Execute VirtualBox and run WindowsXP.
After Windows XP login. download and install:
http://www.microsoft.com/en-us/download/details.aspx?id=42518
Threat Modeling
We'll do a (very basic) sample threat model of a physical bank teller.
The Description isn't always necessary; it just depends on how (un)familiar I am with the component / technology. If I'm helping to threat model Feature XYZ of Microsoft Excel it probably needs no introduction, but if your product team is releasing a brand-new product with some funky internal code name I probably won't have a clue. The point here is to get a high-level overview of how scared I should be about your product / feature; to see what kind of attack surface it has. Is it Notepad or is it IIS? Is it a rich-client app or a network service? What account does it run under? Does it run in user mode or in kernel mode? Is it restricted to fully trusted (native) code or does it allow partially-trusted callers? Does it run by default every time the box boots, or is it a utility that the user runs once in a blue moon? Basic things like that.
For the bank teller example, the salient points are that random people come in off the street and ask you for money, and you have to make sure you only give it to the right people. The description might be:
The Bank Teller component gives out money to clients. It accepts requests from arbitrary clients, performs authentication and authorisation activities, and then processes valid requests for cash withdrawals. The teller is trusted to perform these actions, but is required to work within the confines of various corporate policies with regards to transaction amounts, auditing of transactions, etc.
The DFDs are really where it's all at. As the saying goes, a picture is worth a thousand word and DFDs are no different. You can convey so much information in such a small amount of space / time using a good diagram that their utility cannot be overstated. A DFD is not a flow chart; it is a diagram showing flows of data between components:
A good DFD starts with a Context Diagram -- a diagram with your component in the middle and all the external entities it talks to on the outside. An example for the bank teller might be something like this:
Next, you start drilling into the details inside the component in a series of one or more Level N diagrams (where N gets higher the further you drill down), which might give you something like this:
Here AuthN is short hand for Authenticate - making sure the person is who they really claim they are, and AuthZ is short hand for Authorise, making sure the user has permission to do what they are attempting to do. These two abbreviations are commonly used at Microsoft (and possibly elsewhere) and they are also used to mean "Authentication" and "Authorisation" as well.
In virtual machine Windows XP use the installed Threat Modeling Tool to Draw Diagram from the previous DFD of an ATM.
Step 1 “Draw Diagram”
Step 2 “Analyze Model”
The center for analysis of the model, where users use Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege (STRIDE) to find each threat and figure out how to mitigate it.
Click -> View Menu -> Analysis View
Follow the single Threats and think about potentional problems and solutions.
Step 4 “Generate Reports”
Brings out all the data that has been entered in a variety of useful forms.
Click -> menu Reports
Implement your (secure)system based on the discovered threats and their mitigations.
