Skip to main content
Capítulo Basilar

This chapter is considered foundational in the Security by Design - Theory of Everything (SbD-ToE) model. Its application is mandatory to guarantee the coherence, traceability and effectiveness of the remaining security practices.

The absence or partial application of Threat Modelling compromises the formal link between risk, architecture and requirements, making a consistent adoption of SbD-ToE unfeasible.

Chapter 3 - Threat Modelling

1. 🧭 What it covers technically​

Threat Modelling is the practice that makes it possible to anticipate real threats before implementation, on the basis of the application's architecture, data flows and risk context. It is treated as a structured decision process, subject to human validation and to the production of verifiable evidence.
The absence of a threat from a model is not proof that it does not exist; the risks of omission and bias must be explicitly assumed and mitigated.

In SbD-ToE, Threat Modelling is the formal origin of the mitigation requirements, directly linking:

  • the risk classification (Ch. 1),
  • the security requirements (Ch. 2),
  • and the architecture decisions (Ch. 4).

This chapter covers:

  • The systematic integration of threat modelling into the development lifecycle
  • Structured threat analysis methods (STRIDE, LINDDUN, PASTA)
  • Creation and maintenance of architecture-based threat models (DFDs, trust boundaries)
  • Identification of relevant technical and business threats
  • Explicit derivation of requirements and controls from the identified threats
  • Traceability between threat → requirement → mitigation → validation
  • Controlled reuse of models in standardised architectures
  • Extension to AI/ML systems — systems with artificial intelligence components (LLMs, predictive models, RAG, autonomous agents) require extended threat modelling with specific adversarial threats (model poisoning, prompt injection, data exfiltration, AI supply chain compromise) catalogued in MITRE ATLAS and NIST AI 100-2; see Methodologies — §AI/ML and requirement THR-008

2. 🧪 Practical prescription: what, who, how, when, why and to what end​

🔐 Threat Modelling as the link between risk, architecture and control​

Without Threat Modelling, security requirements lose their context
and the controls applied no longer have a justified origin.

📌 What must be done​

  • Carry out threat modelling on the basis of the application's risk level
  • Model data flows and trust boundaries on the basis of architecture artefacts
  • Identify relevant threats using recognised models
  • Associate each threat with:
    • one or more mitigation requirements,
    • technical or organisational controls,
    • and validation criteria
  • Document decisions, accepted risks and future actions
  • Validate the threat model as part of the architecture review

⚙️ How it must be done​

  • Use clear, versioned diagrams (DFDs, context diagrams)
  • Apply methodologies such as STRIDE, LINDDUN or PASTA proportionally
  • Integrate the exercise into existing rituals (design review, technical refinement)
  • Create traceable backlog items for each relevant mitigation
  • Align the derived requirements with the Requirements Catalogue (Ch. 2)
  • Reuse models only when the architecture and the context are equivalent

Specialised tools can support the process,
but do not replace human analysis or technical validation.

📆 When to apply​

  • At the start of relevant projects or epics
  • Before external integrations, exposures or architectural changes
  • Whenever the application is classified as L2 or L3
  • Whenever changes occur that may alter the threat profile

👥 Who is involved​

Role/FunctionMain responsibilities
Software Architects / DevOps / SREFacilitate the process and keep the models up to date
Development TeamExplain flows, logic and attack surfaces
Security / AppSecIdentify relevant threats, vectors and attack techniques
Product Owner / BusinessValidate the impact, priority and acceptability of the risk

3. ⚠️ Caveats and limitations​

  • Models that are too abstract become useless
  • Unversioned documentation loses operational value
  • Automated tools do not capture business context
  • The absence of a link to requirements and the backlog nullifies the value of the exercise

4. 💡 Examples and reuse​

  • Examples of applying STRIDE by architecture type
  • Examples of privacy-focused threat modelling (LINDDUN)
  • Examples of integration with supporting tools (e.g. IriusRisk)

5. 🔍 What more can be done (and why)​

  • Create internal libraries of reusable threats by system type
  • Integrate threat modelling with validation pipelines and architecture gates
  • Use the history of incidents and findings to enrich the models
  • Train technical facilitators for iterative, lightweight sessions

🧩 Links to other chapters​

ChapterTechnical relationship
Ch. 1 – Risk ManagementDetermines when threat modelling is mandatory
Ch. 2 – Security RequirementsReceives requirements derived from the threats
Ch. 4 – Secure ArchitecturePrimary source of the modelled artefacts
Ch. 7 – Secure CI/CDSupports traceability and validation
Ch. 10 – Security TestingValidates derived requirements

📌 This chapter is mandatory for L2 and L3 applications.
It is the mechanism that guarantees that security requirements respond to real threats,
and that the architecture is assessed before it is exploited in production.

📜 Relevant Organisational Policies​

PolicyMandatory?ApplicationMinimum content
Threat Modelling Policy✅ Yes (L2–L3)AppSec, ArchitectureMandatory methodology, scope, minimum artefacts, traceability and cadence

📎 See the details of the policies recommended for this chapter
For the printed version, see the manual's Organisational Policies Annex.