Secure Development - SAMM - Threat Assessment

While the SAMM model lists Governance as the first business function, we will start with the Construction and Verification functions since they address some of the more traditional and well-known aspects of the software development lifecycle. Once we have explored these functions, the infrastructure discussed in the Deployment and Governance functions is a logical extension.

The Construction function consists of three security practices: Threat Assessment, Security Requirements, and Secure Architecture. In this post, we will start with Threat Assessment, which is the process of determining the specific security threats facing your applications and infrastructure. The results of this process form the basis for the defenses that will need to be built into your development process and infrastructure, and these defenses can vary widely depending on the circumstances. Without a proper threat assessment, security measures and spending are often based on (questionable) assumptions, and you may end up protecting against insignificant threats in some areas, but neglecting real threats in other areas.

At the first maturity level, SAMM recommends the following two activities: 1) threat modeling for each specific application under development and 2) building an attacker profile based on your software architecture. 1. Threat modeling for an application can take many different forms, both formal and informal. A simple approach is an attack tree (described in more detail in SAMM), which lists out the various worst-case scenarios and all of the ways in which an attacker might be able to achieve them. 2. When building attacker profiles, consider only malicious intent, both from inside and outside threats. List potential attackers by their role/relationship to the organization and also include their likely motivation(s). Typically, attacker profiles are very similar across applications of the same general architecture, so it may not be necessary to build a separate profile for each application.

To help clarify these concepts, here is a sample threat model and attacker profile (both are extremely simple and general for brevity):

Threat Model (simple attack tree)

Threat: Private customer data is disclosed to an unauthorized third party
Preconditions (each is a branch of the tree):

1. Attacker eavesdrops on unencrypted communication between company server and customer OR
2. Attacker obtains valid login credentials to company network AND
3. Attacker uses credentials to access company's network and customer database OR
4. Attacker exploits a web application vulnerability to access customer data via the Internet

For additional examples of threat modeling, see this article by Bruce Schneier and this MSDN article.

Attacker Profile

External Attacker: Employee of a competing company
Motivation: Obtain proprietary trade information, such as product specifications, formulas, and computer algorithms/software

Internal Attacker: Greedy or financially unstable employee
Motivation: Divert company funds for personal profit or to repay debts

At the second maturity level, both of these items are enhanced: 1) add specific abuse cases to your threat model for each application/project, based on the normal usage scenarios (use-case diagrams, etc.) and 2) develop a weighting system for each attacker/threat identified in the original attacker profile, then use these weights to prioritize your security efforts.

The third maturity level takes this approach to its logical conclusion by recommending 1) a full threat model with compensating controls assigned to each threat, along with 2) a detailed evaluation of risk from third-party components in your environment. 1. For each precondition in your threat model, develop one or more compensating controls (a technical or process control) to directly mitigate the risk. In our example above, a compensating technical control for precondition 1 (eavesdropping) is to encrypt all web traffic containing private customer data. 2. The threat from third-party software is often overlooked, but it should be subject to at least the same level of "distrust" as your internal code, if not more. To address this risk, update your threat models and attacker profiles to factor in potential design flaws and vulnerabilities in third-party software. If the third-party code happens to be open-source, you can gain additional assurances about its level of security by performing code analysis and reviews (either automated or manual).

Threat Assessment is an important first step in understanding what exactly you need to protect, and from whom. Without such an assessment, security measures are often hit-and-miss and may not address your most important security priorities. Next time, we will discuss how Security Requirements are used as the entry point to ensure that security follows development throughout the lifecycle.