Threat modeling

Threat modeling systematically analyzes what can go wrong in a system, who would want to attack it, and how, to prioritize defenses before it’s built or deployed. It’s proactive security design, not reaction.

The four questions (Shostack)

1. What are we building?          system diagram (DFD: flows, trust boundaries)
2. What can go wrong?              identify threats (STRIDE, attack trees)
3. What are we going to do about it?  prioritized mitigations and controls
4. Did we do a good job?           validate/review; iterate

STRIDE (threat taxonomy)

Spoofing              identity spoofing             -> authentication
Tampering             data tampering                 -> integrity (signatures, hashes)
Repudiation           denying an action              -> logging/non-repudiation
Information disclosure information leak               -> encryption, access control
Denial of service     service outage                 -> resilience, limits
Elevation of privilege privilege escalation          -> authorization, least privilege

Data flow diagrams and trust boundaries

- model entities, processes, stores, and data FLOWS
- mark the TRUST BOUNDARIES: where data crosses from one zone to another = where to attack
- each boundary crossing is a threat candidate (validation, auth, encryption)

Approaches and frameworks

STRIDE            system/design-centric (Microsoft)
PASTA             risk- and attacker-centric (7 stages, business-oriented)
Attack trees      decompose an attacker's goal into steps (tree)
LINDDUN           PRIVACY-centric (threats to personal data)
MITRE ATT&CK      bring real adversary TTPs into the model (cti-attack)

Risk prioritization

- risk = likelihood x impact; prioritize the critical and the exposed
- DREAD (debated) or other scoring; better qualitative + context than fake numbers
- connect with risk management (grc-riesgos) and vulnerabilities (def-vulnmgmt)

Blue Team / operation

Do threat modeling early (design) and keep it alive with each relevant change.
Focus on trust boundaries and the data flow: that’s where most threats live.
Enrich with ATT&CK (real TTPs) and the context of CTI (who attacks your sector).
Actionable output: a prioritized list of mitigations that enters the backlog (see Threat modeling in design for AppSec).

Real-world cases

Many breaches trace back to an unmodeled trust boundary (unvalidated input, missing auth).
LINDDUN/privacy gains weight with GDPR: model threats to personal data (GDPR & privacy).
Threat modeling in the SDLC (Secure SDLC) cuts the cost of fixing design flaws versus doing it in production.

Testing checklist

Diagram the system (DFD) with trust boundaries
Identify threats (STRIDE / attack trees)
Enrich with real TTPs (ATT&CK) and CTI context
Prioritize by risk (likelihood x impact)
Define mitigations per threat and assign them
Consider privacy (LINDDUN/GDPR) if personal data is involved
Review/iterate with each design change