Chapter 3 – Threat Modeling
Retired Content |
---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Improving Web Application Security: Threats and Countermeasures
J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation
Published: June 2003
Applies to:
- Web Applications
See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.
See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.
Summary: Threat modeling allows you to apply a structured approach to security and to address the top threats that have the greatest potential impact to your application first. This chapter helps you to decompose your Web application to identify and rate the threats that are most likely to impact your system. The chapter presents a six-step threat modeling process.
Contents
In This Chapter
Overview
Before You Begin
How to Use This Chapter
Threat Modeling Principles
Step 1. Identify Assets
Step 2. Create an Architecture Overview
Step 3. Decompose the Application
Step 4. Identify the Threats
Step 5. Document the Threats
Step 6. Rate the Threats
What Comes After Threat Modeling?
Summary
Additional Resources
In This Chapter
- Steps to decompose application architecture to discover vulnerabilities
- How to identify and document threats that are relevant to your application
Overview
Threat modeling allows you to systematically identify and rate the threats that are most likely to affect your system. By identifying and rating threats based on a solid understanding of the architecture and implementation of your application, you can address threats with appropriate countermeasures in a logical order, starting with the threats that present the greatest risk.
Threat modeling has a structured approach that is far more cost efficient and effective than applying security features in a haphazard manner without knowing precisely what threats each feature is supposed to address. With a random, "shotgun" approach to security, how do you know when your application is "secure enough," and how do you know the areas where your application is still vulnerable? In short, until you know your threats, you cannot secure your system.
Note For more information about the latest threat modeling process, see "Threat Modeling Web Applications."
Before You Begin
Before you start the threat modeling process, it is important that you understand the following basic terminology:
- Asset. A resource of value, such as the data in a database or on the file system. A system resource.
- Threat. A potential occurrence, malicious or otherwise, that might damage or compromise your assets.
- Vulnerability. A weakness in some aspect or feature of a system that makes a threat possible. Vulnerabilities might exist at the network, host, or application levels.
- Attack (or exploit). An action taken by someone or something that harms an asset. This could be someone following through on a threat or exploiting a vulnerability.
- Countermeasure. A safeguard that addresses a threat and mitigates risk.
Consider a simple house analogy: an item of jewelry in a house is an asset and a burglar is an attacker. A door is a feature of the house and an open door represents a vulnerability. The burglar can exploit the open door to gain access to the house and steal the jewelry. In other words, the attacker exploits a vulnerability to gain access to an asset. The appropriate countermeasure in this case is to close and lock the door.
How to Use This Chapter
This chapter outlines a generic process that helps you identify and document threats to your application. The following are recommendations on how to use this chapter:
- Establish a process for threat modeling. Use this chapter as a starting point for introducing a threat modeling process in your organization if you do not already have one. If you already have a process, then you can use this as a reference for comparison.
- Use the other chapters in this guide to familiarize yourself with the most common threats. Read Chapter 2, "Threats and Countermeasures," for an overview of common threats that occur at the network, host, and application levels.
- For more specific threats to your network, see "Threats and Countermeasures" in Chapter 15, "Securing Your Network."
- For more specific threats to your Web server, application server, and database server, see "Threats and Countermeasures" in Chapter 16, "Securing Your Web Server," Chapter 17, "Securing Your Application Server," and Chapter 18, "Securing Your Database Server."
- For more specific threats to your assemblies, ASP.NET, serviced components, remoted components, Web Services, and data access, see "Threats and Countermeasures" in Chapter 7, "Building Secure Assemblies;" Chapter 10, "Building Secure ASP.NET Pages and Controls;" Chapter 11, "Building Secure Serviced Components;" Chapter 12, "Building Secure Web Services;" Chapter 13, "Building Secure Remoted Components;" and Chapter 14, "Building Secure Data Access."
- Evolve your threat model. Build a threat model early and then evolve it as you go. It is a work in progress. Security threats evolve, and so does your application. Having a document that identifies both what the known threats are and how they have been addressed (or not) puts you in control of the security of your application.
Threat Modeling Principles
Threat modeling should not be a one time only process. It should be an iterative process that starts during the early phases of the design of your application and continues throughout the application life cycle. There are two reasons for this. First, it is impossible to identify all of the possible threats in a single pass. Second, because applications are rarely static and need to be enhanced and adapted to suit changing business requirements, the threat modeling process should be repeated as your application evolves.
The Process
Figure 3.1 shows the threat modeling process that you can perform using a six-stage process.
Note The following process outline can be used for applications that are currently in development and for existing applications.
Figure 3.1
An overview of the threat modeling process
Identify assets.
Identify the valuable assets that your systems must protect.
Create an architecture overview.
Use simple diagrams and tables to document the architecture of your application, including subsystems, trust boundaries, and data flow.
Decompose the application.
Decompose the architecture of your application, including the underlying network and host infrastructure design, to create a security profile for the application. The aim of the security profile is to uncover vulnerabilities in the design, implementation, or deployment configuration of your application.
Identify the threats.
Keeping the goals of an attacker in mind, and with knowledge of the architecture and potential vulnerabilities of your application, identify the threats that could affect the application.
Document the threats.
Document each threat using a common threat template that defines a core set of attributes to capture for each threat.
Rate the threats.
Rate the threats to prioritize and address the most significant threats first. These threats present the biggest risk. The rating process weighs the probability of the threat against damage that could result should an attack occur. It might turn out that certain threats do not warrant any action when you compare the risk posed by the threat with the resulting mitigation costs.
The Output
The output from the threat modeling process is a document for the various members of your project team. It allows them to clearly understand the threats that need to be addressed and how to address them. Threat models consist of a definition of the architecture of your application and a list of threats for your application scenario, as Figure 3.2 shows.
Figure 3.2
Components of the threat model
Step 1. Identify Assets
Identify the assets that you need to protect. This could range from confidential data, such as your customer or orders database, to your Web pages or Web site availability.
Step 2. Create an Architecture Overview
At this stage, the goal is to document the function of your application, its architecture and physical deployment configuration, and the technologies that form part of your solution. You should be looking for potential vulnerabilities in the design or implementation of the application.
During this step, you perform the following tasks:
- Identify what the application does.
- Create an architecture diagram.
- Identify the technologies.
Identify What the Application Does
Identify what the application does and how it uses and accesses assets. Document use cases to help you and others understand how your application is supposed to be used. This also helps you work out how it can be misused. Use cases put application functionality in context.
Here are some sample use cases for a self-service, employee human resources application:
- Employee views financial data.
- Employee updates personal data.
- Manager views employee details.
In the above cases you can look at the implications of the business rules being misused. For example, consider a user trying to modify personal details of another user. He or she should not be authorized to access those details according to the defined application requirements.
Create an Architecture Diagram
Create a high-level architecture diagram that describes the composition and structure of your application and its subsystems as well as its physical deployment characteristics, such as the diagram in Figure 3.3. Depending on the complexity of your system, you might need to create additional diagrams that focus on different areas, for example, a diagram to model the architecture of a middle-tier application server, or one to model the interaction with an external system.
Figure 3.3
Sample application architecture diagram
Start by drawing a rough diagram that conveys the composition and structure of the application and its subsystems together with its deployment characteristics. Then, evolve the diagram by adding details about the trust boundaries, authentication, and authorization mechanisms as and when you discover them (usually during Step 3 when you decompose the application).
Identify the Technologies
Identify the distinct technologies that are used to implement your solution. This helps you focus on technology-specific threats later in the process. It also helps you determine the correct and most appropriate mitigation techniques. The technologies you are most likely to identify include ASP.NET, Web Services, Enterprise Services, Microsoft .NET Remoting, and ADO.NET. Also identify any unmanaged code that your application calls.
Document the technologies using a table similar to Table 3.1, below.
Table 3.1 Implementation Technologies
Technology/Platform | Implementation Details |
---|---|
Microsoft SQL Server on Microsoft Windows Advanced Server 2000 | Includes logins, database users, user defined database roles, tables, stored procedures, views, constraints, and triggers. |
Microsoft .NET Framework | Used for Forms authentication. |
Secure Sockets Layer (SSL) | Used to encrypt HTTP traffic. |
Step 3. Decompose the Application
In this step, you break down your application to create a security profile for the application based on traditional areas of vulnerability. You also identify trust boundaries, data flow, entry points, and privileged code. The more you know about the mechanics of your application, the easier it is to uncover threats. Figure 3.4 shows the various targets for the decomposition process.
Figure 3.4
Targets for application decomposition
During this step, you perform the following tasks:
- Identify trust boundaries.
- Identify data flow.
- Identify entry points.
- Identify privileged code.
- Document the security profile.
Identify Trust Boundaries
Identify the trust boundaries that surround each of the tangible assets of your application. These assets are determined by your application design. For each subsystem, consider whether the upstream data flows or user input is trusted, and if not, consider how the data flows and input can be authenticated and authorized. Also consider whether the calling code is trusted, and if it is not, consider how it can be authenticated and authorized. You must be able to ensure that the appropriate gatekeepers guard all entry points into a particular trust boundary and that the recipient entry point fully validates all data passed across a trust boundary.
Start by analyzing trust boundaries from a code perspective. The assembly, which represents one form of trust boundary, is a useful place to start. Which assemblies trust which other assemblies? Does a particular assembly trust the code that calls it, or does it use code access security to authorize the calling code?
Also consider server trust relationships. Does a particular server trust an upstream server to authenticate and authorize the end users, or does the server provide its own gatekeeping services? Also, does a server trust an upstream server to pass it data that is well formed and correct?
For example, in Figure 3.3, the Web application accesses the database server by using a fixed, trusted identity, which in this case is the ASP.NET Web application process account. In this scenario, the database server trusts the application to authenticate and authorize callers and forward only valid data request data on behalf of authorized users.
Note In a .NET Framework application, the assembly defines the smallest unit of trust. Whenever data is passed across an assembly boundary — which by definition includes an application domain, process, or machine boundary — the recipient entry point should validate its input data.
Identify Data Flow
A simple approach is to start at the highest level and then iteratively decompose the application by analyzing the data flow between individual subsystems. For example, analyze the data flow between a Web application and an Enterprise Services application and then between individual serviced components.
Data flow across trust boundaries is particularly important because code that is passed data from outside its own trust boundary should assume that the data is malicious and perform thorough validation of the data.
Note Data flow diagrams (DFDs) and sequence diagrams can help with the formal decomposition of a system. A DFD is a graphical representation of data flows, data stores, and relationships between data sources and destinations. A sequence diagram shows how a group of objects collaborate in terms of chronological events.
Identify Entry Points
The entry points of your application also serve as entry points for attacks. Entry points might include the front-end Web application listening for HTTP requests. This entry point is intended to be exposed to clients. Other entry points, such as internal entry points exposed by subcomponents across the tiers of your application, may only exist to support internal communication with other components. However, you should know where these are, and what types of input they receive in case an attacker manages to bypass the front door of the application and directly attack an internal entry point.
For each entry point, you should be able to determine the types of gatekeepers that provide authorization and the degree of validation.
Logical application entry points include user interfaces provide by Web pages, service interfaces provided by Web services, serviced components, and .NET Remoting components and message queues that provide asynchronous entry points. Physical or platform entry points include ports and sockets.
Identify Privileged Code
Privileged code accesses specific types of secure resources and performs other privileged operations. Secure resource types include DNS servers, directory services, environment variables, event logs, file systems, message queues, performance counters, printers, the registry, sockets, and Web services. Secure operations include unmanaged code calls, reflection, serialization, code access security permissions, and manipulation of code access security policy, including evidence.
Privileged code must be granted the appropriate code access security permissions by code access security policy. Privileged code must ensure that the resources and operations that it encapsulates are not exposed to untrusted and potentially malicious code. .NET Framework code access security verifies the permissions granted to calling code by performing stack walks. However, it is sometimes necessary to override this behavior and short-circuit the full stack walk, for example, when you want to restrict privileged code with a sandbox or otherwise isolate privileged code. Doing so opens your code up to luring attacks, where malicious code calls your code through trusted intermediary code.
Whenever you override the default security behavior provided by code access security, do it diligently and with the appropriate safeguards. For more information about reviewing code for security flaws, see Chapter 21, "Code Review." For more information about code access security, see Chapter 8, "Code Access Security in Practice" and Chapter 9, "Using Code Access Security with ASP.NET."
Document the Security Profile
Next, you should identify the design and implementation approaches used for input validation, authentication, authorization, configuration management, and the remaining areas where applications are most susceptible to vulnerabilities. By doing this, you create a security profile for the application.
The following table shows what kinds of questions to ask while analyzing each aspect of the design and implementation of your application. For more information about reviewing application architecture and design, see Chapter 5, "Architecture and Design Review."
Table 3.2 Creating a Security Profile
Category | Considerations |
---|---|
Input validation | Is all input data validated?
Could an attacker inject commands or malicious data into the application? Is data validated as it is passed between separate trust boundaries (by the recipient entry point)? Can data in the database be trusted? |
Authentication | Are credentials secured if they are passed over the network?
Are strong account policies used? Are strong passwords enforced? Are you using certificates? Are password verifiers (using one-way hashes) used for user passwords? |
Authorization | What gatekeepers are used at the entry points of the application?
How is authorization enforced at the database? Is a defense in depth strategy used? Do you fail securely and only allow access upon successful confirmation of credentials? |
Configuration management | What administration interfaces does the application support?
How are they secured? How is remote administration secured? What configuration stores are used and how are they secured? |
Sensitive data | What sensitive data is handled by the application?
How is it secured over the network and in persistent stores? What type of encryption is used and how are encryption keys secured? |
Session management | How are session cookies generated?
How are they secured to prevent session hijacking? How is persistent session state secured? How is session state secured as it crosses the network? How does the application authenticate with the session store? Are credentials passed over the wire and are they maintained by the application? If so, how are they secured? |
Cryptography | What algorithms and cryptographic techniques are used?
How long are encryption keys and how are they secured? Does the application put its own encryption into action? How often are keys recycled? |
Parameter manipulation | Does the application detect tampered parameters?
Does it validate all parameters in form fields, view state, cookie data, and HTTP headers? |
Exception management | How does the application handle error conditions?
Are exceptions ever allowed to propagate back to the client? Are generic error messages that do not contain exploitable information used? |
Auditing and logging | Does your application audit activity across all tiers on all servers?
How are log files secured? |
Step 4. Identify the Threats
In this step, you identify threats that might affect your system and compromise your assets. To conduct this identification process, bring members of the development and test teams together to conduct an informed brainstorming session in front of a whiteboard. This is a simple yet effective way to identify potential threats. Ideally, the team consists of application architects, security professionals, developers, testers, and system administrators.
You can use two basic approaches:
- Use STRIDE to identify threats. Consider the broad categories of threats, such as spoofing, tampering, and denial of service, and use the STRIDE model from Chapter 2, "Threats and Countermeasures" to ask questions in relation to each aspect of the architecture and design of your application. This is a goal-based approach where you consider the goals of an attacker. For example, could an attacker spoof an identity to access your server or Web application? Could someone tamper with data over the network or in a store? Could someone deny service?
- Use categorized threat lists. With this approach, you start with a laundry list of common threats grouped by network, host, and application categories. Next, apply the threat list to your own application architecture and any vulnerabilities you have identified earlier in the process. You will be able to rule some threats out immediately because they do not apply to your scenario.
Use the following resources to help you with the threat identification process:
- For a list of threats organized by network, host, and application layers, as well as explanations of the threats and associated countermeasures, see Chapter 2, "Threats and Countermeasures."
- For a list of threats by technology, see "Threats and Countermeasures" at the beginning of each of the "Building" chapters in Part III of this guide.
During this step, you perform the following tasks:
- Identify network threats.
- Identity host threats.
- Identify applicationthreats.
Identify Network Threats
This is a task for network designers and administrators. Analyze the network topology and the flow of data packets, together with router, firewall, and switch configurations, and look for potential vulnerabilities. Also pay attention to virtual private network (VPN) endpoints. Review the network defenses against the most common network layer threats identified in Chapter 2, "Threats and Countermeasures."
Top network threats to consider during the design phase include:
- Using security mechanisms that rely on the IP address of the sender. It is relatively easy to send IP packets with false source IP addresses (IP spoofing).
- Passing session identifiers or cookies over unencrypted network channels. This can lead to IP session hijacking.
- Passing clear text authentication credentials or other sensitive data over unencrypted communication channels. This could allow an attacker to monitor the network, obtain logon credentials, or obtain and possibly tamper with other sensitive data items.
You must also ensure that your network is not vulnerable to threats arising from insecure device and server configuration. For example, are unnecessary ports and protocols closed and disabled? Are routing tables and DNS server secured? Are the TCP network stacks hardened on your servers? For more information about preventing this type of vulnerability, see Chapter 15, "Securing Your Network."
Identify Host Threats
The approach used throughout this guide when configuring host security (that is, Microsoft Windows 2000 or Microsoft Windows Server™ 2003 and .NET Framework configuration) is to divide the configuration into separate categories to allow you to apply security settings in a structured and logical manner. This approach is also ideally suited for reviewing security, spotting vulnerabilities, and identifying threats. Common configuration categories applicable to all server roles include patches and updates, services, protocols, accounts, files and directories, shares, ports, and auditing and logging. For each category, identify potentially vulnerable configuration settings. From these, identify threats.
Top vulnerabilities to consider include:
- Maintaining unpatched servers, which can be exploited by viruses, Trojan horses, worms, and well-known IIS attacks.
- Using nonessential ports, protocols, and services, which increase the attack profile and enable attackers to gather information about and exploit your environment.
- Allowing unauthenticated anonymous access.
- Using weak passwords and account policies that lead to password cracking, identity spoofing, and denial of service attacks if accounts can be locked out deliberately.
Identify Application Threats
In the previous steps, you defined the architecture, data flow, and trust boundaries of your application. You also created a security profile that describes how the application handles core areas, such as authentication, authorization, configuration management, and other areas.
Now use the broad STRIDE threat categories and predefined threat lists to scrutinize each aspect of the security profile of your application. Focus on application threats, technology-specific threats, and code threats. Key vulnerabilities to consider include:
- Using poor input validation that leads to cross-site scripting (XSS), SQL injection, and buffer overflow attacks.
- Passing authentication credentials or authentication cookies over unencrypted network links, which can lead to credential capture or session hijacking.
- Using weak password and account policies, which can lead to unauthorized access.
- Failing to secure the configuration management aspects of your application, including administration interfaces.
- Storing configuration secrets, such as connection strings and service account credentials, in clear text.
- Using over-privileged process and service accounts.
- Using insecure data access coding techniques, which can increase the threat posed by SQL injection.
- Using weak or custom encryption and failing to adequately secure encryption keys.
- Relying on the integrity of parameters that are passed from the Web browser, for example, form fields, query strings, cookie data, and HTTP headers.
- Using insecure exception handling, which can lead to denial of service attacks and the disclosure of system-level details that are useful to an attacker.
- Doing inadequate auditing and logging, which can lead to repudiation threats.
Using Attack Trees and Attack Patterns
Attack trees and attack patterns are the primary tools that security professionals use. These are not essential components of the threat identification phase but you may find them useful. They allow you to analyze threats in greater depth, going beyond what you already know to identify other possibilities.
Important When you use previously prepared categorized lists of known threats, it only reveals the common, known threats. Additional approaches, such as the use of attack trees and attack patterns, can help you identify other potential threats.
An attack tree is a way of collecting and documenting the potential attacks on your system in a structured and hierarchical manner. The tree structure gives you a descriptive breakdown of various attacks that the attacker uses to compromise the system. By creating attack trees, you create a reusable representation of security issues that helps focus efforts. Your test team can create test plans to validate security design. Developers can make tradeoffs during implementation and architects or developer leads can evaluate the security cost of alternative approaches.
Attack patterns are a formalized approach to capturing attack information in your enterprise. These patterns can help you identify common attack techniques.
Creating Attack Trees
While several approaches can be used in practice, the accepted method is to identify goals and sub-goals of an attack, as well as what must be done so that the attack succeeds. You can use a hierarchical diagram to represent your attack tree, or use a simple outline. What is important in the end is that you have something that portrays the attack profile of your application. You can then evaluate likely security risks, which you can mitigate with the appropriate countermeasures, such as correcting a design approach, hardening a configuration setting, and other solutions.
Start building an attack tree by creating root nodes that represent the goals of the attacker. Then add the leaf nodes, which are the attack methodologies that represent unique attacks. Figure 3.5 shows a simple example.
Figure 3.5
Representation of an attack tree
You can label leaf nodes with AND and OR labels. For example, in Figure 3.5, both 1.1 and 1.2 must occur for the threat to result in an attack.
Attack trees like the one shown above have a tendency to become complex quickly. They are also time-consuming to create. An alternative approach favored by some teams is to structure your attack tree using an outline such as the one shown below.
1. Goal One
1.1 Sub-goal one
1.2 Sub-goal two
2. Goal Two
2.1 Sub-goal one
2.2 Sub-goal two
Note In addition to goals and sub-goals, attack trees include methodologies and required conditions.
Here is an example of the outline approach in action:
Threat #1 Attacker obtains authentication credentials by monitoring the network
1.1 Clear text credentials sent over the network AND
1.2 Attacker uses network-monitoring tools
1.2.1 Attacker recognizes credential data
For a complete example, see "Sample Attack Trees" in the "Cheat Sheets" section of this guide.
Attack Patterns
Attack patterns are generic representations of commonly occurring attacks that can occur in a variety of different contexts. The pattern defines the goal of the attack as well as the conditions that must exist for the attack to occur, the steps that are required to perform the attack, and the results of the attack. Attack patterns focus on attack techniques, whereas STRIDE-based approaches focus on the goals of the attacker.
An example of an attack pattern is the code-injection attack pattern that is used to describe code injection attacks in a generic way. Table 3.3 describes the code-injection attack pattern.
Table 3.3 Code Injection Attack Pattern
Pattern | Code injection attacks |
---|---|
Attack goals | Command or code execution |
Required conditions | Weak input validation
Code from the attacker has sufficient privileges on the server. |
Attack technique | 1.Identify program on target system with an input validation vulnerability.
2.Create code to inject and run using the security context of the target application. 3.Construct input value to insert code into the address space of the target application and force a stack corruption that causes application execution to jump to the injected code. |
Attack results | Code from the attacker runs and performs malicious action. |
For more information about attack patterns, see the "Additional Resources" section at the end of this chapter.
Step 5. Document the Threats
To document the threats of your application, use a template that shows several threat attributes similar to the one below. The threat description and threat target are essential attributes. Leave the risk rating blank at this stage. This is used in the final stage of the threat modeling process when you prioritize the identified threat list. Other attributes you may want to include are the attack techniques, which can also highlight the vulnerabilities exploited, and the countermeasures that are required to address the threat.
Table 3.4 Threat 1
Threat Description | Attacker obtains authentication credentials by monitoring the network |
---|---|
Threat target | Web application user authentication process |
Risk | |
Attack techniques | Use of network monitoring software |
Countermeasures | Use SSL to provide encrypted channel |
Table 3.5 Threat 2
Threat Description | Injection of SQL commands |
---|---|
Threat target | Data access component |
Risk | |
Attack techniques | Attacker appends SQL commands to user name, which is used to form a SQL query |
Countermeasures | Use a regular expression to validate the user name, and use a stored procedure that uses parameters to access the database. |
Step 6. Rate the Threats
At this stage in the process, you have a list of threats that apply to your particular application scenario. In the final step of the process, you rate threats based on the risks they pose. This allows you to address the threats that present the most risk first, and then resolve the other threats. In fact, it may not be economically viable to address all of the identified threats, and you may decide to ignore some because of the chance of them occurring is small and the damage that would result if they did is minimal.
Risk = Probability * Damage Potential
This formula indicates that the risk posed by a particular threat is equal to the probability of the threat occurring multiplied by the damage potential, which indicates the consequences to your system if an attack were to occur.
You can use a 1–10 scale for probability where 1 represents a threat that is very unlikely to occur and 10 represents a near certainty. Similarly, you can use a 1–10 scale for damage potential where 1 indicates minimal damage and 10 represents a catastrophe. Using this approach, the risk posed by a threat with a low likelihood of occurring but with high damage potential is equal to the risk posed by a threat with limited damage potential but that is extremely likely to occur.
For example, if Probability=10 and DamagePotential=1, then Risk = 10 * 1 = 10. If Probability=1 and DamagePotential=10, then Risk = 1 * 10 = 10.
This approach results in a scale of 1–100, and you can divide the scale into three bands to generate a High, Medium, or Low risk rating.
High, Medium, and Low Ratings
You can use a simple High, Medium, or Low scale to prioritize threats. If a threat is rated as High, it poses a significant risk to your application and needs to be addressed as soon as possible. Medium threats need to be addressed, but with less urgency. You may decide to ignore low threats depending upon how much effort and cost is required to address the threat.
DREAD
The problem with a simplistic rating system is that team members usually will not agree on ratings. To help solve this, add new dimensions that help determine what the impact of a security threat really means. At Microsoft, the DREAD model is used to help calculate risk. By using the DREAD model, you arrive at the risk rating for a given threat by asking the following questions:
- Damage potential: How great is the damage if the vulnerability is exploited?
- Reproducibility: How easy is it to reproduce the attack?
- Exploitability: How easy is it to launch an attack?
- Affected users: As a rough percentage, how many users are affected?
- Discoverability: How easy is it to find the vulnerability?
You can use above items to rate each threat. You can also extend the above questions to meet your needs. For example, you could add a question about potential reputation damage:
Reputation: How high are the stakes? Is there a risk to reputation, which could lead to the loss of customer trust?
Ratings do not have to use a large scale because this makes it difficult to rate threats consistently alongside one another. You can use a simple scheme such as High (1), Medium (2), and Low (3).
When you clearly define what each value represents for your rating system, it helps avoids confusion. Table 3.6 shows a typical example of a rating table that can be used by team members when prioritizing threats.
Table 3.6 Thread Rating Table
Rating | High (3) | Medium (2) | Low (1) | |
---|---|---|---|---|
D | Damage potential | The attacker can subvert the security system; get full trust authorization; run as administrator; upload content. | Leaking sensitive information | Leaking trivial information |
R | Reproducibility | The attack can be reproduced every time and does not require a timing window. | The attack can be reproduced, but only with a timing window and a particular race situation. | The attack is very difficult to reproduce, even with knowledge of the security hole. |
E | Exploitability | A novice programmer could make the attack in a short time. | A skilled programmer could make the attack, then repeat the steps. | The attack requires an extremely skilled person and in-depth knowledge every time to exploit. |
A | Affected users | All users, default configuration, key customers | Some users, non-default configuration | Very small percentage of users, obscure feature; affects anonymous users |
D | Discoverability | Published information explains the attack. The vulnerability is found in the most commonly used feature and is very noticeable. | The vulnerability is in a seldom-used part of the product, and only a few users should come across it. It would take some thinking to see malicious use. | The bug is obscure, and it is unlikely that users will work out damage potential. |
After you ask the above questions, count the values (1–3) for a given threat. The result can fall in the range of 5–15. Then you can treat threats with overall ratings of 12–15 as High risk, 8–11 as Medium risk, and 5–7 as Low risk.
For example, consider the two threats described earlier:
- Attacker obtains authentication credentials by monitoring the network.
- SQL commands injected into application.
Table 3.7 shows an example DREAD rating for both threats:
Table 3.7 DREAD rating
Threat | D | R | E | A | D | Total | Rating |
---|---|---|---|---|---|---|---|
Attacker obtains authentication credentials by monitoring the network. | 3 | 3 | 2 | 2 | 2 | 12 | High |
SQL commands injected into application. | 3 | 3 | 3 | 3 | 2 | 14 | High |
Once you have obtained the risk rating, you update the documented threats and add the discovered rating level, which is High for both of the above threats. Table 3.8 shows an example.
Table 3.8 Threat 1
Threat Description | Attacker obtains authentication credentials by monitoring the network |
---|---|
Threat target | Web application user authentication process |
Risk rating | High |
Attack techniques | Use of network monitoring software |
Countermeasures | Use SSL to provide encrypted channel |
What Comes After Threat Modeling?
The output of the threat modeling process includes documentation of the security aspects of the architecture of your application and a list of rated threats. The threat model helps you orchestrate development team members and focus on the most potent threats.
Important Threat modeling is an iterative process. The threat model is a document that evolves and that various team members can work from.
The threat model can be used by the following groups of people:
- Designers can use it to make secure design choices about technologies and functionality.
- Developers who write code can use it to mitigate risks.
- Testers can write test cases to test if the application is vulnerable to the threats identified by the analysis.
Generating a Work Item Report
From the initial threat model, you can create a more formalized work item report that can include additional attributes, such as a Bug ID, which can be used to tie the threat in with your favorite bug tracking system. In fact, you may choose to enter the identified threats in your bug tracking system and use its reporting facilities to generate the report. You can also include a status column to indicate whether or not the bug has been fixed. You should make sure the report includes the original threat number to tie it back to the threat model document.
Organize the threats in the report by network, host, and application categories. This makes the report easier to consume for different team members in different roles. Within each category, present the threats in prioritized order starting with the ones given a high risk rating followed by the threats that present less risk.
Summary
While you can mitigate the risk of an attack, you do not mitigate or eliminate the actual threat. Threats still exist regardless of the security actions you take and the countermeasures you apply. The reality in the security world is that you acknowledge the presence of threats and you manage your risks. Threat modeling can help you manage and communicate security risks across your team.
Treat threat modeling as an iterative process. Your threat model should be a dynamic item that changes over time to cater to new types of threats and attacks as they are discovered. It should also be capable of adapting to follow the natural evolution of your application as it is enhanced and modified to accommodate changing business requirements.
Additional Resources
For additional related reading, see the following resources:
- For more information about the latest threat modeling process, see "Threat Modeling Web Applications"
- For information on attack patterns, see "Attack Modeling for Information Security and Survivability," by Andrew P. Moore, Robert J. Ellison, and Richard C. Linger at http://www.sei.cmu.edu/library/abstracts/reports/01tn001.cfm
- For information on evaluating threats, assets and vulnerabilities, see "Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0" on the Carnegie Mellon Software Engineering Institute Web site at http://www.sei.cmu.edu/library/abstracts/reports/99tr017.cfm
- For a walkthrough of threat modeling, see "Architect WebCast: Using Threat Models to Design Secure Solutions" at https://www.microsoft.com/events/webcasts/ondemand.mspx
- For more information on creating DFDs, see Writing Secure Code, Second Edition, by Michael Howard, David C. LeBlanc.
Retired Content |
---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |