Create a good threat about model in 10 simple steps

How can I get a great and secure product without killing myself? This is not just a question for how-to Diet magazines; it’s a legitimate business problem. I teach the ACE Threat Modeling class (First Wednesday of every month!), and that is the question I hear most often.

How can I make a good, useful, threat model and still get my product out on time? If you use the latest Threat Analysis and Modeling (TAM) tool, you can make a terrific threat model in 10 simple steps. You can download this tool at http://go.microsoft.com/fwlink?linkid=77002.

1. Identify business Objectives: The first thing you do is identify the business objectives or goals that are being supported by your application. If an application has no business purpose, it probably isn’t worth building. You should have no more than 5 generic business objectives. The most common one I see is “Specific business Process/Function Automation.” Remember, these are generic—very high level.
2. Define User Roles: Define those actors or users involved in the application functions; break down these roles according to the trust levels in your application. Common roles include Administrators, Support Users, Managers, and Employees.
3. Define Data: Define the logical data groups in your application. You should define these based on the functionality in the application.
4. Define Data Access Control: This defines what a user can do in the application. For each data group you defined above, list who can create, read, update, and/or delete (CRUD) within that group and under what conditions they may act.
5. Generate or Create Use Cases: You can actually let the tool do this for you: just click the Tools -> Generate Use Cases menu item. But note that these cases are based on the information from the previous steps, so make sure it is accurate!
6. Define Components, Service Roles, and Identities: To define these high level components, stick to the logical level, such as Website, Order Processing Component, Reports Component, Main Database, Log Database, etc. With each component, you will have a Service role and identity under which that component runs. Web application components usually have a website role and a network Service identity; windows application have neither because they run under the context of the invoked user, which you capture in the calls.
7. Flush out Calls: Detail each use case with its appropriate call structure. Please give some extra attention to data sent/data received and authorization entries. Note that you can copy/paste or drag/drop calls from one use case to other. Verify each use case by looking at Call, Data and Trust flow visualizations; they help you understand and check the flow visually.
8. Generate and Evaluate Threats: This is another step TAM does for you. Just click Tools -> Generate Threats, and click “OK” to generate threats. Once threat generation is complete, evaluate each threat by selecting appropriate risk factors and risk response.
9. Identify component relevancies: Go back to each component and select the appropriate relevancies. If you have technologies that are not listed in the attack library, import the appropriate attack library using Tools -> Attack Library -> Import.
10. Refresh Countermeasures: Just click Tools -> Refresh Countermeasures, which will identify countermeasures for each threat.

Congratulations! You now have a robust threat model!

Some key side notes:

* Use Data Access Control Matrix to very data access Control; you can view it by going to Analytics -> Data Access Control Matrix
* Use Subject Object Matrix to verify user actions in the entire model; this is a good way to verify that specific users are allowed to do specific actions
* Use development team report to create a countermeasure implementation strategy
* Finally, save a copy of the comprehensive report.

For more information, check out the how-to guide installed with the tool. Ppress F1 to view the guide.

Thanks
Anil Revuru
Security Technologist
ACE Team