How To Use Threat Modeling to Explore Threats and Countermeasures

“Those that are the loudest in their threats are the weakest in their actions.” — Charles Caleb Colton

You can learn the basics of Threat Modeling to help you evaluate threats for any situation.

Simply remember the following mantra to whittle any situation down to size:

Map out the threats, attacks, vulnerabilities, and countermeasures.

Whether you are facing a pandemic, designing a product, managing a property, or whatever, you will find that Threat Modeling is a very helpful and methodical way to explore and identify potential risks.

In this article, I’m going to use the example of Threat Modeling an app to make it concrete, but the same basic approach and ideas apply to anything you want to Threat Model.

What is Threat Modeling

Threat modeling is an approach you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that might be relevant to your application.

The Threat Modeling activity helps you to recognize and identify the following:

• Your security objectives
• Relevant threats
• Relevant vulnerabilities and countermeasures

Key Terms

It helps to know the following terms when you are working through Threat Modeling:

• Threat. A threat is an undesired event or potential occurrence, often best described as an effect that could damage or compromise an asset or objective. It may or may not be malicious in nature.
• Attack (or exploit). An attack is an action taken that uses one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
• Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an attack possible. Vulnerabilities can exist at the network, host, or application level and include operational practices.
• Countermeasure. A countermeasure addresses a vulnerability to reduce the probability of attack or the impact of a threat. A countermeasure does not directly address a threat. Instead, it addresses the factors that define the threat. Countermeasures range from improving application design or improving code, to improving an operational practice.
• Asset. An asset is a resource that has value. It varies by perspective. To your business, an asset might be the availability of information or the information itself, such as customer data. It might be intangible, such as your company’s reputation. To an attacker, an asset could be the ability to misuse your application for unauthorized access to data or privileged operations.

Threat Modeling Turns Paranoia Into Pragmatic Action

Once you learn how to Threat Model, you will never look at situations the same way again.

Threat Modeling helps turn paranoia into pragmatic action.

Threat Modeling gives you a systematic way to walk through threats, attacks, vulnerabilities, and countermeasures.  And it helps you look at scenarios and situations with new perspectives and lenses, to better understand how bad things might happen.

To bottom line it, Threat Modeling helps you address potential threats versus just hope for the best.

The Mindset and Cornerstone Concepts for Better Threat Modeling

When you build a Threat Model, it helps to remember that the whole point of the exercise is to manage risk.

Just like scenario planning for future business scenarios, Threat Modeling helps identify potential issues in the future that you will want to address in your approach, design, or implementation.

Here are a few cornerstone concepts to keep in mind as you approach Threat Modeling:

• Modeling to reduce risk – Use Threat Modeling to identify when and where you should apply effort to eliminate or reduce a potential threat. Avoid wasted effort by threat modeling to clarify the areas of most risk.
• Incremental rendering – Perform Threat Modeling iteratively. You should not be too concerned about missing details in any single iteration — instead focus on making each iteration productive.
• Context precision – Understand application use cases and roles in order to identify threats and vulnerabilities that are specific to your application. Different application types, application usage, and roles can yield different threats and vulnerabilities.
• Boundaries – Establish boundaries in order to help you define constraints and goals. Boundaries help you identify what must not be allowed to happen, what can happen, and what must happen.
• Entry and exit criteria – Define entry and exit criteria to establish tests for success. You should know before you start what your Threat Model will look like when complete (good enough) and when you have spent the right amount of time on the activity.
• Communication and collaboration tool – Use the Threat Model as a communication and collaboration tool. Leverage discovered threats and vulnerabilities to improve shared knowledge and understanding.
• Pattern-based information model – Use a pattern-based information model to identify the patterns of repeatable problems and solutions, and organize them into categories.
• Key engineering decisions – Expose your high-risk engineering decisions and design choices with your Threat Model. These high-risk choices are good candidates for focusing prototyping efforts.

Let’s Blitz the Big Ideas of Threat Modeling

First, let’s get some grounding in the big ideas of Threat Modeling so you don’t get lost in the mechanics.

The goal of Threat Modeling is simply to manage risk better, by exploring how something might be attacked or how something might go wrong, intentionally, or unintentionally.

Here are some of the big ideas to keep in mind:

• It’s a mapping exercise.  Threat Modeling is an exercise in mapping out the threats, attacks, vulnerabilities, and the countermeasures for a given scenario or a situation or a particular thing.
• Rate and rank threats.  Ultimately, you will rate and rank the potential and the impact for a given threat that you identify.   This alone is a powerful tool for translating chaos into clarity.  Anybody can come up with a laundry list of bad things that could happen.  But the real value is in identifying the high impact and high probability threats so that you can focus your time and effort better.
• It’s a game of risk management.  It’s a dilemma to be managed, not a problem to be solved.  Will you figure out everything that can go wrong?  No.  But will you learn a lot in the process of brainstorming what can go wrong?  Yes.  And will you be able to prevent all the things that you do figure out that can go wrong?  No.   But will you be able to make better decisions about what to focus on?  Yes.  And what you can’t prevent, maybe you can mitigate in some way, or slow down the damage, or respond more effectively.
• Vulnerabilities are highly actionable.    Sometimes people get lost in their Threat Models or lose sight of where the gold is.  A chain is as strong as its weakest link.  Vulnerabilities are your weak links in the chain.  When you identify vulnerabilities as part of your Threat Modeling, you are basically mapping out where to focus to address vulnerabilities and to apply countermeasures.
• Threat modeling is better with expert knowledge.  It can be very difficult to imagine some of the types of things that could go wrong, or how they can even happen.  It really helps to have some experts you can bounce ideas around with, and to brainstorm threats, attacks, vulnerabilities, and countermeasures.  Access to experts helps you Threat Model better, but don’t ever let a lack of experts limit your ability to learn and get started.   It’s a skill you can build and grow for life.

The bottom line is Threat Modeling helps you better prepare for future and emerging threats, and it helps you respond better to the changing world around you, because you will be surprised less, by exploring potential threats through additional lenses and perspectives.

Where Does Threat Modeling Fit In?

Use it wherever you need it.

But for the sake of this example, let’s imagine we’re building apps.  Threat Modeling begins early in the architecture and design phase of the application life cycle.

It is performed with knowledge of your security objectives. Your security objectives are a key part of your business objectives and they are used to determine the extent of the Threat Modeling activity and where to spend the most effort.

As the life cycle progresses and your design and development evolve, you progressively add more detail to your threat model. Threat modeling is iterative, and you need to repeat the process as indicated by the following:

• Increase the detail of your model whenever new environmental facts become known.
• While you develop, increase the detail of your model as design and implementation decisions reveal new facts.
• Add detail as new uses and configurations of the application appear. This is during the application lifetime including after the application is in production and is maintained by the operations team.

Add information to the model as it becomes available to you, and keep identifying what you now know and what you need to know next.

Why Use Threat Modeling

You use Threat Modeling to identify when and where more resources are required (or justified) to reduce risks. There are many possible vulnerabilities, threats, and attacks, and it is unlikely that your application will encounter all of them.

It is also unlikely that your company would need to address all of them. Threat Modeling helps you to identify where your organization needs to apply effort.

Threat Modeling helps you to:

• Shape your application design to meet your security objectives.
• Make engineering decisions that weigh security goals against other design goals.
• Address and improve the quality of your engineering efforts by eliminating common vulnerabilities.
• Improve quality of service by implementing necessary and effective countermeasures.
• Reduce risk of security issues arising during development and operations.

With that in mind, let’s learn the basic approach of building a Threat Model…

Threat Modeling Activity Summary Table

Here is a summary of a simple Agile Threat Modeling approach.  It’s iterative, incremental, and focused on learning loops, while evaluating risks of use cases and user stories.

Step	Inputs	Outputs
Step 1: Identify security objectives	Business requirements Security policies Compliance requirements	Key security objectives
Step 2: Create an application overview	Deployment diagrams Use cases Functional specifications	Whiteboard-style diagram with end-to-end deployment scenario Key scenarios Roles Technologies Application security mechanisms
Step 3: Decompose your application	Deployment diagrams Use cases Functional specifications Data flow diagrams	Trust boundaries Entry points Exit points Data flows
Step 4: Identify threats	Common threats	Threat list
Step 5: Identify vulnerabilities	Common vulnerabilities	Vulnerability list

Threat Modeling Overview

Knowing the overview of the inputs, outputs, and steps helps a lot to ground you in the basic approach.  But to really internalize the approach, let’s really light it up by walking through a simple method for doing Threat Modeling.

Again, this is rooted in an example of Threat Modeling an app, but you can apply the main idea of mapping out threats, attacks, vulnerabilities, and countermeasures to any high risk stakes situation or scenario where you want to better understand what can go wrong, and how to better plan, better prepare, and better respond.

The five major threat modeling steps are shown below. You should progressively refine your threat model by repeatedly performing steps 2 through 5.

You will be able to add more detail as you move through your application development life cycle and discover more about your application design.

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 application overview. 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.

Step 1: Identify Security Objectives

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.

Step 2: Create an Application Overview

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.

Draw the End-to-End Deployment Scenario

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.

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 Roles

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.

Identify Key Usage Scenarios

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.

Identify Technologies

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 Application Security Mechanisms

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.

Step 3: Decompose Your Application

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 Trust Boundaries

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?

Identify Data Flows 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.

Identify Entry Points

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 Exit Points

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.

Step 4: Identify Threats

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 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.

Identify Common Threats and Attacks

There are a number of common threats and attacks that rely on common vulnerabilities. As a starting point, create a cheat sheet of common threats and attacks, and you can build on it and modify from real usage, and you can socialize with experts to supplement your information.

Web Application Security Frame

The following vulnerability categories were developed by security experts who have examined and analyzed the top security issues across many Web applications. This section identifies a set of key questions to ask for each category.

• Authentication

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?

• Authorization

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?

• Input and Data Validation

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?

• Configuration Management

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?

• Sensitive 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?

• Session Management

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?

• Cryptography

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?

• Parameter Manipulation

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?

• Exception Management

Review exception management by asking the following:

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

• Auditing and Logging

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?

Identify Threats Along Use Cases

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 non-validated 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?

Identify Threats Along Data Flows

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.

Explore Additional Threats by Using Threat/Attack Trees

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.

Creating Attack Trees

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.

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

Attack trees like the one in the future 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

Step 5: Identify Vulnerabilities

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.

Authentication

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

Authorization

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

Input and Data Validation

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

Configuration Management

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

Sensitive Data

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

Session Management

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

Cryptography

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

Parameter Manipulation

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.

Exception Management

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

Auditing and Logging

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

What to Do Next

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.

Agile Considerations

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 more you practice, the better you get.

And the better you get, the more prepared you are, for the unexpected.

You Might Also Like

Agile Security Engineering

How I Created Super Successful Software

How I Explain Threat Modeling to Customers

How To Improve Business Agility with User Stories

Threat Modeling Terms and How To Use Them