C'è un momento specifico in ogni progetto in cui si decide — spesso senza rendersene conto — quanto sarà sicura quell'applicazione. Non è quando si configura il firewall. Non è quando si fa il penetration test prima del go-live. È molto prima: quando si disegna il sistema su una lavagna e si decide come le parti si connettono tra loro.
Quel momento è l'unico in cui il costo di correggere un problema di sicurezza è quasi zero. Dopo, cresce esponenzialmente.
Il Threat Modeling è la pratica che mi permette di sfruttare quel momento. In questo articolo spiego come la applico concretamente — non la versione da manuale, ma quella che uso davvero.
Il Threat Modeling è un processo strutturato per rispondere a quattro domande prima che il sistema esista:
Sembra semplice. Non lo è, perché richiede di pensare come un attaccante mentre stai ancora costruendo. È una modalità mentale che si allena nel tempo.
Esistono diversi framework per il Threat Modeling. Io uso STRIDE, sviluppato da Microsoft, perché è pratico e si adatta bene ai progetti applicativi su cui lavoro.
Ogni lettera rappresenta una categoria di minaccia:
| Lettera | Minaccia | Domanda che mi pongo |
|---|---|---|
| S | Spoofing | Qualcuno può fingere di essere qualcun altro? |
| T | Tampering | Qualcuno può modificare dati o componenti? |
| R | Repudiation | Un utente può negare di aver fatto qualcosa? |
| I | Information Disclosure | Dati sensibili possono essere esposti? |
| D | Denial of Service | Il sistema può essere reso non disponibile? |
| E | Elevation of Privilege | Qualcuno può ottenere permessi che non ha? |
Non applico STRIDE come una checklist meccanica. Lo uso come lente: prendo ogni componente del sistema e chiedo — per ognuna delle sei categorie — se c'è una minaccia plausibile.
Immagina un sistema di gestione documentale con tre attori: utente finale, API backend, storage cloud. È un sistema comune, e nasconde più superfici di attacco di quanto sembri.
Prima di ragionare sulle minacce, mappo il sistema. Non serve uno strumento sofisticato — uso spesso carta e penna o Excalidraw. L'importante è identificare:
Le trust boundary sono cruciali. Ogni volta che un dato attraversa un confine — dall'esterno verso il backend, dal backend verso il database — lì si nasconde una minaccia potenziale.
Prendo ogni flusso di dati e processo, e ragiono sistematicamente.
Esempio — flusso "Utente → API":
Esempio — flusso "API → Storage cloud":
Questo processo mi porta a scoprire minacce che normalmente emergerebbero solo durante un pentest — o peggio, in produzione.
Non tutte le minacce meritano lo stesso sforzo. Per ogni minaccia identificata valuto due dimensioni:
Le minacce ad alta probabilità e alto impatto vengono mitigate subito, in fase di design. Quelle a bassa probabilità e basso impatto vengono documentate e monitorate. Le altre stanno nel mezzo — le gestisco con controlli compensativi.
Ogni minaccia identificata diventa un requisito di sicurezza esplicito. Non una nota a margine — un task nel backlog, con la stessa priorità di una feature.
Questo è il passaggio che fa più differenza nella pratica. Se la contromisura non diventa un task tracciato, sparisce nella frenesia dello sviluppo.
Fare Threat Modeling solo alla fine. Se lo fai quando il sistema è già costruito, stai facendo una security review, non Threat Modeling. Il valore è nell'anticipazione, non nella diagnosi.
Coinvolgere solo i security specialist. Il Threat Modeling funziona meglio quando ci sono anche i developer e i designer di sistema. Chi conosce il codice sa dove sono le scorciatoie, i casi limite, le integrazioni problematiche. Quella conoscenza è oro.
Cercare minacce esotiche ignorando quelle banali. Il 90% delle vulnerabilità reali viene da cose semplici: input non validato, credenziali hardcoded, endpoint non autenticati lasciati per test. STRIDE aiuta a non dimenticarle.
Non aggiornarlo. Il sistema cambia, le minacce cambiano. Un Threat Model fatto una volta e dimenticato è quasi inutile. Lo tratto come un documento vivo — lo rivedo ad ogni cambio architetturale significativo.
Un Threat Modeling fatto bene richiede qualche ora. Un incidente di sicurezza in produzione — con remediation, comunicazione agli utenti, possibili implicazioni legali — richiede settimane e lascia cicatrici durature sulla reputazione del prodotto.
Non è una questione di paranoia. È ingegneria del rischio applicata al software.
Ho iniziato a fare Threat Modeling sistematicamente qualche anno fa, dopo aver trovato in fase di review una vulnerabilità di Elevation of Privilege che sarebbe passata inosservata fino al primo pentest. Da quel momento è diventata una parte fissa del mio processo di design — non opzionale, non "se c'è tempo".
Il Threat Modeling non richiede strumenti costosi né certificazioni specifiche. Richiede disciplina, un framework semplice come STRIDE, e la volontà di pensare come un attaccante prima che lo faccia qualcun altro.
Se non l'hai mai applicato su un tuo progetto, inizia dal prossimo. Prendi il diagramma architetturale, traccia le trust boundary, e chiediti: cosa può andare storto qui? Sarai sorpreso da quello che trovi.
Sviluppatore dalla nascita, oggi mi occupo di architetture Front-end e Back-end in ambito enterprise. Credo fermamente che la tecnologia debba essere condivisa: per questo ho aperto questo blog, dove riverso tutto ciò che imparo tra una riga di codice e l'altra. Quando non sono davanti a un terminale, mi trovi su un palco teatrale o su un campo sportivo. Qui condivido la mia visione sulla programmazione e la sicurezza informatica, cercando di rendere semplice ciò che è complesso. [..]
