How To: Create a Threat Model for a Web Application at Design Time

J.D. Meier, Alex Mackman, Blaine Wastell

Microsoft Corporation

May 2005

Home Page for Threat Modeling Web Applications

• "Cheat Sheet: Web Application Security Frame"
• "Walkthrough: Creating a Threat Model for a Web Application"
• "Template: Web Application Threat Model"
• "Template Sample: Web Application Threat Model"

This How To describes an approach for creating a threat model for a Web application. The threat modeling activity helps you to model your security design so that you can expose potential security design flaws and vulnerabilities before you invest significant time or resources in a flawed design and/or problems become difficult to reverse. This How To provides prioritized vulnerability categories and a threat list to make the threat modeling activity easier.

This How To contains the following information:

Objectives
Overview
How to Use This Module
Input
Output
Steps
What to Do Next
Agile Considerations
MSF Agile Considerations
Additional Resources
Contributors and Reviewers

By performing the steps in this module, you will:

• Identify relevant threats to your particular application scenario.
• Identify key vulnerabilities in your application design.
• Improve your security design.

Threat modeling is a structured activity for identifying and evaluating application threats and vulnerabilities. This How To presents a question-driven approach to threat modeling that can help you identify security design problems early in the application design process. This approach allows you to quickly create a basic threat model for your application scenario. Then you can use this threat model to help refine your application's design early and for communication among team members.

The threat modeling approach presented here focuses on identifying and addressing vulnerabilities. The security objectives, threats, and attacks that you identify in the early steps of the activity are the scoping mechanisms designed to help you find vulnerabilities in your application. You can use the identified vulnerabilities to help shape your design and direct and scope your security testing.

Use this module to quickly create an effective threat model for your application. When using this module, keep the following in mind:

• Do not get blocked on steps or implementation. Focus on the approach. If you do get blocked on a particular step, skip ahead to step 4, "Identify Threats." The primary objective of the activity is to improve security design, not to model for the sake of modeling.

• Use scenarios to scope the modeling activity. Identify scenarios that are out of scope to help limit your threat modeling activity. What are you not going to talk about? For example, are operational practices out of scope?

• Use your existing design documents if you have them. Use items such as documented use cases or user stories, data flow diagrams, architecture diagrams, and other design documentation if you have them.

• Start with a whiteboard. It can be easier to get started by modeling on a whiteboard before you start capturing information in documents or getting lost in details. A helpful technique is to use a digital camera or whiteboard with print capability to document and distribute the information from the whiteboard.

• Use an iterative approach. Add more detail and evolve your threat model as you continue design and development. Use ongoing modeling to reduce risk and to inform your design decisions. For example, when early in the design process, you may have only basic use cases, an initial deployment topology, and an idea of how you will layer your application. By using an iterative approach, you become familiar with the modeling process and can evolve your threat model to examine "what if" scenarios as more information becomes available to you.

  You might choose to adopt a more formal approach and identify milestones for revisiting your model. What is most important is that you revisit the model when you need to make an engineering decision, as you introduce new levels of risk, and when you contemplate significant design choices.

• Review and use the Template: Web Application Threat Model. Use the companion template while creating your threat model. The template includes exit criteria for each step described in this How To.

• Use the Cheat Sheet. Use the companion document, "Cheat Sheet: Web Application Security Frame," to help you identify threats and vulnerabilities in step 4, "Identify Threats," and step 5, "Identify Vulnerabilities." The cheat sheet contains sample threats, attacks, vulnerabilities, and countermeasures.

• Adapt the activity for your situation. If you are new to threat modeling, consider reading this document and then reading the companion walkthrough, "Walkthrough: Creating a Threat Model for a Web Application," to become more familiar with the approach. If you have existing applications, you can use the threat and vulnerability identification approaches in steps 4 and 5. With this information, you can determine where to focus your efforts.

• Obtain input about host and network constraints from your system and network administrators. To be able to draw and understand your end-to-end deployment scenario, you need to have information about the host configuration, firewall policies, allowed protocols and ports, and so on. Obtain this information by talking to your system and network administrators.

The following input is useful for threat modeling:

• Use cases and usage scenarios
• Data flows
• Data schemas
• Deployment diagrams

Although all of these are useful, none of them are essential. However, you do need to have knowledge of your application's primary function and architecture.

The output of the threat modeling activity is a threat model. The main items captured by the threat model include the following:

• A list of threats
• A list of vulnerabilities

The five major threat modeling steps are shown in Figure 1.

Figure 1. The iterative threat modeling process

These steps are:

• Step 1: Identify security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on subsequent steps.
• Step 2: Create an applicationoverview. Itemizing your application's important characteristics and actors helps you to identify relevant threats during step 4.
• Step 3: Decompose your application. A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant and more detailed threats.
• Step 4: Identify threats. Use details from steps 2 and 3 to identify threats relevant to your application scenario and context.
• Step 5: Identify vulnerabilities. Review the layers of your application to identify weaknesses related to your threats. Use vulnerability categories to help you focus on those areas where mistakes are most often made.

You add progressively more detail to your threat model as you move through your application development life cycle and discover more details about your application design. Because key resources identified in threat modeling are also likely to be key resources from a performance and functionality perspective, you can expect to revisit and adjust your model as you balance all of your needs. This is normal and is a valuable outcome of the process.

Security objectives are goals and constraints related to the confidentiality, integrity, and availability of your data and application. They include:

• Confidentiality. This includes protecting against unauthorized information disclosure.
• Integrity. This includes preventing unauthorized information changes.
• Availability. This includes providing the required services even while under attack.

Security-specific objectives are a subset of project objectives, and you should use them to guide your threat modeling efforts. You may find it helpful to think of security objectives in terms of constraints. Consider the question, "What do you not want to happen?" For example, an attacker must not be able to steal user credentials.

By identifying your key security objectives, you can determine where to focus your efforts. Identifying your objectives also helps you to understand the goals of potential attackers and concentrate on those areas of your application that require closer attention. For example, if you identify customer account details as sensitive data that needs protecting, you can examine how securely the data is stored and how access to the data is controlled and audited.

To determine your security objectives, consider the following questions:

• What client data do you need to protect? For example, does your application use user accounts and passwords, customer account details including personalization information, financial history and transaction records, customer credit card numbers, bank details, or travel itineraries?
• Do you have compliance requirements? Compliance requirements may include security policy, privacy laws, regulations, and standards.
• Do you have specific quality of service requirements? Quality of service requirements include availability and performance requirements.
• Are there intangible assets that you need to protect? Intangible items include your company's reputation, trade secrets, and intellectual property.

The following are examples of some common security objectives:

• Prevent attackers from obtaining sensitive customer data, including passwords and profile information.
• Meet service-level agreements for application availability.
• Protect the company's online business credibility.

In this step, you outline what your Web application does. Your goal is to identify your application's key functionality, characteristics, and clients. This will help you to identify relevant threats during step 4.

Note   Remember that threat modeling is an iterative process. Do not let this step block your progress. Identify as much detail as you can and then add more detail as your design evolves. For example, if you are in the middle of your design and have not tackled physical deployment, you can still perform this step, although with less data. Itemize what you can as soon as you can.

To create an application overview:

• Draw the end-to-end deployment scenario.
• Identify roles.
• Identify key usage scenarios.
• Identify technologies.
• Identify application security mechanisms.

The next sections describe each of these.

Use a whiteboard to draw the end-to-end deployment scenario. First, draw a rough diagram that describes the composition and structure of your application, its subsystems, and its deployment characteristics. Add details about the authentication, authorization, and communication mechanisms as you discover them. Remember that you may not have all of the details early in the design process.

Figure 2 is an example of an initial whiteboard diagram that shows the application architecture with some details.

Figure 2. Example whiteboard drawing depicting an application architecture

Your deployment diagram should generally include the following:

• End-to-end deployment topology. Show the layout of the servers and indicate intranet, extranet, or Internet access. Start with logical network topologies, and then refine this to show physical topologies when you have those details. You can add or remove threats depending on your choice of specific physical topologies.
• Logical layers. Show where the presentation layer, business layer, and data access layers reside. Refine this to include physical server boundaries when you know them.
• Key components. Show the important components within each logical layer. Refine this to include actual process and component boundaries when you know them.
• Key services. Identify any important services. Show these as processes when you know them.
• Communication ports and protocols. Show which servers, components, and services communicate with each other and how they do it. Show the specifics of inbound and outbound information packages when you know them.
• Identities. Show the main identities used for the application and any relevant service accounts if you have this information.
• External dependencies. Show the dependencies that your application has on external systems. Later in the modeling process, this will help you identify vulnerabilities that can arise if any assumptions you make about the external systems are false or if the external systems change in any way.

Note   As your design evolves, you should regularly revisit the threat model to add more detail. For example, you might not know all of the components initially. Subdivide your application as necessary to get enough detail to find your threats.

Identify your application's roles: that is, identify who can do what within your application. What can your users do? What higher-privileged groups of users do you have? For example, who can read data, who can update data, who can delete data?

Use role identification to determine both what is supposed to happen and what is not supposed to happen.

What are the important features of your application? What does it do? Use your application's use cases to derive this information. Identify the dominant application functionality and usage, and capture the Create, Read, Update, and Delete aspects.

Key features are often explained in the context of use cases. They can help you and others to understand how your application is intended to be used and how it can be misused. Use cases help you identify data flows and provide focus when you identify threats later in the modeling process.

Avoid attempting to list every possible use case. Instead, start by identifying the main use cases that exercise the predominant Create, Read, Update, and Delete functionality of your application. For example, a self-service, employee human resources application might include the following use cases:

• Employee views financial data.
• Employee updates personal data.
• Manager views employee details.
• Manager deletes employee records.

In these cases, you can look at the possibilities of the business rules being misused. For example, consider a user trying to modify personal details of another user. You often need to consider several use cases happening simultaneously to perform a complete analysis.

Also identify what scenarios are out of scope, and use your key scenarios to constrain the discussion. For example, you might decide that operational practices, such as backup and restore, are out of scope for the initial threat modeling exercise.

Where you can identify them, list the technologies and key features of the software and technologies that you use. Identify the following:

• Operating systems
• Web server software
• Database server software
• Technologies used in the presentation, business, and data access layers
• Development languages

Identifying technologies helps you to focus on technology-specific threats later in the threat modeling activity. It also helps you determine the correct and most appropriate mitigation techniques.

Identify any key points that you know about the following:

• Input and data validation
• Authentication
• Authorization
• Configuration management
• Sensitive data
• Session management
• Cryptography
• Parameter manipulation
• Exception management
• Auditing and logging

The purpose of this effort is to identify interesting details and be able to add detail where necessary, or to identify where you might need to learn more.

For example, you might know how your application is authenticated by the database or how your users are authorized. You might know the other areas where your application performs authentication and authorization. You might also know certain details about how input validation is to be performed. Highlight these and other key elements of your application security mechanisms.

In this step, you break down your application to identify trust boundaries, data flows, entry points, and exit points. The more you know about the mechanics of your application, the easier it is to uncover threats and discover vulnerabilities. To decompose your application:

• Identify trust boundaries.
• Identify data flows.
• Identify entry points.
• Identify exit points.

The next sections describe each of these.

Identify your application's trust boundaries to help focus your analysis on areas of concern. Trust boundaries indicate where trust levels change. You can think of trust from the perspective of confidentiality and integrity. For example, a change in access control levels in your application where a specific role or privilege level is required to access a resource or operation would be a change in trust level. Another example would be at an entry point in your application where you might not fully trust the data passed to the entry point.

To help identify trust boundaries:

• Start by identifying your outer system boundaries. For example, your application can write to files on server X, it can make calls to the database on server Y, and it can call Web service Z. This defines your system boundary.
• Identify access control points or the key places where access requires additional privileges or role membership. For example, a particular page might be restricted to managers. The page requires authenticated access and also requires that the caller is a member of a particular role.
• Identify trust boundaries from a data flow perspective. For each subsystem, consider whether the upstream data flow or user input is trusted, and if it is not, consider how the data flow and input can be authenticated and authorized. Knowing which entry points exist between trust boundaries allows you to focus your threat identification on these key entry points. For example, you are likely to have to perform more validation on data passed through an entry point at a trust boundary.

Some example trust boundaries are:

• A perimeter firewall. The firewall is likely to be the first trust boundary. It moves qualified information from the untrusted Internet to your trusted data center.
• The boundary between the Web server and database server. Your database may or may not be included in your application's trust boundary. Often the Web servers act as a second firewall to the databases. This significantly limits network access to the databases and thereby reduces the attack surface. Describe the network topology within your data center. Do any other applications write to the database? If they do, do you trust those applications? If you trust the applications that write to the database, you may still not want to trust the database—is it protected?
• The entry point into a business component that exposes privileged data (data that should be available to only particular users). In this case, you need an access check to ensure that only the appropriate callers are allowed access. This is a trust boundary.
• The boundary between your application and a third-party service. Do you trust the service's identity? Can you trust the data returned from the service?

Trace your application's data input through the application from entry to exit. You do this to understand how your application interacts with external systems and clients and how internal components interact. Pay particular attention to data flow across trust boundaries and how that data is validated at the trust boundary entry point. Also pay close attention to sensitive data items and how these flow through your system, where they are passed over a network, and where they are persisted.

A good approach is to start at the highest level and then deconstruct the application by analyzing the data flow between individual subsystems. For example, start by analyzing the data flow between your Web application, your middle tier servers, and your database server. Then consider page-to-page and component-to-component data flows.

The entry points of your application also serve as entry points for attacks. Entry points can 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 layers of your application, may exist only 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. Additional levels of checking provides defense in depth but may be costly in terms of money and performance.

Consider the trust levels required to access an entry point and the type of functionality exposed by the entry point. Early in the threat modeling activity, focus your attention on entry points that expose privileged functionality, such as administration interfaces.

Identify the points where your application sends data to the client or to external systems. Prioritize the exit points where your application writes data that includes client input or includes data from untrusted sources, such as shared databases.

In this step, you identify threats and attacks that might affect your application and compromise your security objectives. These threats are the bad effects that could happen to your application. To conduct this identification process, bring members of the development and test teams together to conduct an informed brainstorming session. Use a whiteboard to identify potential threats. Ideally, the team consists of application architects, security professionals, developers, testers, and system administrators.

You can use two basic approaches:

• Start with common threats and attacks. With this approach, you start with a list of common threats grouped by application vulnerability categories. Next, apply the threat list to your own application architecture. While doing this, use the data you gathered. For example, use the identified scenarios to review data flows, paying particular attention to entry points and where trust boundaries are crossed. You will be able to eliminate some threats immediately because they do not apply to your application and its use cases. Use the "Cheat Sheet: Web Application Security Frame" as a starting point.
• Use a question-driven approach. A question-driven approach can help you identify relevant threats and attacks. The STRIDE categorization includes broad categories of threats, such as spoofing, tampering, repudiation, information disclosure, and denial of service. You can use the STRIDE model to ask questions related 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 data store? Is sensitive information disclosed when you report an error message or log an event? Could someone deny service?

While identifying threats, examine the application tier by tier, layer by layer, and feature by feature. By focusing on vulnerability categories, you focus on the areas where security mistakes are most frequently made. The threats identified at this stage do not necessarily indicate vulnerabilities. Identify potential threats and the actions that an attacker might try to use to exploit the application.

During this step, you perform the following tasks:

• Identify common threats and attacks.
• Identify threats along use cases.
• Identify threats along data flows.

The next sections describe each of these.

There are a number of common threats and attacks that rely on common vulnerabilities. As a starting point, use the companion document, "Cheat Sheet: Web Application Security Frame." The cheat sheet will help you identify threats and attacks relevant to your application.

The following vulnerability categories were developed by security experts who have examined and analyzed the top security issues across many Web applications. They have been refined with input from Microsoft consultants, product support engineers, customers, and Microsoft partners. This section identifies a set of key questions to ask for each category.

Review authentication by asking the following:

• How could an attacker spoof identity?
• How could an attacker gain access to the credential store?
• How could an attacker mount a dictionary attack? How are your user's credentials stored and what password policies are enforced?
• How can an attacker modify, intercept, or bypass your user's credential reset mechanism?

Review authorization by asking the following:

• How could an attacker influence authorization checks to gain access to privileged operations?
• How could an attacker elevate privileges?

• Review input and data validation by asking the following:
• How could an attacker inject SQL commands?
• How could an attacker perform a cross-site scripting attack?
• How could an attacker bypass input validation?
• How could an attacker send invalid input to influence security logic on the server?
• How could an attacker send malformed input to crash the application?

Review configuration management by asking the following:

• How could an attacker gain access to administration functionality?
• How could an attacker gain access to your application's configuration data?

Review sensitive data by asking the following:

• Where and how does your application store sensitive data?
• When and where is sensitive data passed across a network?
• How could an attacker view sensitive data?
• How could an attacker manipulate sensitive data?

Review session management by asking the following:

• Do you use a custom encryption algorithm, and do you trust the algorithm?
• How could an attacker hijack a session?
• How could an attacker view or manipulate another user's session state?

Review cryptography by asking the following:

• What would it take for an attacker to crack your encryption?
• How could an attacker obtain access to encryption keys?
• Which cryptographic standards are you using? What, if any, are the known attacks on these standards?
• Are you creating your own cryptography?
• How does your deployment topology potentially impact your choice of encryption methods?

Review parameter manipulation by asking the following:

• How could an attacker manipulate parameters to influence security logic on the server?
• How could an attacker manipulate sensitive parameter data?

Review exception management by asking the following:

• How could an attacker crash the application?
• How could an attacker gain useful exception details?

Review auditing and logging by asking the following:

• How could an attacker cover his or her tracks?
• How can you prove that an attacker (or legitimate user) performed specific actions?

Examine each of your application's key use cases that you identified earlier, and examine ways in which a user could maliciously or unintentionally coerce the application into performing an unauthorized operation or into disclosing sensitive or private data.

Ask questions and try to think as an attacker would. Examples of the types of question you should ask include the following:

• How can a client inject malicious input here?
• Is data being written out based on user input or on unvalidated user input?
• How could an attacker manipulate session data?
• How could an attacker obtain sensitive data as it is passed over the network?
• How could an attacker bypass your authorization checks?

Review the key use cases and scenarios, and analyze the data flows. Analyze the data flow between individual components in your architecture. Data flow across trust boundaries is particularly important. A piece of code should assume that any data from outside the code's trust boundary is malicious. The code should perform thorough validation of the data.

When identifying threats associated with data flows, ask the following questions:

• How does data flow from the front end to the back end of your application?
• Which components call which components?
• What does valid data look like?
• Where is validation performed?
• How is the data constrained?
• How is data validated against expected length, range, format, and type?
• What sensitive data is passed between components and across networks, and how is that data secured while in transit?

Note   Use existing documentation if you have it. For example, data flow diagrams (DFDs) and Unified Modeling Language (UML) sequence diagrams can help you to analyze your application and identify data flows.

The previous activities have helped you to identify the more obvious and pervasive security issues. You can now explore additional threats and attacks. (It is helpful to set a time limit so that you do not become blocked by this activity.)

Attack trees and attack patterns are the primary tools that many security professionals use. They allow you to analyze threats in greater depth, going beyond what you already know to identify other threat possibilities.

The categorized lists of known threats only reveal the common, known threats. Additional approaches, such as using threat/attack trees and attack patterns, can help you identify other potential threats.

An attack tree is a way of identifying and documenting the potential attacks on your system in a structured and hierarchical manner. The tree structure gives you a detailed picture of various attacks that the attacker uses to compromise the system. By creating attack trees, you create a reusable representation of security issues that will help to focus your threat and mitigation efforts. Your test team can use the trees to create test plans that validate security design. Architects or developer leads can use the trees to evaluate the security cost of alternative approaches. Developers can use the trees to make informed coding decisions during implementation.

Attack patterns are a formalized approach to capturing attack information in your enterprise. These patterns can help you identify common attack techniques.

When creating an attack tree, assume the role of the attacker. Consider what you must do to launch a successful attack and identify goals and sub-goals of the attack. You can use a hierarchical diagram to represent your attack tree, or you can use a simple outline. What is important is that you construct something that portrays the attack profile of your application. Then you can evaluate security risks and use the appropriate countermeasures to mitigate them, 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 shows a simple example.

Figure 3. Attack tree example

You can label leaf nodes with AND and OR labels. For example, in Figure 3, both 1.1 and 1.2 must occur for the threat to result in an attack.

Attack trees like the one in Figure 3 have a tendency to become complex quickly. They are also time-consuming to create. An alternative approach is to structure your attack tree using an outline, such as the following.

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.

The following is a more complete example of the outline approach.

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
  

In this step, you review the Web application security frame and explicitly look for vulnerabilities. Focus on the vulnerability categories as you did while identifying threats in the previous step. However, note that the sample questions presented in this section are designed to help you identify vulnerabilities, not threats. A useful way of proceeding is to examine your application layer by layer, considering each of the vulnerability categories in each layer.

Identify authentication vulnerabilities by asking the following:

• Are user names and passwords sent in clear text over an unprotected channel? Is any ad hoc cryptography used for sensitive information?
• Are credentials stored? If they are stored, how are they stored and protected?
• Do you enforce strong passwords? What other password policies are enforced?
• How are credentials verified?
• How is the authenticated user identified after the initial logon?

Review authentication by looking for these common vulnerabilities:

• 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
• Mixing personalization with authentication

Identify authorization vulnerabilities by asking the following:

• What access controls are used at the entry points of the application?
• Does your application use roles? If it uses roles, are they sufficiently granular for access control and auditing purposes?
• Does your authorization code fail securely and grant access only upon successful confirmation of credentials?
• Do you restrict access to system resources?
• Do you restrict database access?
• How is authorization enforced at the database?

Review authorization by looking for these common vulnerabilities:

• Using over-privileged roles and accounts
• Failing to provide sufficient role granularity
• Failing to restrict system resources to particular application identities

• Identify input and data validation vulnerabilities by asking the following:
• Is all input data validated?
• Do you validate for length, range, format, and type?
• Do you rely on client-side validation?
• Could an attacker inject commands or malicious data into the application?
• Do you trust data you write out to Web pages, or do you need to HTML-encode it to help prevent cross-site scripting attacks?
• Do you validate input before using it in SQL statements to help prevent SQL injection?
• Is data validated at the recipient entry point as it is passed between separate trust boundaries?
• Can you trust data in the database?
• Do you accept input file names, URLs, or user names? Have you addressed canonicalization issues?

Review input validation by looking for these common vulnerabilities:

• Relying exclusively on client-side validation
• Using a deny approach instead of allow for filtering input
• Writing data you did not validate out to Web pages
• Using input you did not validate to generate SQL queries
• Using insecure data access coding techniques, which can increase the threat posed by SQL injection
• Using input file names, URLs, or user names for security decisions

Identify configuration management vulnerabilities by asking the following:

• How do you protect remote administration interfaces?
• Do you protect configuration stores?
• Do you encrypt sensitive configuration data?
• Do you separate administrator privileges?
• Do you use least privileged process and service accounts?

Review configuration management by looking for these common vulnerabilities:

• Storing configuration secrets, such as connection strings and service account credentials, in clear text
• Failing to protect the configuration management aspects of your application, including administration interfaces
• Using over-privileged process accounts and service accounts

Identify sensitive data vulnerabilities by asking the following:

• Do you store secrets in persistent stores?
• How do you store sensitive data?
• Do you store secrets in memory?
• Do you pass sensitive data over the network?
• Do you log sensitive data?

Review sensitive data by looking for these common vulnerabilities:

• Storing secrets when you do not need to store them
• Storing secrets in code
• Storing secrets in clear text
• Passing sensitive data in clear text over networks

Identify session management vulnerabilities by asking the following:

• How are session cookies generated?
• How are session identifiers exchanged?
• How is session state protected as it crosses the network?
• How is session state protected to prevent session hijacking?
• How is the session state store protected?
• Do you restrict session lifetime?
• How does the application authenticate with the session store?
• Are credentials passed over the network and are they maintained by the application? If they are, how are they protected?

Review session management by looking for these common vulnerabilities:

• Passing session identifiers over unencrypted channels
• Prolonged session lifetime
• Insecure session state stores
• Session identifiers in query strings

Identify cryptography vulnerabilities by asking the following:

• What algorithms and cryptographic techniques are used?
• Do you use custom encryption algorithms?
• Why do you use particular algorithms?
• How long are encryption keys, and how are they protected?
• How often are keys recycled?
• How are encryption keys distributed?

Review cryptography by looking for these common vulnerabilities:

• Using custom cryptography
• Using the wrong algorithm or a key size that is too small
• Failing to protect encryption keys
• Using the same key for a prolonged period of time

Identify parameter manipulation parameters by asking the following:

• Do you validate all input parameters?
• Do you validate all parameters in form fields, view state, cookie data, and HTTP headers?
• Do you pass sensitive data in parameters?
• Does the application detect tampered parameters?

Review parameter manipulation by looking for these common vulnerabilities:

• Failing to validate all input parameters. This makes your application susceptible to denial of service attacks and code injection attacks, including SQL injection and XSS.
• Including sensitive data in unencrypted cookies. Cookie data can be changed at the client or it can be captured and changed as it is passed over the network.
• Including sensitive data in query strings and form fields. Query strings and form fields are easily changed on the client.
• Trusting HTTP header information. This information is easily changed on the client.

Identify exception management vulnerabilities by asking the following:

• How does the application handle error conditions?
• Are exceptions ever allowed to propagate back to the client?
• What type of data is included in exception messages?
• Do you reveal too much information to the client?
• Where do you log exception details? Are the log files secure?

Review exception management by looking for these common vulnerabilities:

• Failing to validate all input parameters
• Revealing too much information to the client

Identify auditing and logging vulnerabilities by asking the following:

• Have you identified key activities to audit?
• Does your application audit activity across all layers and servers?
• How are log files protected?

Review auditing and logging by looking for these common vulnerabilities:

• Failing to audit failed logons
• Failing to protect audit files
• Failing to audit across application layers and servers

After you complete the threat modeling activity, do the following:

• If you capture your threat model in a document, keep the document lightweight and avoid over-formatting so you can easily update it. Key content should include your security objectives, key scenarios, protected resources, a threat list, and a vulnerability list.
• Use the vulnerabilities to help shape your security design and implementation. For example, developers should notice anti-patterns related to the identified vulnerabilities and use patterns to address the issues.
• Use the vulnerabilities to plan and scope your system testing. For example, testers should test against the vulnerabilities to verify that the development team fixed or addressed all vulnerabilities.
• Track and prioritize vulnerabilities in your work item tracking system.
• If you have high priority threats and you have no corresponding vulnerabilities, you need to make a decision. Without a vulnerability to track and act on, the threat you identified can be easily overlooked. Will you investigate it further to identify vulnerabilities or rule it out of scope or accept the risk?
• Communicate the information you capture to relevant team members. This may include your application development team, your test team, and your network and system administrators.

You should begin the threat modeling exercise early in your project so that the threat model influences the design of your application. To create and update the threat model, develop user stories. A user story describes what the application should do from the point of view of the customer. In this case, you would create stories around the threats, attacks, and security objectives. You should be able to complete a story in a single iteration. You may need to develop new stories as you create and update the threat model.

Consider the following when you plan your stories:

• Early in the project, reduce risk by creating a candidate architecture that supports architecturally significant end-to-end scenarios that exercise all layers of the architecture.
• Create your first threat model for this candidate architecture. This will change, but it is a good starting point.
• Using your threat model to guide you, make changes to your architecture, design, and code to meet your security objectives.
• Create a threat model based on what you know at the time and define a list of questions that need to be addressed in subsequent stories and iterations.
• After you make enough significant changes to the architecture and design, consider creating a story that reflects these changes. Batch together the small changes in the architecture and design and address them together.
• If you need to work with outside security groups, you need to schedule a time to complete the threat model to provide to the external group. These groups tend to provide better input when they understand the entire application.

The Microsoft Solutions Framework (MSF) Agile Software Development processes use the architecture diagrams found in the Microsoft Visual Studio Team System. These processes use scenarios instead of use cases. Therefore, when applying the threat modeling activity to MSF for Agile Software Development or MSF for CMMI Process Improvement, use scenarios and system and logical data center diagrams as input.

For more information about building threat models using the system and logical data center diagrams, see the MSF process guidance or the MSF Web site.

For more information about a related threat modeling process from which the current one has evolved, see Chapter 3, "Threat Modeling," in Improving Web Application Security: Threats and Countermeasures, on MSDN at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh03.asp.

• External Contributors and Reviewers: Andy Eunson; Anil John, Johns Hopkins University - Applied Physics Laboratory; Brian Cowan; Brian Gran, Ascentium Corporation; Darren Simmonds, Ascentium Corporation; David Raphael, Foundstone Professional Services; Jan Drake, Ascentium Corporation; ; Keith Brown, Pluralsight LLC; Manoranjan M Paul; Mark Curphey, Foundstone Professional Services; Michael Panciroli, Ascentium Corporation; Mrinal Bhao, Infosys Technologies Ltd; Pete Coupland, VMC Consulting Corporation; Rudolph Araujo, Foundstone Professional Services;
• Microsoft Services and PSS Contributors and Reviewers: Kate Baroni; Maarten Van De Bospoort
• Microsoft IT Contributors and Reviewers: Shawn Veney
• Microsoft EEG Contributors and Reviewers: Corey Ladas
• Microsoft Product Group Contributors and Reviewers: Don Wilits; Randy Miller; Rico Mariani
• Microsoft patterns & practices Contributors and Reviewers: Edward Jezierski; Jason Hogg; Jonathan Wanagel; Larry Brader; Naveen Yajaman
• Test team: Sivanthapatham Shanmugasundaram (Infosys Technologies Ltd).
• Edit team: Sharon Smith (Linda Werner & Associates Inc), Tina Burden McGrayne (Linda Werner & Associates Inc).

Start | Previous | Next