Threat Modeling

Summary of the book: https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998

Overall a superb introduction to the activity of performing threat modeling of software. Although, some chapters do feel like filler content, and the crux of the topic lies in a handful of chapters.

Threat Modeling of the System

The purpose of threat modeling is to elicit the possible attacks that a threat actor can perform towards your system. Attacks are different from Attack Vectors. An attack vector is a surface that is a target for attacks, and can be subjected to multiple distinct attacks.

To find out the attack vectors of your system, we need to first model your system in a way that can be analyzed. Diagrams can help to represent the system in a structured way for the threat modeling activity. Some types of diagrams are:

  • Data flow diagrams
  • Swim lane diagrams
  • State diagrams

Choosing the appropriate diagram to best represent the system should be done. The diagram should be structured from a Software system point of view, meaning to say the entities in the diagrams should consist of your software components (web server, database, authentication etc.)

Once the diagram has been laid out, we then identify boundaries, which are layers of abstraction that delineates the system into logical components. The the type of separations are done mostly via trust boundaries, which represents groups of systems within the same trust-level (For example, all backend systems are within a single trust boundary. However, even within the backend systems there can be more granular trust boundaries.)

To identify attacks across and within these boundaries, we use STRIDE to hypothesize attacks that are possible.

STRIDE

One of the most important concept behind threat modeling is STRIDE, which is an acronym for

  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privilege
AttackIn Violation of
SpoofingAuthentication
Tampering Integrity
Repudiation Non-Repudiation
Information Disclosure Confidentiality
Denial of Service Availability
Elevation of PrivilegeAuthorization

Another variant of it, STRIDE-LM, adds Lateral Movement to its attack vector, and that violates Authorization.

When to Threat Model

  • At the planning stage of the architecting and building the system
  • As new features are being developed and added
  • As the system is close to delivery

Threat Modeling should be done Top-Down, taking into account the entire system, before going down to the components. Threat Modeling should not be done bottom up from the features.

When doing Threat Modeling at the development phase, notes and comments should be added along side the code, as well as verbose error/warning messages, to inform the users of the possible security risks.

Risk Management

There are a number of ways to management risk

MethodExplanation
Avoiding RiskAvoid the risk by not doing it at all i.e. don’t build the feature, and it will never be compromised
Addressing RiskAddress the risk through design considerations
Accepting RiskAccept that things will go wrong, and be prepared to pay the cost
Transferring RiskRisks is pushed onto the users/customers. EULA does this, where the customer accepts it
Ignoring RiskTurning a blind-eye to the risk

Testing Threat Mitigation

After you how identified the threats, and chosen the appropriate risk management strategy, you need to test it’s effectiveness. This should be done along side the testing phase of the software, and ideally part of the CI/CD pipeline (DevSecOps).

Levels of Threat Model Measurement

RatingComments
0 – No Threat ModelThreat Modeling is not even done
1 – Not AcceptableOut of date Threat Model, diagrams, documentations and scenarios
2 – OkayUpdated diagrams, at least 1 threat identified per asset
3 – GoodAll in Okay + S,T,I,E properly covered. Covered Remote users.
4 – ExcellentAll in Good + S,T,R,I,D,E properly covered.
Threat Model done in all stages (Planning, Development, Close to shipping)

Threats to Threat Modeling

ThreatComment
Having Dangerous DeliverablesForcing enumeration of all assumptions, which is impossible
Forcing Threat Model reports as a final deliverable, when its an ongoing process
Having Dangerous ApproachesCargo Culting – Going through the motion, but never taking it seriously
Thinking that there is a best way to Threat Model
Not having done it before, and therefore never doing it

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s