Threat Modeling: The First Step in Architecting

Before you start to develop your Architecture, you need to take a close look at the Threats that will put your Application at Risk. To do that, you need to start the process of Threat Modeling.

Threat Modeling is the process of evaluating the Threats to an Application, determining the Risk associated with the Threat (Risk being the combination of the likelihood of a Vulnerability being exploited and the Result if the Vulnerability was to used successfully). To Security people, this is often called Threat Risk Assessments (TRAs).

Threat Modeling contains four basic steps:

• Define the Requirements
  
• Model the Threats
  
• Measure the Impacts
  
• Document the Results
  

When you look at defining the Requirements, you develop the Use Cases for the Application to determine where the potential vulnerabilities may be for the Application about to be designed. That way you know what to design for.

After defining the Requirements, you then model the Threats. Typically, this involves using a collection of known threats that you have collected that you have to deal with. If you haven’t collected a list of known threats, I would suggest that you go to the OWASP web site and take a look at the list of Vulnerabilities to get an idea of what you have to deal with. The OWASP Vulnerability listing is located at http://www.owasp.org/index.php/Category:Vulnerability.

Once you’ve Modeled the Threats, you need to Measure the Impacts. This means determining what the Risk is associated with the Threats, determining what the resulting impact would be, and then determining how to deal with that Risk. To use an extreme case, say one of the Threats is that someone will blow up the Server Room housing the Application. The likelihood of this occurring is very low but, if it was to occur, the result may quite devastating for a mission critical application. Hence the reason why you look into Disaster Recovery/Failover locations. Then, to deal with the Risk, you determine whether you want to Avoid (completely mitigate the risk), Reduce (partially mitigate the Risk, Transfer (move the risk to some other party such as insurance), or Accept the Risk (do nothing – this is always an option).

Documenting is basically a necessary step in the creation of any Architecture in order to ensure that the resulting Architecture has taken into consideration the modeling that you have just done. Remember that the Threat Model is used through the rest of the development process so that all parties understand what Risks have to be dealt with.

For those that would like to use a tool, the one I’ve been looking at lately is the Microsoft Threat Modeling tool. It’s free to anyone that wants to download it from MSDN and it assists dramatically in structuring the Threat Modeling process. You can get it from the following URL http://www.microsoft.com/downloads/details.aspx?familyid=570dccd9-596a-44bc-bed7-1f6f0ad79e3d&displaylang=en. I’ll review the tool in the next blog.

So, the next time you decide to architect an application, make sure you include Threat Modeling in your initial modeling processes. It ensures that your Architecture is designed with Threats in mind. And remember that all of this is driven by your Business Requirements that we talked about in the last blog. If the Requirements don’t require this level of security (eg. The application being written is a simple, behind the scenes, unimportant application) you may not be required to perform Threat Modeling).

Regards,

Neil R.

Posted at 03:58 AM  Permalink