Resource File
Threat Model Your Security Risks
In the .NET world of loosely coupled distributed components, sharing sensitive data across networks means increased exposure to attackers hungry for your data. You need to create a tight security model to benefit from the .NET vision of fully functional, distributed computing. Failure to achieve this can lead to disaster. So how do you make sure your application is as secure as it needs to be? Well, you should begin with threat modeling, an iterative approach to assessing the vulnerabilities in your application to find those that are the most dangerous because they expose the most sensitive data. From there, you create a prioritized set of countermeasures to manage your risk.
The best place to learn about threat modeling and its role in the overall architecture and design process is "Improving Web Application Security: Threats and Countermeasures," located on the Microsoft
patterns & practices Web site.
There's a six-step approach to creating a threat model. The first is obvious—identify your assets. Every site has some confidential data, from salaries to Social Security numbers. You won't know what hackers want until you've identified the sensitive information on your site.
The next step is to develop an architecture overview. You need to be explicit about what the application is designed to do (use cases), how you plan to architect and design the application to achieve that functionality, and what technologies are required to implement the design. This helps you identify common technology-specific threats and implement solutions to overcome them.
The use cases and architectural model will help you decompose your application, which is the third step. The more you know about your application, the easier it is to uncover threats. This step involves breaking down your application to create a security profile. Accepting the axiom that all data is evil, you should perform validation against all data sent across subsystems. An exhaustive examination of your trust boundaries, data flow, and entry points will ensure that all handoffs are done in a secure manner.
In the fourth step, you identify threats that might affect your system and compromise your assets. To take a methodical approach, you should work your way up the stack: from network threats, through host threats, and then application threats. To assess network threats, investigate how the data passes through router configurations, firewalls, and switches. This is the network-level defense in-depth strategy and you need to determine what it takes to get past each gatekeeper. When investigating the host, examine common configuration categories applicable to all server resources (patches, files, directories, and so on). Finally, refocus on the application. The best way to go deep with your app is to use attack trees, which define a potential attack on your system in a structured and hierarchical manner. "Improving Web Application Security" goes into greater detail on how to create and use attack trees.
In the fifth step, you document each threat—the description of the threat, the target of the attack, the risk of the attack, the techniques likely to be used to perpetrate the attack, and a strategy to manage your risk. For example, when dealing with SQL injection, the target is your database and the technique is that the attacker types a command into a textbox that is automatically added into a T-SQL command without client-side validation. To counter this threat, use regular expressions to validate the user name, and use a parameterized query to access the database.
So far you've been in data collection mode, determining every possible hole in your app. Step six is to prioritize. Addressing every conceivable threat is not practical, but you need to do a risk assessment to prioritize and address the most important ones. This requires some simple math: the probability of occurrence multiplied by the potential damage that would occur. The good news is that this is a simple way to prioritize; the bad news is that this is a simple way to prioritize. It is a bit subjective given the meticulous approach to identifying the risks. There are more thorough approaches for risk assessment.
Microsoft uses the DREAD model to assess risk with a greater granularity than the simple math already described. DREAD is an acronym that defines five key attributes used to measure each vulnerability: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. "Improving Web Application Security" details how Microsoft uses DREAD to prioritize and mitigate risk.
These six steps complete the process. You are now ready to properly implement your security strategy. Threat modeling is an indispensable approach to avoiding the disasters that could make for front-page news.