Ten tips - how to write a well-structured threat model document

Larry Osterman has an excellent post about threat modeling. I would add a couple of observations, from my own experience.

1) Make sure that you include short definitions for all concepts that are you using, even if they are very basic. Even if it might look redundant to explain what STRIDE stands for, some readers will be thankful to you as they might not remember these definitions. Make sure that you are as accurate as possible in those definitions.

2) Make sure that all entry points, assets, trust boundaries and levels, threats, vulnerabilities, etc. have well-defined IDs. Use these IDs to cross-reference them. For example, a threat description would refer the list of related assets and their IDs.

3) When you list things like entry points and assets, you usually get a very long list (containing dozens and dozens of items). It is a good practice to structure this list in a tree format instead of a very long list in flat format. For example, the list of entry points might start like this:

Entry points are where control or data crosses the trust-relationship boundary of the system being modeled. The entry points are presented in a layered manner. The default access is read/write, unless other access is specified explicitly.

 

ID			Name	Description	Trust level
1			File system	All the file-system operations (local or remote)	Depends on the operation
	1.1		NTFS contents	Anyone can get/set properties of directories/files, like name, last access time, etc. These properties are interpreted/parsed by components X and Y. We should not have buffer overruns in this parsing code.	Everyone
		1.1.1	Directory & file names	Directory/file names are used by feature X, etc. An invalid file name (or a file name containing invalid Unicode characters) should not cause problems.	Everyone
		1.1.2	Other file properties	Used by feature Z. - File attributes - Last creation time - Last modify time - Owner SID - File size - Etc (TBD – add the full list)	Everyone
		1.1.3	Special cases of directories/files	There are a number of special file system features that can be used as an entry point - Alternate file streams - Hard-links - Reparse points - Compresed files - Encrypted files - NTFS quota - Etc. (TBD – add the full list)	Depends on the feature
	1.2		NTFS Metadata operations	This includes operations that change NTFS metadata: creating directories, renaming files, etc.	Depends on the operation

Note the tree-style format. This format of exposing your list has also a great advantage: you can insert new items in the middle of the list without bumping the ID of all the items that follow. For example, if I insert something between 1.1.2 and 1.1.3, I will change only the ID for the 1.1.3 entry point.

4) When enumerating assets, remember that these assets can be something very abstract. For example, ensuring high availability of the service X would be an asset. An adversary can attack this asset through an DoS attack, with the goal of bringing down availability.

5) When gathering the security-related information about your system, make sure you take an outside-in approach. This strongly contrasts with the inside-out approach used during design and development. Don't start you analysis by reading from the design spec. Start with a fresh mind and attempt to rediscover the system from the attacker's eyes.

6) Use a rigurous process to enumerate the list of threats. Don't rely on intuition only. Intuition is good, but also make sure that you understand very deeply the list of assets and how one could attack them. And another tip: each threat in the list will have fields grouped horizontally (as opposed to columns). This increases the readability of the threat list. Here is a threat example:

ID	1.1
Name	Memory corruption caused by buffer overruns in process X
Description	An adversary exploits a buffer overrun in the process. This directly causes memory corruption, and can lead to malicious code execution in the worst case, and process termination in the best case.
STRIDE classification	STRIDE
Entry points	All, especially: (1) File system. For example, a user creates a very long file path.
Relevant assets	(1) Process
Investigation status	- Testing/Investigate
Vulnerabilities	None yet.
Doc impact?	No
Mitigation	- Before shipping: Eliminate all BOs. Ensuring proper code review, running PREfast/PREfix, etc. - After shipping: disable the feature or publish guidelines to restrict the specific use scenario.

7) We found it very useful to provide a "status" field for every threat (or threat analysis). This status field might be "during investigation by test team", or "during investigation by dev". It is also useful to cross-reference a list of vulnerabilities (if any) for every threat. This allows anyone to see if you still have some uncovered threats.

8) If possible, separate the section listing the threats by the section dealing with threat analysis (i.e. threat trees, etc). This will avoid putting too much information in the threat list.

9) Make sure that every vulnerability has an associated bug number. Also, make sure you specify the impact to the documentation. Some low-priority vulnerabilities might end up being documented in the released product as "potential security issues".

10) Make sure that the mitigation is well-documented for every vulnerability. Add a generic mitigation field to the threats too - this might be useful as a starting point for related vulnerabilities. Make sure that you provide an explicit mitigation strategy for this specific vulnerability that has to be applied after the product is shipped.