Threat Modeling

As the name suggests, threat modeling is the process of systematically deriving the key threats relevant to an application, in order to efficiently identify and mitigate potential security weaknesses before releasing it. In its simplest form, threat modeling can be a series of meetings between development team members (including intra- or extraorganizational security expertise as needed) where such threats and mitigation plans are discussed and documented.

Threat modeling is best employed during the design phase of development, since its results almost always influence the rest of the development process (coding, testing, and so on). The threat model should also be revisited before release, and following any significant update. Figure 12-1 illustrates an optimal threat modeling schedule. Based on the experiences of major software companies who have implemented it, threat modeling is one of the most critical steps you can take to improve the security of your web applications .

Figure 12-1: An example threat modeling schedule mapped to a hypothetical development process

The detailed process of threat modeling software applications is best described in Writing Secure Code, 2 ^nd Edition and Threat Modeling , the seminal works on the topic (see "References and Further Reading" at the end of this chapter for more information). The basic components of the methodology are as follows ( adapted from the "Security Across the Software Development Lifecycle Task Force" report at http://www.itaa.org/software/docs/SDLCPaper.pdf and from our own experience implementing similar processes for our consulting clientele):

• Clarify security objectives to focus the threat modeling activity and determine how much effort to spend on subsequent steps.

• Identify assets protected by the application (it is also helpful to identify the confidentiality, integrity, availability, and audit-logging (CIAA) requirements for each asset).

• Create an architecture overview (this should at the very least encompass a data flow diagram, or DFD, that illustrates the flow of sensitive assets throughout the product and related systems).

• Decompose the application, paying particular attention to security boundaries (for example, application interfaces, privilege use, authentication/ authorization model, logging capabilities, and so on).

• Identify and document threats.

• Rank the threats using a systematic metric.

• Develop threat mitigation strategies for the highest ranking threats.

• Implement the threat mitigations according to the agreed-upon schedule.

  Tip 

  Microsoft publishes a threat-modeling tool that can be downloaded from the link provided in "References and Further Reading" at the end of this chapter.

In this section we will illustrate this basic threat-modeling methodology as it might be applied to a sample web application: a standard online bookstore shopping cart, which has a two- tier architecture comprised of a frontend web server and a backend database server. The database server contains all the data about the customer and the items that are available for purchase online; the front end provides an interface to the customers to log in and purchase items.

Clarify Security Objectives

Although it may seem obvious, we have found that documenting security objectives can make the difference between an extremely useful threat model and a simply mediocre one. Setting concise objectives sets an appropriate tone for the exercise: what's in scope and what's out, what are priorities and what are not, what are musts vs. coulds vs. shoulds, and last but not least, the all-important "what will help you sleep better at night." We've also found that this clarification lays the foundation for subsequent steps (for example, identifying assets), since newcomers to threat modeling often have unrealistic security expectations and have a difficult time articulating what they don't want to protect. Having a solid list of security objectives really helps constrain things to a reasonable scope.

Identify Assets

Security begins with first understanding what it is that you're trying to secure. Thus, the foundational step of threat modeling is inventorying the application assets. For web applications, this is usually a straightforward exercise: our sample application contains valuable items such as customer information (possibly including financial information), user and administrative passwords, and business logic. The development team should list all of the valuable assets protected by the application, ranked by sensitivity. This ranking can usually be obtained by considering the impact of loss of confidentiality, integrity, or availability of each asset. The asset inventory should be revisited in the next step to ensure that the architecture overview and related data flow diagrams properly account for the location of each asset.

Architecture Overview

A picture is worth a thousand words, and threat modeling is no exception. Data flow diagrams (DFDs) greatly help determine security threats by modeling the application in a visually meaningful manner, and are one of the primary benefits of the full-knowledge approach over black-box (since it's unlikely that black-box testers would have access to detailed DFDs). We usually find that level 0 (overview) and level 1 (component-level) DFDs are the minimal necessary for this purpose. The level 0 and level 1 DFDs for our hypothetical shopping cart application are shown in Figures 12-2 and 12-3.

Figure 12-2: Level 0 DFD for our hypothetical shopping cart web application

Figure 12-3: Level 1 DFD

The browser sends a request to log in to the site with the credentials, the credentials are passed back to the backend database that verifies the credentials and sends back a response to the web server. The web server, based on the response received from the database, either displays a success page or displays an error. If the request is successful, the web server also sets a new cookie value and a session ID on the client. The client can then make additional requests to the site to add to his shopping cart or update his profile and checkout.

Decompose The Application

Now that the application has been broken down into functional components, the next step is to decompose the application further to indicate important security (or trust) boundaries, including user and programmatic interfaces, privilege use, authentication/ authorization model, logging capabilities, and so on. Figure 12-4 shows our level 1 DFD with the relevant security boundaries overlaid. All the dashed lines are entry points. The box represents the security/trust boundaries.

Figure 12-4: Level 1 with Trust boundaries and entry points

Identify And Document Threats

With our visual representation of the application, including security boundaries and entry points, we can now begin to determine the threats to the application. The biggest challenge of threat modeling is being systematic and comprehensive, especially in light of ever-changing technologies and emerging attack methodologies. There are no techniques available that can claim to identify 100 percent of the feasible threats to a complex software product, so you must rely on best practices to achieve as close to 100 percent as possible, and use good judgment to realize when you've reached a point of diminishing returns.

The easiest approach is to view the application DFD and create threat trees or threat lists (see "References and Further Reading" for more information on attack/threat trees). Another helpful mechanism is Microsoft's STRIDE model: attempt to brainstorm S poofing, T ampering, R epudiation, I nformation disclosure, D enial of service, and E levation of privilege threats for each documented asset inventoried previously. If you considered confidentiality, integrity, availability, and audit-logging (CIAA) requirements when documenting your assets, you're halfway home here: you'll note that STRIDE and CIAA threats are remarkably similar.

It's also very useful to consider known threats against web applications. Internal or external security personnel can assist with bringing this knowledge to the threat-modeling process. Additionally, visiting and reviewing security mailing lists like Bugtraq and security web sites like www.owasp.org could also be used to help create a list of threats. Microsoft publishes a "cheat sheet" of common web application security threats and vulnerability categories (see "References and Further Reading" at the end of this chapter for a link). Of course, the book you're holding is also a decent reference for common web security threats (grin).

Tip 

Don't waste time determining if/how these threats are/should be mitigated at this point; that comes later, and you can really derail the process by attempting to tackle mitigation at this point.

Here is a sample threat list for the shopping cart application:

• Authentication

  • Brute-force credential guessing.

• Session Management

  • Session key might be easily guessable.

  • Session key doesn't expire.

  • Secure cookie is not implemented.

• Attacker able to view another user's cart

  • Authorization may not be implemented correctly.

  • User may not have logged off on a shared PC.

• Improper input validation

  • SQL injection to bypass authentication routine.

  • Message board allows for cross-site scripting (XSS) attack to steal credentials.

• Error Messaging

  • Verbose error messages display SQL errors.

  • Verbose error messages display invalid message for invalid username and invalid password.

  • Verbose error message during authentication enables enumeration of users.

• SSL not enforced across the web site

  • Allows eavesdropping on sensitive information.