Threat Modeling
Threat modeling is the structured search for what can go wrong in a system before it is built. The four questions, STRIDE and attack trees, and how it feeds a pentest.
Updated This page as Markdown
In short
Threat modeling is a structured analysis of a system's design that identifies assets, trust boundaries, possible attackers and the threats they pose, and derives countermeasures and test cases. It answers four questions: what are we building, what can go wrong, what do we do about it, did we do a good job. Methods such as STRIDE and attack trees give it structure; in automotive the formalised variant is the TARA of ISO/SAE 21434.
What is threat modeling?
Threat modeling is the practice of looking at a system from the attacker’s side before the attacker does. The Threat Modeling Manifesto summarises it as four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?
The working material is a model of the system, usually a data flow diagram with processes, data stores, external entities, data flows and trust boundaries. For every element and every boundary you ask what an attacker could do. STRIDE gives six categories to check: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Attack trees take one attacker goal and break it down into the steps and alternatives that reach it. The output is a list of threats with their severity, the countermeasures you decided on, and the open items that become requirements and test cases.
Where is it defined?
There is no single standard; several bodies describe the practice. OWASP maintains the Threat Modeling Cheat Sheet and the community page with methods and tools. Microsoft documents STRIDE and its Threat Modeling Tool. The Threat Modeling Manifesto (2020) records the values and principles agreed by practitioners. In regulated domains the practice is formalised: ISO/SAE 21434 Clause 15 turns it into the TARA with fixed rating scales for road vehicles; IEC 62443-3-2 requires a risk assessment per zone and conduit for industrial systems; the Cyber Resilience Act requires in Article 13 that manufacturers undertake a cybersecurity risk assessment and keep it as part of the technical documentation.
What it means in practice
A threat model pays off twice. During design it removes whole classes of findings at the cost of a whiteboard session: keys that should never have been on the device, an admin interface that should never have faced the network, a trust relationship between two ECUs that nobody questioned. Before a penetration test it becomes the test plan: the tester attacks the paths the model considers critical first, and checks whether the countermeasures the model claims actually exist.
In our ECU and IoT projects the second use is the common one. For an infotainment platform the model listed the TEE, the kernel drivers reachable from unprivileged apps, DoIP and SOME/IP as the critical boundaries, and the fuzzing campaign followed that list. For an ESP32 communication module the model identified the shared MQTT credential as a single point of failure for the entire fleet, before any test had run. The best threat models we see are short, drawn by the people who built the system, and updated when the design changes.
Common misunderstandings
Threat modeling is not a tool run and not a compliance document. A generated list of 300 generic threats is less useful than 20 specific ones with named owners. It is also not finished when the list exists: the “did we do a good job” question needs verification, which is where code review, fuzzing and penetration testing come in. And it does not replace them. A model says what should be true about the system; a test shows whether it is.
FAQ
Frequently asked questions
When should we do threat modeling?
As early as there is an architecture to draw, and again whenever it changes materially: a new interface, a new trust boundary, a new deployment model. A threat model made after the product ships still has value as the test plan for a penetration test, but the cheap fixes (not storing the key there, not exposing that port) are gone by then.
Which method should we use: STRIDE, PASTA, attack trees?
The method matters less than doing it with the right people and a precise diagram. STRIDE is a good checklist per data flow for software systems. Attack trees are better for showing how several weaknesses combine, which is what matters in embedded products. For vehicles ISO/SAE 21434 prescribes the TARA structure. We usually combine a data flow diagram, STRIDE per boundary and attack trees for the top risks.
Do you need source code or the hardware for a threat model?
No. A threat model works on the design: architecture diagrams, interface descriptions, deployment and the list of assets. Code and hardware come in when the threat model is verified, in a code review or a penetration test. That is also why a threat model is a good first step before any testing: it tells the tester where to spend the time.
Sources
Related pages
- GlossaryTARA (Threat Analysis and Risk Assessment)TARA is the risk analysis method of ISO/SAE 21434 for vehicles and ECUs. The seven steps, how impact and attack feasibility are rated, and what a usable TARA looks like.
- GlossaryAttack SurfaceThe attack surface is every point where an attacker can interact with a system: interfaces, protocols, ports, debug access, people. How to map it and how to shrink it.
- GlossaryPenetration testA penetration test is an authorised, mostly manual attack on a system to find and prove exploitable vulnerabilities. Definition, types, process and the report.
- InsightsSecure Coding in Embedded C: Five Bugs We Keep FindingUnchecked lengths, integer overflows, format strings, weak randomness and debug leftovers: the five bug classes we find most in firmware, and how to avoid them.
- ServicesSecure code from the first commit.Secure coding training, source code review, threat modelling and DevSecOps. Build secure software and firmware and meet CRA and ISO/SAE 21434 requirements.
