As I mentioned in my previous four posts, Create a Threat Model - Step 1, Create a Threat Model - Step 2, Create a Threat Model - Step 3, and Create a Threat Model - Step 4, there are five major threat modeling steps, as shown below in Figure 1. This article explains the fifth step, Identify Vulnerabilities.

Figure 1. The iterative threat modeling process

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.

MSF Agile Considerations

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.

Adapted from Microsoft patterns & practices guidance.

Create a Threat Model - Step 5