Threat modeling per PMI: identificare i rischi prima di scrivere il codice
Il 16 maggio 2025 sono stato ingaggiato da una finanziaria piemontese di medie dimensioni attiva nel credito al consumo - 42 dipendenti, 180 milioni di euro di impieghi totali, regolamentata dalla Banca d'Italia - per revisionare la sicurezza di un'applicazione di prestiti online che il loro team interno stava sviluppando da otto mesi. Il sistema era in fase pre-lancio, con previsione di go-live a settembre 2025. Il CTO mi aveva chiamato non per un audit tecnico tradizionale (per quello aveva già previsto un penetration test esterno prima del lancio) ma per un esercizio metodologico specifico: threat modeling sistematico dell'architettura applicativa prima che il codice fosse scritto per aree non ancora completate, e dell'architettura esistente per le aree già sviluppate. Il CTO aveva sentito parlare di STRIDE e di Microsoft Threat Modeling Tool ma non aveva mai visto applicare il pattern in contesto reale, e voleva capire se fosse un investimento ragionevole per la sua dimensione o solo teoria accademica.
In due giornate di sessioni strutturate con il CTO, due sviluppatori senior, il responsabile compliance e il DPO dell'azienda, abbiamo condotto un threat modeling completo dell'applicazione applicando sistematicamente la metodologia STRIDE di Microsoft. Il risultato è stato identificazione di 14 rischi significativi specifici al dominio prestiti online. Cinque di questi rischi erano architetturali - avrebbero richiesto refactoring profondo se scoperti dopo il go-live, con costi stimati in 40-80 giornate di sviluppo ciascuno. Sette erano rischi di media gravità risolvibili con modifiche incrementali durante i mesi di sviluppo residui. Due erano rischi di bassa gravità che abbiamo deliberatamente deciso di accettare con mitigazioni compensative (logging specifico, monitoring intensificato). Il costo consulenziale delle due giornate di threat modeling è stato 3.600 euro. Il valore preservato dai cinque rischi architetturali identificati prima del codice - stimato conservativamente in 60 giornate di sviluppo risparmiate su media tariffa interna - è superiore a 48.000 euro di costo opportunity.
Questo articolo descrive il pattern operativo del threat modeling applicabile a PMI italiane, basato sull'esperienza di circa 20 sessioni negli ultimi sei anni in settori vari (finanziario, sanitario, legale, assicurativo, logistica). Il principio guida è uno: threat modeling non è un'attività da esperti di sicurezza remoti - è una sessione di gruppo strutturata fra technology, product e compliance che produce insights azionabili in poche ore. Applicato correttamente al momento giusto del ciclo di sviluppo, è probabilmente l'attività di sicurezza con il ROI più alto nel medio termine.
Cos'è il threat modeling e perché è diverso da penetration test e code review
Il threat modeling è una metodologia strutturata per identificare sistematicamente le minacce a un sistema software analizzandolo dal punto di vista di un attaccante, prima che la minaccia si manifesti. La differenza chiave rispetto ad altre attività di sicurezza è il timing e il focus: threat modeling è proattivo e architetturale, mentre pentest e code review sono reattivi e implementativi.
Un penetration test cerca vulnerabilità in un sistema già costruito, tipicamente vicino o dopo il go-live. Una code review cerca bug in codice specifico già scritto. Un threat modeling cerca minacce all'architettura del sistema - tipicamente durante la fase di design, prima che molto codice sia stato scritto. La differenza di impatto è enorme: un bug di sicurezza trovato in pentest a ridosso del go-live richiede hotfix, può ritardare il lancio, può richiedere rework significativo. Una minaccia identificata in threat modeling fase design viene semplicemente indirizzata nel design successivo, senza rework.
La metodologia più diffusa è STRIDE, sviluppata originariamente da Microsoft e documentata nel Microsoft Threat Modeling Tool ufficiale. STRIDE è un acronimo che identifica sei categorie di minacce universali: Spoofing (impersonare un'entità), Tampering (modificare dati non autorizzatamente), Repudiation (negare un'azione compiuta), Information disclosure (esfiltrazione di dati), Denial of service (interruzione di servizio), Elevation of privilege (accesso a privilegi superiori al dovuto). Per ogni componente del sistema e per ogni flusso di dati fra componenti, il team si chiede sistematicamente: come un attaccante potrebbe spoofare qui? Come potrebbe tamperare? Come potrebbe negare responsabilità? e così via. L'esercizio sistematico cattura minacce che l'intuizione tecnica casuale mancherebbe.
Se stai pianificando lo sviluppo di un nuovo sistema con componenti sensibili (dati personali, finanziari, sanitari, legali) e vuoi introdurre threat modeling nel tuo processo, nel mio profilo professionale trovi il dettaglio delle sessioni di threat modeling che ho guidato in contesti PMI italiane, sempre con approccio calibrato sulla dimensione del team e sulla complessità del dominio.
Il format della sessione: 4 ore, 4 ruoli, 4 output
La sessione di threat modeling efficace richiede tre elementi: tempo dedicato (non spezzone di riunioni), ruoli complementari al tavolo, facilitatore strutturato. Il format standard che applico è una sessione di 4 ore con quattro ruoli presenti.
Primo ruolo: architetto tecnico (CTO o tech lead) - conosce l'architettura proposta e può rispondere a domande tecniche. Secondo ruolo: prodotto (product manager o business owner) - comunica cosa il sistema deve fare dal punto di vista del business e quali sarebbero le conseguenze di specifiche compromissioni. Terzo ruolo: compliance (DPO, consulente privacy, responsabile rischi) - articola i requisiti regolamentari e i rischi di non-compliance. Quarto ruolo: facilitatore di threat modeling (io, nel caso della finanziaria, o un threat modeler interno se l'azienda ha maturato competenza) - conduce la sessione secondo la metodologia, fa domande strutturate, documenta in tempo reale.
L'output standard della sessione è quattro artefatti. Primo artefatto: diagramma del flusso dati (DFD) - rappresentazione visuale dei componenti, dei confini di trust, dei flussi di dati. Secondo artefatto: lista completa delle minacce identificate, ciascuna con categoria STRIDE, componente target, vettore di attacco, probabilità, impatto. Terzo artefatto: mitigazioni proposte per ciascuna minaccia, con owner e priorità. Quarto artefatto: backlog di azioni concrete da integrare nella roadmap di sviluppo.
Il data flow diagram come base di ogni threat modeling
La base tecnica di qualunque sessione di threat modeling è il Data Flow Diagram (DFD) dell'architettura analizzata. Il DFD rappresenta il sistema in termini di entità esterne (utenti, sistemi terzi), processi applicativi, store di dati, e flussi fra questi - con confini di trust esplicitamente marcati.
Per l'applicazione prestiti del cliente piemontese, il DFD iniziale aveva queste componenti principali. Entità esterne: richiedenti (clienti finali che richiedono prestiti), bureau creditizi (Crif, Experian), banca custode (sistema core bancario esterno), operatori interni della finanziaria. Processi: portale web richiesta, motore di valutazione creditizia, motore di firma elettronica, gestione contratti, erogazione pagamenti. Data store: anagrafica richiedenti (PostgreSQL), storico valutazioni (PostgreSQL separato per compliance), contratti firmati (bucket S3), audit trail (tabella dedicata). Confini di trust: internet pubblico (fra richiedente e portale web), DMZ applicativa, rete interna finanziaria, rete interna banca custode.
Ogni attraversamento di confine di trust è un punto critico dove STRIDE va applicato sistematicamente. I flussi dentro lo stesso confine (es. fra due microservizi interni) hanno tipicamente bassa priorità. I flussi che attraversano confini (es. da internet pubblico a portale web, o da portale web a sistema bancario esterno) sono i punti caldi dove le minacce si concentrano.
Applicazione sistematica di STRIDE: l'esercizio che produce valore
Una volta disegnato il DFD, la sessione procede iterando sistematicamente su ogni componente e ogni flusso attraverso le sei categorie STRIDE. Il facilitatore pone domande specifiche come:
- Spoofing sul portale web: "Come può un utente malintenzionato fingersi un richiedente legittimo per sottrarre la sua identità?"
- Tampering sui dati di richiesta: "Come può un attaccante modificare i dati della richiesta (reddito dichiarato, importo richiesto) prima che arrivino al motore di valutazione?"
- Repudiation sui contratti firmati: "Come può un cliente negare di aver firmato un contratto dopo la firma elettronica?"
- Information disclosure sui bureau creditizi: "Come può un attaccante accedere ai dati sensibili del bureau senza autorizzazione?"
- Denial of service sul motore di valutazione: "Come può un attaccante saturare il motore per bloccare l'attività commerciale?"
- Elevation of privilege sull'operatore interno: "Come può un operatore base fare operazioni riservate ai responsabili?"
Per ogni domanda, il team discute scenari concreti, valuta se la minaccia è realistica, identifica mitigazioni possibili. Per il cliente piemontese, questo esercizio ha prodotto insight come il seguente sulla categoria Tampering: "L'attuale architettura prevede che i dati di reddito dichiarato dal richiedente vengano passati dal portale web al motore di valutazione creditizia attraverso una sessione utente di 30 minuti. Un attaccante che compromette la sessione può modificare i dati fra richiesta originale e valutazione, ottenendo prestiti maggiori di quelli che il suo profilo permetterebbe". La mitigazione identificata era la firma crittografica dei dati critici al momento della sottomissione della richiesta, con verifica della firma al momento della valutazione. Questa modifica, applicata in fase di design, è costata circa 3 giornate di sviluppo. Se fosse stata scoperta dopo il go-live, avrebbe richiesto revisione architetturale profonda perché il flusso dati è al centro dell'applicazione.
Il pattern di threat modeling si integra con gli altri pilastri di hardening applicativo che ho descritto nel mio articolo sulla costruzione di una cultura della sicurezza informatica come processo continuo in azienda, dove threat modeling è uno dei componenti metodologici della postura di sicurezza complessiva di una PMI.
Prioritizzazione delle minacce: la matrice impact × probability
Non tutte le minacce identificate sono uguali. Un threat modeling efficace produce tipicamente 20-40 minacce su un'applicazione media; applicare mitigazioni a tutte indistintamente è impraticabile. Il pattern di prioritizzazione che uso è la classica matrice impact × probability.
Per ciascuna minaccia identificata, il team stima. Probabilità (bassa/media/alta): quanto è plausibile che un attaccante provi e riesca in questo attacco, considerando la superficie di esposizione, gli incentivi economici, la difficoltà tecnica. Impatto (basso/medio/alto): se l'attacco riesce, quanto è grave il danno - economico, reputazionale, regolamentare.
Le minacce con alta probabilità e alto impatto vanno mitigate prioritariamente. Le minacce con bassa probabilità e basso impatto possono essere documentate come accettate con mitigazioni compensative (monitoring). Le minacce con alta probabilità ma basso impatto (es. scraping commerciale del catalogo pubblico) o con bassa probabilità ma alto impatto (es. insider malicious dello sviluppatore core) richiedono valutazioni caso per caso.
Per il cliente piemontese, la classificazione delle 14 minacce identificate è stata: 3 alto/alto (priorità massima, mitigate entro il mese), 5 medio/alto o alto/medio (priorità alta, mitigate entro due mesi), 4 medio/medio (priorità normale, integrate nel backlog), 2 basso/basso (accettate con monitoring intensificato). La documentazione di questa classificazione - con motivazione esplicita per ciascuna scelta - è un artefatto di compliance che il DPO può mostrare in caso di istruttoria o audit.
Threat modeling continuo: non solo al design, ma a ogni major change
L'errore comune nell'adozione di threat modeling è trattarlo come attività una tantum al design iniziale. In realtà, il threat landscape cambia con il tempo: nuove feature introdotte nell'applicazione cambiano i flussi di dati, nuove integrazioni con sistemi esterni aprono nuove superfici di attacco, nuove vulnerabilità emergenti in dependency usate modificano il panorama delle minacce. Threat modeling dovrebbe essere ripetuto per ogni major change all'architettura, e come minimo annualmente come revisione completa.
Sul cliente piemontese, dopo la sessione iniziale di maggio 2025, abbiamo pianificato sessioni di threat modeling trimestrali di 2 ore ciascuna dedicate alle modifiche del trimestre corrente. Il pattern è leggero (2 ore vs 8-12 ore della sessione iniziale completa) e produce aggiornamento continuo del modello di minacce senza costo operativo eccessivo. Il pattern è allineato ai principi di DevSecOps per PMI che ho descritto in un articolo dedicato, dove la sicurezza è integrata nel ciclo di sviluppo continuo invece di essere rilegata a attività saltuarie.
Documentazione e integrazione con backlog di sviluppo
L'artefatto finale di una sessione di threat modeling è un documento strutturato che serve a tre scopi: input per il backlog di sviluppo (le mitigazioni diventano ticket concreti), evidenza per audit e compliance (dimostrazione di approccio strutturato alla sicurezza), training interno (il team interiorizza pattern di thinking in termini di minacce).
Il template di documento che uso include. Sezione 1: Scope - cosa è stato modellato, cosa no. Sezione 2: Diagramma data flow - artefatto visuale annotato. Sezione 3: Tabella minacce - per ogni minaccia: ID, categoria STRIDE, componente, descrizione, vettore, probabilità, impatto, priorità, mitigazione proposta, owner, data target. Sezione 4: Decisioni di accettazione rischio - minacce non mitigate con motivazione esplicita. Sezione 5: Appendice tecnica - approfondimenti su specifici pattern di attacco rilevanti per il dominio.
Il documento vive in un repository versionato (Git o wiki interno), accessibile al team tecnico e al responsabile compliance, aggiornato alle successive sessioni di threat modeling. Per il cliente piemontese, il documento è stato incluso nel audit package consegnato alla Banca d'Italia in sede di verifica annuale sulla finanziaria.
Il risultato finale dell'intervento sulla finanziaria piemontese, al termine dei tre mesi di mitigazione e prima del go-live di settembre 2025, è stato il seguente. Le 3 minacce alto/alto identificate a maggio sono state completamente mitigate entro luglio. Le 5 minacce medio/alto o alto/medio sono state mitigate entro agosto con costo di circa 22 giornate di sviluppo. Il penetration test esterno pre-lancio eseguito a settembre 2025 da una security firm milanese ha trovato 0 vulnerabilità critiche, 2 vulnerabilità di media gravità (mitigate prima del lancio), 7 di bassa gravità (gestite post-lancio). Il go-live di settembre è avvenuto senza incidenti di sicurezza. La Banca d'Italia ha valutato positivamente il pacchetto compliance consegnato, con menzione specifica della disciplina di threat modeling come elemento di buona governance. Costo consulenziale dell'intervento di threat modeling iniziale: 3.600 euro. ROI difensivo stimato: oltre 13x sulla prima annualità.
Se gestisci lo sviluppo di applicazioni con componenti sensibili o esposizione regolamentare e non hai ancora introdotto threat modeling sistematico nel tuo processo, probabilmente stai scoprendo le minacce troppo tardi - in penetration test a ridosso del go-live, o peggio, dopo incidenti di produzione. L'introduzione di threat modeling è un investimento metodologico contenuto (2-4 sessioni iniziali di 4 ore ciascuna) che produce beneficio strutturale duraturo. Se vuoi confrontarti sul tuo caso specifico con una proposta di sessione di threat modeling calibrata sul tuo dominio e sulla fase del ciclo di sviluppo in cui ti trovi, contattami per una consulenza preliminare: in una sessione di analisi guidata valutiamo insieme la complessità del tuo sistema, definiamo il scope appropriato della sessione, e pianifichiamo il workflow che integra le mitigazioni identificate nel tuo backlog di sviluppo esistente.