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
| Attack | In Violation of |
| Spoofing | Authentication |
| Tampering | Integrity |
| Repudiation | Non-Repudiation |
| Information Disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorization |
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
| Method | Explanation |
| Avoiding Risk | Avoid the risk by not doing it at all i.e. don’t build the feature, and it will never be compromised |
| Addressing Risk | Address the risk through design considerations |
| Accepting Risk | Accept that things will go wrong, and be prepared to pay the cost |
| Transferring Risk | Risks is pushed onto the users/customers. EULA does this, where the customer accepts it |
| Ignoring Risk | Turning 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
| Rating | Comments |
| 0 – No Threat Model | Threat Modeling is not even done |
| 1 – Not Acceptable | Out of date Threat Model, diagrams, documentations and scenarios |
| 2 – Okay | Updated diagrams, at least 1 threat identified per asset |
| 3 – Good | All in Okay + S,T,I,E properly covered. Covered Remote users. |
| 4 – Excellent | All 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
| Threat | Comment |
| Having Dangerous Deliverables | Forcing enumeration of all assumptions, which is impossible Forcing Threat Model reports as a final deliverable, when its an ongoing process |
| Having Dangerous Approaches | Cargo 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 |
Code of The Day 
Leave a Reply