Threat Modeling To Ensure Application Security
I was recently involved in an assignment to perform security testing of a Windows 8 Metro App. The goal was to identify potential security threats to the application and define ways to mitigate them. Security testing of any application involves a variety of test scenarios, but it largely depends on the architecture of the application. A desktop application may be exposed to lesser threats as opposed to client server or web applications. Our first approach was to draw a block diagram for the application with all its interfaces and brainstorm on the possible security threats. This was a very crude way of analyzing security threats and we were unsure if we had covered all scenarios. We were looking for a standard methodology which could be used for this analysis. This is when we came across the Threat Modeling process which is an integral part of Microsoft's Security Development Lifecycle.
Threat Modeling allows you to systematically identify threats and define a mitigation plan. It is a structured approach to analyzing security related vulnerabilities in the application and is done during the design phase of the Security Development Lifecycle. The main objective is to design your applications to meet your security objectives and reduce the risk of security issues after the application has been deployed. Threat Modeling needs to keep evolving as and when the design undergoes a change. The threat modeling team should be comprised of a security expert or someone who has the ability to think like a hacker and imagine ways in which the system can be compromised.
The intention of this blog is not to explain the Threat Modeling process or discuss the various kinds of threats applicable to applications. There are numerous good articles and blogs on these subjects. The book - Writing Secure Code by Michael Howard and David LeBlanc includes an entire chapter on Threat Modeling and Security Testing. The main idea is to recognize the importance of following a structured approach to Threat Modeling.
The first step to Threat Modeling is downloading the Threat Modeling tool by Microsoft. It is not necessary to use a tool to do Threat Modeling, but using a tool will save a lot of time which can otherwise be used in analysis. The latest version is available here. The tool requires Visio 2007/2010 to be pre-installed and optionally an installation of TFS if bug filing capability is required. The help files that come with the tool explain the entire process of Threat Modeling along with a sample threat model. That information is sufficient to get started. The quality of a threat model will ultimately depend on the experience of the person creating the threat model. Though this blog talks about Threat Modeling using the Microsoft Threat Modeling tool, the concepts should be the same even if some other tool is used or the analysis is done manually.
Overview of the process:
- Create a Data Flow Diagram (DFD) for your application. This can be done using the Threat Modeling Tool (In Visio) or on a whiteboard. The diagram should capture all components of the system, external entities (users, third party applications, web services etc), data stores (database, registry, configuration files etc) and the interactions between them clearly showing the direction of data flow. The system which you are trying to analyze may be a single component, an API, a web service or a collection of many components. The only important thing is that the system should lie within a trust boundary. Getting the DFD right is key to getting the threat model right.
- Once the DFD is completed, mark the trust boundaries for the system. Typically a trust boundary is present between the system and its external entities, databases, third party systems etc. This is where data flows into or out of the system and can potentially be compromised.
- Start brainstorming on the various threats possible. Microsoft has defined the STRIDE approach which is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. The MSDN article explains this approach.
- For each of the threat identified by the STRIDE approach, identify a mitigation plan. It could be anything from setting an authentication system to user input validations. Any action that mitigates the threat should be listed. It should be mentioned whether the application design takes care of the mitigation.
- There may be threats which are discovered which are not taken care by the application design. File bugs for such threats threats. This will help in tracking during the security review phase.
If the DFD is well defined and you have walked through each threat as defined by the STRIDE model, the threat modeling is more or less complete but this does not mean you are safe from all possible threats. Analyze the mitigation plan and brainstorm on ways those can be bypassed. How much time you spend on the process depends on the criticality of the application, project schedule, budgets etc.
Following a structured approach identifies the threats for each component or data flow as per the defined methodology. E.g. For all data flows, Tampering, Information Disclosure and Denial of Service are identified threats. Once all possible combinations of threats are identified for all the available elements in the DFD, our job is to analyze the threats and mitigate them. It is quite possible that if we are brainstorming randomly we might miss out on a particular kind of threat. Moreover a structured approach makes it easier to modify the threat model as and when the application design changes.
Threat Modeling should be incorporated into the design process of your project if you are really concerned about the security requirements for your application. It is certainly cheaper to fix a security flaw at design time rather than discovering it after deployment and causing potential financial or information losses.
Do you use Threat Modeling in your organizations? Which Threat Modeling technique works the best for you?