La Verità Scomoda sul Threat Modeling
La maggior parte del threat modeling che vedo nelle aziende è teatro della sicurezza. Sessioni di due ore, un whiteboard pieno di box e frecce, qualcuno che scrive "SQL injection" e "man-in-the-middle" su post-it, un documento Word che finisce in una cartella SharePoint e non viene mai più aperto. Il CISO spunta la casella "TM effettuato", il team torna a scrivere codice, e la superficie di attacco rimane identica a prima.
Il vero threat modeling è una disciplina ingegneristica, non un esercizio di compliance. Il suo output non è un documento — è una comprensione condivisa delle minacce rilevanti per il sistema, tradotta in decisioni di progettazione specifiche, requisiti di sicurezza verificabili e storie di rischio che i developer possono affrontare concretamente nel loro sprint.
La differenza tra un threat model mediocre e uno eccellente non sta nella metodologia scelta. Sta nella qualità del modello di sistema, nella profondità dell'analisi dei trust boundary, e soprattutto nella capacità di trasformare la teoria in mitigazioni concrete. Un threat model senza mitigazioni tracciabili è peggio di nessun threat model: ti dà una falsa sensazione di sicurezza senza cambiare nulla.
"The goal of threat modeling is not to produce a threat model document. The goal is to secure the system."
— Adam Shostack, autore di Threat Modeling: Designing for Security
Le Quattro Domande Fondamentali
Adam Shostack ha strutturato il threat modeling attorno a quattro domande. Sembra semplice. Non lo è — la difficoltà sta nell'onestà delle risposte.
Su cosa stiamo lavorando?
Costruire un modello accurato del sistema: componenti, flussi di dati, confini di fiducia (trust boundary), asset critici. La maggior parte dei team risponde a questa domanda con un diagramma architetturale di alto livello che non mostra dove passano i dati sensibili, chi ha accesso a cosa, o dove si trovano i confini di privilegio. È il punto di partenza sbagliato.
Cosa può andare storto?
Identificare le minacce rilevanti per il sistema specifico — non un elenco generico di vulnerabilità, ma minacce contestualizzate agli asset, alle superfici di attacco e ai trust boundary identificati nella Q1. Qui si sceglie la metodologia (STRIDE, PASTA, Attack Trees) e si analizzano sistematicamente i vettori di attacco.
Cosa facciamo al riguardo?
Per ogni minaccia rilevante: definire la mitigazione appropriata, assegnare ownership, stimare lo sforzo e inserirla nel backlog come issue tracciabile. Questo passaggio è quello più spesso saltato, e quello che determina se il threat model ha valore reale.
Abbiamo fatto un buon lavoro?
Validare il threat model: è il modello del sistema aggiornato? Le minacce identificate sono quelle giuste? Le mitigazioni proposte sono adeguate? Il threat model è vivo — viene aggiornato quando il design cambia — o è già diventato l'ennesimo artefatto obsoleto?
Decomporre il Sistema: Dove il 90% dei Team Fallisce
La qualità di un threat model è direttamente proporzionale alla qualità del modello di sistema su cui si basa. Se il tuo DFD (Data Flow Diagram) è impreciso, superficiale o non aggiornato, il resto dell'analisi è costruito su sabbia.
Data Flow Diagrams (DFD): non solo box e frecce
Un DFD per il threat modeling ha elementi specifici con semantica precisa: processi (cerchi — elaborano o trasformano dati), data store (rettangoli doppi — archiviano dati, anche temporaneamente), entità esterne (rettangoli — utenti, sistemi esterni, il "mondo fuori"), flussi di dati (frecce — mostrano come i dati si muovono) e trust boundary (linee tratteggiate — il confine tra zone di diverso livello di fiducia).
La disciplina nella produzione del DFD è fondamentale. Ogni freccia deve rispondere: cosa fluisce, in quale direzione, sotto quale protocollo o meccanismo, e chi controlla quel canale? Un DFD che non mostra dove passano le credenziali, dove vengono cifrati i dati, o dove un processo eleva i suoi privilegi non è utile per il threat modeling.
Usa livelli: un DFD Level-0 (context diagram) mostra il sistema nel suo insieme. Un Level-1 scompone i processi principali. Un Level-2 entra nei sotto-componenti. Per il threat modeling di applicazioni web/API tipicamente Level-1 è sufficiente; per sistemi embedded complessi con hardware, firmware e software bisogna arrivare a Level-2 o oltre.
Asset Identification: cosa stai proteggendo davvero?
Prima di identificare le minacce, devi sapere cosa stai proteggendo. Asset non significa solo "database con i dati degli utenti". Gli asset rilevanti per il threat modeling includono: dati in transito e a riposo (PII, credenziali, chiavi crittografiche, token di sessione, proprietà intellettuale), funzionalità critiche (il processo di autenticazione, il motore di autorizzazione, il workflow di pagamento), risorse di sistema (CPU, storage, network bandwidth — rilevanti per gli attacchi DoS), e reputazione e fiducia (la capacità del sistema di essere percepito come affidabile dai suoi utenti).
Un esercizio che trovo molto efficace: chiedi al team "quali sono le tre cose peggiori che potrebbero succedere a questo sistema?" Le risposte identificano quasi sempre gli asset più critici. Un attaccante non ha bisogno di compromettere tutto — ha bisogno di compromettere le cose giuste.
Trust Boundary: Il Concetto Più Critico (e Più Frainteso)
Il trust boundary è la linea che separa due zone del sistema con livelli di fiducia differenti. Attraversare un trust boundary significa che i dati o le richieste passano da una zona meno attendibile a una più attendibile — e questo è il punto dove le minacce più serie si manifestano.
L'errore più comune: pensare che il trust boundary sia solo quello tra Internet e il perimetro di rete aziendale. In realtà, i trust boundary rilevanti in un sistema moderno sono molto più numerosi e granulari:
- Browser → Server: ogni request HTTP è un attraversamento di trust boundary. L'input dell'utente non è mai attendibile.
- Frontend → Backend: anche in un sistema "interno", il frontend non dovrebbe avere accesso diretto a operazioni privilegiate.
- Microservizio A → Microservizio B: se il traffico interno non è autenticato e autorizzato, un attaccante che compromette un singolo servizio si muove lateralmente senza attrito.
- Processo user-space → Kernel: ogni system call, ogni operazione privilegiata è un attraversamento di trust boundary.
- Container → Host OS: confine critico, soprattutto con container privilegiati o volume mount pericolosi.
- Firmware → Hardware security module: nei prodotti IoT, la catena di fiducia hardware/software è un trust boundary con implicazioni di sicurezza profonde.
- Applicazione → Dipendenza di terze parti: ogni libreria open source ha accesso al processo — il suo codice potrebbe essere compromesso.
La regola pratica: ogni volta che dati controllati da un'entità meno fidata raggiungono un'entità più fidata, c'è un trust boundary. Disegnali tutti. Poi analizza sistematicamente cosa attraversa ognuno di loro.
STRIDE: La Metodologia Fondamentale
STRIDE, sviluppata da Loren Kohnfelder e Praerit Garg in Microsoft nel 1999 e poi sistematizzata da Adam Shostack, è la metodologia più diffusa per il threat modeling di applicazioni software. La ragione del suo successo è semplice: fornisce un framework mnemonica — sei categorie di minacce — che si applica sistematicamente a ogni elemento del DFD.
La logica di STRIDE è questa: per ogni componente del sistema (ogni processo, ogni data store, ogni flusso di dati, ogni entità esterna), chiedi quali delle sei categorie di minacce si applicano. Il risultato è un insieme strutturato di minacce ancorato al modello del sistema, non una lista generica di CVE.
Una nota tecnica importante su STRIDE: non tutte le categorie si applicano a tutti gli elementi del DFD. I processi sono vulnerabili a tutte e sei. I data store tipicamente non sono soggetti a Spoofing e Repudiation (a meno che non abbiano meccanismi di autenticazione propri). I flussi di dati sono vulnerabili a Tampering, Information Disclosure e DoS. Le entità esterne sono principalmente soggette a Spoofing.
Consiglio dal campo: Applicare STRIDE meccanicamente produce un elenco di minacce banali. Il valore emerge quando si usa STRIDE come framework di domande, non come checklist. Per ogni minaccia teorica chiedi: È realisticamente sfruttabile nel contesto di questo sistema? Qual è l'impatto reale se si materializza? C'è già una mitigazione che la copre? Questo filtraggio è dove l'esperienza del security architect fa la differenza.
Oltre STRIDE: Le Altre Metodologie
STRIDE non è l'unico strumento. La scelta della metodologia dipende dal tipo di sistema, dalla maturità del team e dal contesto in cui si opera.
PASTA — Process for Attack Simulation and Threat Analysis
Quando usarlo: sistemi enterprise complessi, risk-centric threat modelingPASTA è una metodologia in sette stadi orientata al rischio: definisce gli obiettivi di business prima ancora di analizzare le minacce, collegando le vulnerabilità tecniche agli impatti sul business. Il vantaggio è un output strettamente allineato alle priorità aziendali. Lo svantaggio: è labor-intensive e richiede coinvolgimento di stakeholder business, security e engineering. È la scelta giusta quando il threat modeling deve essere giustificato in termini di ROI a livello executive, non solo a livello tecnico.
LINDDUN — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance
Quando usarlo: sistemi con requisiti GDPR, dati sensibili, privacy by designLINDDUN è a STRIDE quello che il GDPR è all'ISO 27001 — lo stesso paradigma, ma specializzato sulla privacy. Le sue sette categorie mappano minacce alla privacy in modo analogo a come STRIDE mappa minacce alla sicurezza. Se il tuo sistema tratta dati sanitari, dati di localizzazione, dati biometrici o qualsiasi dato che richiederebbe una DPIA, l'analisi LINDDUN complementa il STRIDE e produce input diretto per il Privacy Impact Assessment.
TARA — Threat Analysis and Risk Assessment
Quando usarlo: sistemi embedded, IoT, automotive (ISO/SAE 21434), CRA complianceTARA è la metodologia adottata in ambito automotive (UNECE WP.29, ISO/SAE 21434) e sempre più rilevante per i sistemi IoT soggetti al CRA. Struttura l'analisi su tre livelli — identificazione degli asset, analisi delle minacce (STRIDE-like) e valutazione del rischio con formule esplicite (likelihood × impact). Il suo punto di forza è la tracciabilità: ogni mitigazione è collegata a un requisito specifico e validabile. Per il CRA, TARA produce direttamente la cybersecurity risk assessment richiesta dall'Annex I.
Attack Trees
Quando usarlo: analisi profonda di scenari di attacco specifici, red team planningGli Attack Tree (proposti da Bruce Schneier) modellano un singolo obiettivo dell'attaccante (es. "compromettere il wallet dell'utente") in una struttura ad albero dove ogni nodo rappresenta un sotto-obiettivo o un'azione. I nodi figli possono essere in AND (tutti devono verificarsi) o OR (è sufficiente uno). Sono straordinariamente efficaci per analizzare scenari di attacco complessi in profondità, per identificare il percorso di attacco minimo, e per la pianificazione di red team exercise. Non sono ideali come metodologia primaria per sistemi complessi, ma sono complementari a STRIDE per analizzare le minacce più critiche.
OCTAVE — Operationally Critical Threat, Asset, and Vulnerability Evaluation
Quando usarlo: organizzazioni con risorse limitate, assessment olistico, risk management enterpriseOCTAVE è più vicino a un framework di risk assessment organizzativo che a una metodologia di threat modeling tecnico. È autoguidato e orientato alla valutazione degli asset critici dal punto di vista del business e delle operazioni. La variante OCTAVE Allegro è adatta a organizzazioni di medie dimensioni. È meno granulare tecnicamente rispetto a STRIDE ma produce un quadro di rischio comprensivo che include processi, persone e tecnologia.
Dalla Minaccia alla Mitigazione: La Mappa STRIDE→Controlli
Un threat model senza mitigazioni è un esercizio accademico. La vera utilità emerge quando ogni minaccia è collegata a un controllo specifico, con ownership chiara e criteri di verifica. Questa non è una mappatura one-to-one — molte minacce richiedono controlli a più livelli (difesa in profondità).
- Spoofing → Autenticazione: Autenticazione forte (non solo password), sessioni a breve scadenza, validazione di tutti i claim di identità, mTLS per comunicazioni service-to-service, certificate pinning dove appropriato.
- Tampering → Integrità: HMAC o firma digitale su tutti i dati critici in transito, TLS 1.3 con cipher suite forti, verifica dell'integrità dei binary in deployment (firma e verifica degli artefatti), ORM parametrizzati o prepared statements per prevenire SQL injection.
- Repudiation → Auditability: Audit log strutturati, centralizzati e tamper-proof (WORM storage, log signing), con timestamp sicuri e correlazione degli eventi. Logging di tutte le azioni amministrative e delle operazioni su dati sensibili. Retention policy adeguata alla compliance applicabile.
- Information Disclosure → Confidenzialità: TLS su tutti i canali (anche internal), cifratura at-rest per tutti i dati sensibili (con key management separato dai dati), data minimization (non loggare mai credenziali, PAN, SSN), error handling che non espone dettagli interni, security headers HTTP (CSP, X-Content-Type-Options, HSTS).
- Denial of Service → Disponibilità: Rate limiting a più livelli (IP, utente, endpoint), circuit breaker pattern, resource quotas per database connection pool e thread pool, input validation rigorosa (lunghezza, tipo, struttura), timeout su tutte le operazioni di I/O, pagination obbligatoria per le query di lista.
- Elevation of Privilege → Autorizzazione: Modello di autorizzazione esplicito (deny-by-default), RBAC o ABAC con granularità adeguata, validazione server-side di tutti i controlli di accesso (mai fidarsi del frontend), principio di least privilege per ogni account di servizio, sandboxing dei componenti ad alto rischio.
Errore frequente: Usare TLS come risposta a tutte le minacce di Information Disclosure. TLS protegge i dati in transito, ma non quelli a riposo, non quelli nei log, non quelli esposti da un endpoint non autenticato, e non quelli in una query di debug che mostra l'intero record. La cifratura è necessaria ma non sufficiente. Ogni threat di Information Disclosure richiede un'analisi del suo specifico vettore.
Prioritizzare le Minacce: Oltre il CVSS
Identificare cento minacce non serve a nulla se non sai quali affrontare per prime. La prioritizzazione è dove molti threat model perdono valore operativo — o perché non la fanno, producendo una lista piatta non azionabile, o perché usano il CVSS meccanicamente fuori contesto.
Il CVSS (Common Vulnerability Scoring System) è nato per valutare vulnerabilità note e specifiche in componenti software. Applicarlo a minacce architetturali durante il threat modeling è metodologicamente scorretto: le minacce TM non sono CVE, non hanno ancora una sfruttabilità determinata, e il loro impatto dipende fortemente dal contesto dell'applicazione.
Per la prioritizzazione in-TM, preferisco un approccio a tre assi:
- Sfruttabilità contestuale: Quanto è realistica l'exploitazione in questo sistema specifico? Considera: la complessità tecnica richiesta, se l'attaccante ha bisogno di accesso fisico/logico, se esistono precondizioni (autenticazione, posizione di rete), e il livello di sofisticazione dell'attaccante più probabile per questo sistema.
- Impatto sul business: Non l'impatto tecnico astratto, ma il danno reale al business se la minaccia si materializza. Perdita di dati sensibili degli utenti? Danno reputazionale? Impatto regolatorio (GDPR, CRA)? Perdita economica diretta?
- Costo della mitigazione: Quanto costa mitigarla, in termini di sforzo ingegneristico, complessità operativa aggiunta e possibile impatto sulle performance? Una mitigazione che richiede sei mesi di refactoring dell'architettura ha un profilo di rischio diverso da una che si risolve con due righe di configurazione.
Il risultato è un ranking contestuale, non assoluto. Le minacce ad alta sfruttabilità con impatto critico e mitigazione a basso costo vanno affrontate immediatamente. Le minacce ad alta sfruttabilità con impatto elevato ma mitigazione complessa devono essere pianificate con roadmap e ownership chiara, non delegate al dimenticatoio.
Tooling: Cosa Funziona, Cosa No
Il tool non fa il threat model. Un buon threat model si può fare con carta e penna. Un threat model scadente con IriusRisk rimane scadente. Detto questo, il tooling giusto riduce la frizione, migliora la tracciabilità e facilita la collaborazione.
- Microsoft Threat Modeling Tool: Gratuito, maturo, specificamente progettato per threat modeling con stencil predefiniti per Azure, sistemi web, IoT. Produce automaticamente minacce STRIDE partendo dal DFD. Limitato nella collaborazione multi-utente e nell'integrazione con i tool di sviluppo. Ottimo punto di partenza.
- OWASP Threat Dragon: Open source, disponibile sia come applicazione desktop che web. Più flessibile del Microsoft TMT, supporta template personalizzati, ma il motore di threat generation automatica è meno sofisticato. Ideale per team che lavorano in ambienti non-Microsoft.
- IriusRisk: La soluzione enterprise più completa. Integrazione nativa con Jira, GitHub, Azure DevOps. Librerie di minacce preconfigurate per framework (OWASP, NIST, PCI-DSS). Dashboard di compliance tracking. Il prezzo è significativo e l'adozione richiede investimento, ma per organizzazioni con decine di prodotti è l'unica soluzione scalabile.
- Threagile: Threat modeling as code — il modello del sistema è definito in YAML e le minacce vengono generate automaticamente con un motore rules-based. L'output include diagrammi, report e una risk matrix. Si integra naturalmente in pipeline CI/CD. Interessante per team con forte cultura DevOps che vogliono tratttare il threat model come un artefatto versionato.
- draw.io / Miro / Lucidchart: Per la parte diagrammale, la flessibilità conta più della funzionalità specializzata. Questi tool eccellono per sessioni collaborative real-time. Tieni separato il diagramma dall'analisi delle minacce (un foglio Markdown o uno sheet strutturato).
Il mio setup preferito per team di medie dimensioni: Threat Dragon (o Microsoft TMT) per il DFD e la generazione iniziale delle minacce, un template Markdown per l'analisi e la prioritizzazione, e issue Jira/GitHub per il tracking delle mitigazioni. Semplice, tracciabile, integrabile nella pipeline CI/CD.
Rendere il Threat Modeling Sostenibile
La sfida più grande non è fare il primo threat model. È fare il secondo, il terzo, il decimo. La maggior parte dei programmi di threat modeling muore dopo sei mesi perché il processo è troppo pesante, troppo dipendente da pochi esperti, e troppo slegato dal ritmo reale dello sviluppo.
Threat modeling leggero e iterativo, non monolitico
Non devi fare il threat model completo di un sistema nella sua interezza prima di scrivere una riga di codice. Parti da un threat model di alto livello (Level-0 DFD) all'inizio del progetto, poi approfondisci iterativamente su ogni feature significativa. Quando un developer apre una PR che aggiunge un nuovo endpoint API, la domanda "questo endpoint introduce nuovi trust boundary attraversati?" deve essere naturale, non un evento eccezionale.
Security Champions: scalare oltre il team di sicurezza
Un team di sicurezza centralizzato non può fare threat modeling di tutti i prodotti di un'organizzazione di medie dimensioni — ci sono semplicemente troppi sistemi, troppe feature, troppo poco tempo. La soluzione è distribuire le competenze tramite un programma di Security Champions: developer di ogni team che ricevono formazione specializzata in threat modeling e diventano i referenti locali di sicurezza. Non sostituiscono il security architect per i sistemi critici, ma moltiplicano la capacità dell'organizzazione.
Threat model come PR artifact
Una pratica che ho visto funzionare molto bene: il threat model diventa un artefatto richiesto nelle PR che modificano l'architettura del sistema. Non un documento completo — anche solo un campo strutturato nella PR description che risponde: "quali trust boundary modifica questa PR? Quale minaccia nuova introduce? Come viene mitigata?" Questo sposta il threat modeling nel flusso quotidiano di sviluppo senza richiedere sessioni dedicate per ogni piccola modifica.
Anti-Pattern: Le Cose Che Uccidono un Programma di Threat Modeling
Il "big bang" threat model
Un unico threat model monolitico fatto una volta all'anno per un sistema da 50 microservizi. Output: un documento Word di 80 pagine che nessuno legge. Il sistema cambia ogni settimana; il documento è obsoleto in due sprint. Il threat modeling deve essere continuo e granulare, non un evento annuale.
Threat modeling senza gli sviluppatori
Sessioni in cui il security team analizza il sistema in isolamento, produce un report, e lo manda ai developer come lista di "cose da fixare". Il risultato: nessun contesto, nessuna ownership, nessun cambiamento. Il threat modeling è una pratica collaborativa. I developer conoscono i dettagli implementativi che il security architect non conosce. Senza loro, il modello del sistema sarà sempre incompleto.
Fermarsi all'identificazione delle minacce
Produrre una lista di 40 minacce senza prioritizzazione né mitigazioni specifiche, lasciando che i developer "capiscano come affrontarle". Questo è il modo più veloce per garantire che il threat modeling non cambi nulla. Ogni minaccia deve avere un owner, una mitigazione specifica e un criterio di verifica.
Il DFD che non corrisponde alla realtà
Un modello architetturale idealizzato del sistema "come dovrebbe essere", non come è in produzione. Mancano i servizi di logging, le pipeline CI/CD, i backup automatici, le integrazioni con sistemi di terze parti aggiunte "temporaneamente" due anni fa. Un threat model fatto su questo tipo di DFD produce mitigazioni per minacce inesistenti e ignora quelle reali.
Usare il threat modeling come strumento di compliance, non di sicurezza
Fare threat modeling perché il CISO lo richiede, perché il cliente lo chiede nella RFP, o perché il CRA lo impone. Il risultato è un documento prodotto nel minimo tempo possibile, con il minimo sforzo, che soddisfa formalmente il requisito senza cambiare nulla nella postura di sicurezza del prodotto. Questo è il tipo di threat modeling che dà alla disciplina una cattiva reputazione.
Threat Modeling e Cyber Resilience Act
Il CRA non menziona esplicitamente "threat modeling" come requisito, ma i suoi obblighi tecnici sono praticamente impossibili da soddisfare senza un processo strutturato di analisi delle minacce:
- Annex I, Part I, §1: "I prodotti con elementi digitali sono progettati, sviluppati e prodotti in modo da garantire un livello di cybersecurity adeguato ai rischi." — Impossibile determinare un livello "adeguato ai rischi" senza aver prima identificato e valutato i rischi. Il threat modeling è lo strumento operativo per soddisfare questo requisito.
- Annex I, Part I, §2: "I prodotti sono messi a disposizione senza vulnerabilità sfruttabili note" — La STRIDE analysis sistematica applicata al DFD è il meccanismo per identificare proattivamente le classi di vulnerabilità prima del rilascio.
- §3(d): Protezione da accessi non autorizzati: Il trust boundary analysis è il framework che permette di identificare dove mancano i controlli di autenticazione e autorizzazione.
- §3(j): Resilienza agli attacchi DoS: La categoria "Denial of Service" di STRIDE, applicata sistematicamente, produce i requisiti specifici di rate limiting, resource quota e circuit breaking.
Per i prodotti in Classe II (firewall industriali, gateway IoT critici, sistemi di sicurezza fisica) e Critico, la valutazione da parte di organismo notificato include quasi certamente la verifica di processi di threat modeling documentati e tracciabili. Avere TARA o STRIDE documentato e collegato ai requisiti di sicurezza del prodotto non è solo best practice — è il modo per superare la due diligence di certificazione.
Come Costruire un Programma di Threat Modeling che Duri
Dalle esperienze accumulate costruendo e rilanciando programmi di threat modeling in organizzazioni di diverse dimensioni, emergo con tre conclusioni non negoziabili:
Prima: il threat modeling deve essere parte del definition of done per ogni feature significativa, non un'attività straordinaria. Se richiede un'approvazione speciale, una riunione dedicata e un template da compilare in 6 pagine, non verrà fatto. La frizione uccide l'adozione.
Seconda: il modello di sistema deve essere un artefatto vivo. Ogni PR che modifica l'architettura dovrebbe aggiornare il DFD. Un threat model su un sistema non aggiornato è peggio di nessun threat model, perché ti dà fiducia mal riposta.
Terza: misura l'output, non l'input. Non conta quanti threat model hai prodotto — conta quante mitigazioni sono state implementate, quante vulnerabilità architetturali sono state risolte prima del rilascio, e quante non sono state trovate da penetration test esterni perché il threat model le aveva già anticipate. Questo è il ROI del threat modeling, e questo è il numero che convierte i manager scettici.
Il team di ProductSecurity.it ha costruito e implementato programmi di threat modeling in organizzazioni che producono hardware IoT, piattaforme SaaS enterprise e sistemi embedded critici. Se vuoi costruire un programma sostenibile — non un documento, non un esercizio di compliance, ma un vero cambiamento nella postura di sicurezza del tuo prodotto — inizia dalla valutazione della tua maturità attuale.
The Uncomfortable Truth About Threat Modeling
Most threat modeling I see in organizations is security theater. Two-hour sessions, a whiteboard covered in boxes and arrows, someone writing "SQL injection" and "man-in-the-middle" on sticky notes, a Word document that lands in a SharePoint folder and is never opened again. The CISO ticks the box "TM completed," the team goes back to writing code, and the attack surface remains exactly as it was.
Real threat modeling is an engineering discipline, not a compliance exercise. Its output is not a document — it is a shared understanding of the threats relevant to the system, translated into specific design decisions, verifiable security requirements, and risk stories that developers can concretely address in their sprint.
The difference between a mediocre threat model and an excellent one is not the methodology chosen. It lies in the quality of the system model, the depth of the trust boundary analysis, and above all the ability to translate theory into concrete mitigations. A threat model without traceable mitigations is worse than no threat model at all: it gives you a false sense of security without changing anything.
"The goal of threat modeling is not to produce a threat model document. The goal is to secure the system."
— Adam Shostack, author of Threat Modeling: Designing for Security
The Four Fundamental Questions
Adam Shostack structured threat modeling around four questions. It sounds simple. It isn't — the difficulty lies in the honesty of the answers.
What are we building?
Build an accurate model of the system: components, data flows, trust boundaries, critical assets. Most teams answer this with a high-level architectural diagram that does not show where sensitive data flows, who has access to what, or where privilege boundaries lie. That is the wrong starting point.
What can go wrong?
Identify threats relevant to the specific system — not a generic list of vulnerabilities, but threats contextualized to the assets, attack surfaces, and trust boundaries identified in Q1. This is where you choose the methodology (STRIDE, PASTA, Attack Trees) and systematically analyze attack vectors.
What are we going to do about it?
For each relevant threat: define the appropriate mitigation, assign ownership, estimate effort, and put it in the backlog as a trackable issue. This is the step most often skipped, and the one that determines whether the threat model has real value.
Did we do a good enough job?
Validate the threat model: is the system model current? Were the right threats identified? Are the proposed mitigations adequate? Is the threat model alive — updated when design changes — or has it already become another stale artifact?
Decomposing the System: Where 90% of Teams Fail
The quality of a threat model is directly proportional to the quality of the system model it is based on. If your DFD (Data Flow Diagram) is inaccurate, shallow, or out of date, the rest of the analysis is built on sand.
Data Flow Diagrams (DFDs): not just boxes and arrows
A DFD for threat modeling has specific elements with precise semantics: processes (circles — transform or process data), data stores (double rectangles — store data, even temporarily), external entities (rectangles — users, external systems, the "outside world"), data flows (arrows — show how data moves), and trust boundaries (dashed lines — the boundary between zones of different trust levels).
Discipline in producing the DFD is critical. Every arrow must answer: what flows, in which direction, over what protocol or mechanism, and who controls that channel? A DFD that does not show where credentials flow, where data is encrypted, or where a process elevates its privileges is not useful for threat modeling.
Use levels: a Level-0 DFD (context diagram) shows the system as a whole. Level-1 decomposes the main processes. Level-2 drills into sub-components. For threat modeling web applications and APIs, Level-1 is usually sufficient; for complex embedded systems with hardware, firmware, and software, you need Level-2 or deeper.
Asset Identification: what are you actually protecting?
Before identifying threats, you need to know what you are protecting. Assets in threat modeling include: data in transit and at rest (PII, credentials, cryptographic keys, session tokens, intellectual property), critical functionality (the authentication process, the authorization engine, the payment workflow), system resources (CPU, storage, network bandwidth — relevant for DoS attacks), and trust and reputation (the system's ability to be perceived as reliable by its users).
An exercise I find highly effective: ask the team "what are the three worst things that could happen to this system?" The answers almost always identify the most critical assets. An attacker does not need to compromise everything — they need to compromise the right things.
Trust Boundaries: The Most Critical (and Most Misunderstood) Concept
A trust boundary is the line separating two zones of the system with different trust levels. Crossing a trust boundary means data or requests move from a less-trusted zone to a more-trusted one — and this is where the most serious threats manifest.
The most common mistake: thinking the trust boundary is only the one between the Internet and the corporate network perimeter. In reality, relevant trust boundaries in a modern system are far more numerous and granular:
- Browser → Server: every HTTP request crosses a trust boundary. User input is never trusted.
- Frontend → Backend: even in an "internal" system, the frontend should not have direct access to privileged operations.
- Microservice A → Microservice B: if internal traffic is not authenticated and authorized, an attacker who compromises a single service moves laterally without friction.
- User-space process → Kernel: every system call, every privileged operation is a trust boundary crossing.
- Container → Host OS: a critical boundary, especially with privileged containers or dangerous volume mounts.
- Firmware → Hardware security module: in IoT products, the hardware/software chain of trust is a trust boundary with deep security implications.
- Application → Third-party dependency: every open-source library has access to the process — its code could be compromised (supply chain attack).
The practical rule: every time data controlled by a less-trusted entity reaches a more-trusted entity, there is a trust boundary. Draw them all. Then systematically analyze what crosses each one.
STRIDE: The Foundational Methodology
STRIDE, developed by Loren Kohnfelder and Praerit Garg at Microsoft in 1999 and later systematized by Adam Shostack, is the most widely used methodology for software application threat modeling. The reason for its success is simple: it provides a mnemonic framework — six threat categories — that applies systematically to every element of the DFD.
The logic of STRIDE: for each component in the system (every process, every data store, every data flow, every external entity), ask which of the six threat categories apply. The result is a structured set of threats anchored to the system model, not a generic list of CVEs.
An important technical note on STRIDE: not all categories apply to all DFD elements. Processes are vulnerable to all six. Data stores are typically not subject to Spoofing and Repudiation (unless they have their own authentication mechanisms). Data flows are vulnerable to Tampering, Information Disclosure, and DoS. External entities are primarily subject to Spoofing.
Field note: Applying STRIDE mechanically produces a list of banal threats. The value emerges when you use STRIDE as a question framework, not a checklist. For each theoretical threat, ask: Is it realistically exploitable in this system's context? What is the real impact if it materializes? Is there already a mitigation that covers it? This filtering is where the security architect's experience makes the difference.
Beyond STRIDE: Other Methodologies Worth Knowing
STRIDE is not the only tool. The choice of methodology depends on the type of system, team maturity, and operating context.
PASTA — Process for Attack Simulation and Threat Analysis
Use when: complex enterprise systems, risk-centric threat modelingPASTA is a seven-stage risk-oriented methodology: it defines business objectives before analyzing threats, connecting technical vulnerabilities to business impacts. The advantage: output tightly aligned with business priorities. The disadvantage: it is labor-intensive and requires involvement from business, security, and engineering stakeholders. It is the right choice when threat modeling must be justified in ROI terms at the executive level, not just technically.
LINDDUN — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance
Use when: GDPR requirements, sensitive data systems, privacy by designLINDDUN is to STRIDE what GDPR is to ISO 27001 — the same paradigm, specialized for privacy. Its seven categories map privacy threats analogously to how STRIDE maps security threats. If your system processes health data, location data, biometric data, or any data that would require a DPIA, LINDDUN complements STRIDE and feeds directly into the Privacy Impact Assessment.
TARA — Threat Analysis and Risk Assessment
Use when: embedded systems, IoT, automotive (ISO/SAE 21434), CRA complianceTARA is the methodology adopted in automotive (UNECE WP.29, ISO/SAE 21434) and increasingly relevant for IoT systems subject to the CRA. It structures analysis on three levels — asset identification, threat analysis (STRIDE-like), and risk assessment with explicit formulas (likelihood × impact). Its strength is traceability: every mitigation is linked to a specific, verifiable requirement. For CRA, TARA directly produces the cybersecurity risk assessment required by Annex I.
Attack Trees
Use when: deep analysis of specific attack scenarios, red team planningAttack Trees (proposed by Bruce Schneier) model a single attacker objective (e.g., "compromise the user's wallet") as a tree structure where each node represents a sub-goal or action. Child nodes can be AND (all must occur) or OR (one is sufficient). They are extraordinarily effective for deep analysis of complex attack scenarios, identifying the minimum attack path, and planning red team exercises. Not ideal as a primary methodology for complex systems, but powerful as a complement to STRIDE for the most critical threats.
OCTAVE — Operationally Critical Threat, Asset, and Vulnerability Evaluation
Use when: resource-constrained organizations, holistic assessment, enterprise risk managementOCTAVE is closer to an organizational risk assessment framework than a technical threat modeling methodology. It is self-directed and focused on evaluating critical assets from a business and operations perspective. OCTAVE Allegro is suited to mid-sized organizations. Less technically granular than STRIDE, but produces a comprehensive risk picture that includes processes, people, and technology.
From Threat to Mitigation: The STRIDE→Controls Map
A threat model without mitigations is an academic exercise. Real utility emerges when every threat is linked to a specific control, with clear ownership and verification criteria. This is not a one-to-one mapping — many threats require controls at multiple layers (defense in depth).
- Spoofing → Authentication: Strong authentication (not passwords alone), short-lived sessions, validation of all identity claims, mTLS for service-to-service communication, certificate pinning where appropriate.
- Tampering → Integrity: HMAC or digital signature on all critical data in transit, TLS 1.3 with strong cipher suites, binary integrity verification in deployment (artifact signing and verification), parameterized queries or prepared statements to prevent SQL injection.
- Repudiation → Auditability: Structured, centralized, tamper-proof audit logs (WORM storage, log signing), with secure timestamps and event correlation. Logging of all administrative actions and operations on sensitive data. Retention policies appropriate to applicable compliance requirements.
- Information Disclosure → Confidentiality: TLS on all channels (including internal), at-rest encryption for all sensitive data (with key management separate from data), data minimization (never log credentials, PANs, SSNs), error handling that does not expose internal details, HTTP security headers (CSP, X-Content-Type-Options, HSTS).
- Denial of Service → Availability: Multi-layer rate limiting (IP, user, endpoint), circuit breaker pattern, resource quotas for database connection pools and thread pools, rigorous input validation (length, type, structure), timeouts on all I/O operations, mandatory pagination for list queries.
- Elevation of Privilege → Authorization: Explicit authorization model (deny-by-default), RBAC or ABAC with adequate granularity, server-side validation of all access controls (never trust the frontend), least privilege for every service account, sandboxing of high-risk components.
Common mistake: Using TLS as the answer to all Information Disclosure threats. TLS protects data in transit — not at rest, not in logs, not exposed by an unauthenticated endpoint, and not in a debug query returning entire records. Encryption is necessary but not sufficient. Every Information Disclosure threat requires analysis of its specific vector.
Prioritizing Threats: Beyond CVSS
Identifying one hundred threats means nothing if you do not know which to address first. Prioritization is where many threat models lose operational value — either because it is not done, producing a flat, unactionable list, or because CVSS is applied mechanically out of context.
CVSS was designed to score known and specific vulnerabilities in software components. Applying it to architectural threats during threat modeling is methodologically incorrect: TM threats are not CVEs, do not yet have a determined exploitability, and their impact depends heavily on the application's context.
For in-TM prioritization, I use a three-axis approach:
- Contextual exploitability: How realistic is exploitation in this specific system? Consider: technical complexity required, whether the attacker needs physical/logical access, whether preconditions exist (authentication, network position), and the sophistication level of the most likely attacker for this system.
- Business impact: Not abstract technical impact, but the real damage to the business if the threat materializes. Sensitive user data exposure? Reputational damage? Regulatory impact (GDPR, CRA)? Direct financial loss?
- Cost of mitigation: How much does mitigation cost, in terms of engineering effort, added operational complexity, and potential performance impact? A mitigation requiring six months of architectural refactoring has a different risk profile than one solved by two lines of configuration.
The result is a contextual ranking, not an absolute one. High-exploitability threats with critical impact and low-cost mitigation must be addressed immediately. High-exploitability threats with high impact but complex mitigation must be planned with a roadmap and clear ownership — not delegated to the backlog abyss.
Tooling: What Works, What Doesn't
The tool does not make the threat model. A good threat model can be done with paper and pen. A poor threat model with IriusRisk is still a poor threat model. That said, the right tooling reduces friction, improves traceability, and facilitates collaboration.
- Microsoft Threat Modeling Tool: Free, mature, specifically designed for threat modeling with pre-built stencils for Azure, web systems, IoT. Automatically generates STRIDE threats from the DFD. Limited in multi-user collaboration and integration with development tools. An excellent starting point.
- OWASP Threat Dragon: Open source, available as both desktop and web application. More flexible than Microsoft TMT, supports custom templates, but the automatic threat generation engine is less sophisticated. Ideal for teams working in non-Microsoft environments.
- IriusRisk: The most complete enterprise solution. Native integration with Jira, GitHub, Azure DevOps. Pre-configured threat libraries for frameworks (OWASP, NIST, PCI-DSS). Compliance tracking dashboards. The cost is significant and adoption requires investment, but for organizations with dozens of products it is the only scalable solution.
- Threagile: Threat modeling as code — the system model is defined in YAML and threats are generated automatically by a rules-based engine. Output includes diagrams, reports, and a risk matrix. Naturally integrates into CI/CD pipelines. Interesting for DevOps-heavy teams who want to treat the threat model as a versioned artifact.
- draw.io / Miro / Lucidchart: For the diagrammatic part, flexibility matters more than specialized functionality. These tools excel for real-time collaborative sessions. Keep the diagram separate from the threat analysis (a Markdown document or structured sheet).
My preferred setup for mid-sized teams: Threat Dragon (or Microsoft TMT) for the DFD and initial threat generation, a Markdown template for analysis and prioritization, and Jira/GitHub issues for mitigation tracking. Simple, traceable, integrable into the CI/CD pipeline.
Making Threat Modeling Sustainable
The hardest challenge is not doing the first threat model. It is doing the second, third, tenth. Most threat modeling programs die within six months because the process is too heavy, too dependent on a few experts, and too disconnected from the actual pace of development.
Lightweight and iterative, not monolithic
You do not need to threat model the entire system before writing a single line of code. Start with a high-level threat model (Level-0 DFD) at project start, then deepen iteratively on each significant feature. When a developer opens a PR adding a new API endpoint, the question "does this endpoint introduce new trust boundaries?" should be natural, not exceptional.
Security Champions: scaling beyond the security team
A centralized security team cannot threat model every product in a medium-sized organization — there are simply too many systems, too many features, too little time. The solution is to distribute expertise through a Security Champions program: developers from each team who receive specialized training in threat modeling and become local security referents. They do not replace the security architect for critical systems, but multiply the organization's capacity.
Threat model as a PR artifact
A practice I have seen work very well: the threat model becomes a required artifact in PRs that modify system architecture. Not a full document — even just a structured field in the PR description answering: "which trust boundaries does this PR modify? What new threat does it introduce? How is it mitigated?" This moves threat modeling into the daily development flow without requiring dedicated sessions for every small change.
Anti-Patterns: Things That Kill a Threat Modeling Program
The "big bang" threat model
A single monolithic threat model done once a year for a system with 50 microservices. Output: an 80-page Word document that no one reads. The system changes every week; the document is obsolete in two sprints. Threat modeling must be continuous and granular, not an annual event.
Threat modeling without developers
Sessions where the security team analyzes the system in isolation, produces a report, and sends it to developers as a list of "things to fix." Result: no context, no ownership, no change. Threat modeling is a collaborative practice. Developers know the implementation details the security architect does not. Without them, the system model will always be incomplete.
Stopping at threat identification
Producing a list of 40 threats without prioritization or specific mitigations, leaving developers to "figure out how to address them." This is the fastest way to guarantee that threat modeling changes nothing. Every threat must have an owner, a specific mitigation, and a verification criterion.
The DFD that does not match reality
An idealized architectural model of the system "as it should be," not as it runs in production. Missing: the logging services, CI/CD pipelines, automated backups, third-party integrations added "temporarily" two years ago. A threat model built on this kind of DFD produces mitigations for nonexistent threats and ignores the real ones.
Using threat modeling as a compliance tool, not a security tool
Threat modeling because the CISO requires it, because the customer requests it in the RFP, or because the CRA mandates it. Result: a document produced in minimum time with minimum effort that formally satisfies the requirement without changing anything in the product's security posture. This is the kind of threat modeling that gives the discipline a bad reputation.
Threat Modeling and the Cyber Resilience Act
The CRA does not explicitly mention "threat modeling" as a requirement, but its technical obligations are practically impossible to satisfy without a structured threat analysis process:
- Annex I, Part I, §1: "Products with digital elements are designed, developed, and produced in a way that ensures an appropriate level of cybersecurity based on the risks." — It is impossible to determine a level "appropriate to the risks" without first identifying and assessing those risks. Threat modeling is the operational tool for meeting this requirement.
- Annex I, Part I, §2: "Products are made available without known exploitable vulnerabilities" — Systematic STRIDE analysis applied to the DFD is the mechanism for proactively identifying vulnerability classes before release.
- §3(d): Protection against unauthorized access: Trust boundary analysis is the framework that identifies where authentication and authorization controls are missing.
- §3(j): Resilience against DoS attacks: The "Denial of Service" category of STRIDE, applied systematically, produces the specific requirements for rate limiting, resource quotas, and circuit breaking.
For Class II products (industrial firewalls, critical IoT gateways, physical security systems) and Critical, assessment by a notified body will almost certainly include verification of documented and traceable threat modeling processes. Having TARA or STRIDE documented and linked to the product's security requirements is not just best practice — it is how you pass certification due diligence.
Building a Threat Modeling Program That Lasts
From years of building and relaunching threat modeling programs in organizations of various sizes, I arrive at three non-negotiable conclusions:
First: threat modeling must be part of the definition of done for every significant feature, not an extraordinary activity. If it requires special approval, a dedicated meeting, and a 6-page template to fill out, it will not be done. Friction kills adoption.
Second: the system model must be a living artifact. Every PR that modifies the architecture should update the DFD. A threat model on an outdated system is worse than no threat model, because it gives you misplaced confidence.
Third: measure outputs, not inputs. What counts is not how many threat models you produced — it is how many mitigations were implemented, how many architectural vulnerabilities were resolved before release, and how many were not found by external penetration tests because the threat model had already anticipated them. That is the ROI of threat modeling, and that is the number that converts skeptical managers.
The ProductSecurity.it team has built and implemented threat modeling programs for organizations producing IoT hardware, enterprise SaaS platforms, and critical embedded systems. If you want to build a sustainable program — not a document, not a compliance exercise, but a real change in your product's security posture — start by assessing your current maturity.