Perché il threat modeling è importante

Il threat modeling è una pratica strutturata che consiste nell'individuare ciò che può andare storto in un sistema prima che lo scoprano gli attaccanti. Si analizza il progetto, si enumerano le possibili minacce e si decide come mitigarle.

Risponde a quattro domande fondamentali:

• Che cosa stiamo costruendo?
• Che cosa può andare storto?
• Che cosa faremo al riguardo?
• Abbiamo fatto un buon lavoro?

Il threat modeling applica il principio dello shifting left: affrontare la sicurezza nelle prime fasi del ciclo di sviluppo, invece che dopo la distribuzione.

Il costo della correzione di un difetto cresce notevolmente quanto più tardi viene individuato:

• Fase di progettazione — modificare un diagramma, a costo quasi nullo
• Sviluppo — riscrivere parte del codice
• Produzione — patch d'emergenza, incidente, possibile violazione

Individuare un difetto di progettazione prima di scrivere una sola riga di codice è la soluzione meno costosa possibile.

Il threat modeling impone un deliberato cambio di prospettiva: smettere di pensare a come il sistema dovrebbe funzionare e iniziare a pensare a come può essere abusato.

Chi difende il sistema si concentra naturalmente sulle funzionalità e sui percorsi di successo. Gli attaccanti cercano:

• Input che non vengono convalidati
• Ipotesi di fiducia che possono essere infrante
• Passaggi che possono essere saltati o rieseguiti
• Dati che dovrebbero essere protetti ma non lo sono

Il modeling rende sistematico, anziché casuale, questo approccio avversariale.

Tre termini sono alla base di ogni threat model. È importante distinguerli:

• Asset — qualcosa di valore che merita protezione (dati dei clienti, credenziali, disponibilità)
• Minaccia — un potenziale evento o attore dannoso (un attaccante che ruba i dati)
• Vulnerabilità — una debolezza che consente a una minaccia di avere successo (un controllo degli accessi mancante)

Il rischio emerge quando una minaccia può sfruttare una vulnerabilità ai danni di un asset di valore.

Non è possibile proteggere ciò che non è stato individuato. Inizi ogni threat model elencando ciò che conta.

Categorie comuni di asset:

Il threat modeling è più utile in momenti specifici, non come attività da svolgere una sola volta:

• Quando si progetta un nuovo sistema o una nuova funzionalità
• Quando si apporta una modifica significativa all'architettura
• Quando si aggiunge un nuovo confine di fiducia (una nuova integrazione o API esterna)
• Dopo un incidente di sicurezza, per individuare lacune correlate

I team maturi lo considerano un'attività continua e rivedono il modello man mano che il sistema evolve.

Il threat modeling è un'attività di squadra. Un modello creato da una sola persona non considera abbastanza elementi del contesto.

Una sessione efficace include:

• Sviluppatori che conoscono il funzionamento effettivo del sistema
• Architetti che comprendono gli obiettivi della progettazione
• Security engineer che conoscono i modelli di attacco
• Product owner che comprendono l'impatto sul business

È la combinazione di prospettive a far emergere minacce che nessun singolo ruolo riuscirebbe a individuare.

Esistono diverse metodologie strutturate; può combinarle secondo necessità:

• STRIDE — classifica le minacce per tipologia; ideale per i progetti tecnici (sarà trattata nella prossima lezione)
• PASTA — incentrata sul rischio, collega le minacce all'impatto sul business
• Alberi degli attacchi — modellano gli obiettivi e i percorsi dell'attaccante
• DREAD — un modello di valutazione per stabilire le priorità dei rischi

STRIDE è il punto di partenza più comunemente insegnato perché è sistematico e accessibile.

Un modello delle minacce è utile solo se produce risultati concreti. In genere, i deliverable includono:

• Un diagramma del sistema e dei relativi confini di attendibilità
• Un elenco delle minacce identificate, suddivise per categoria
• Una valutazione del rischio per ogni minaccia
• Mitigazioni o decisioni relative all'accettazione del rischio
• Attività assegnate ai responsabili

Un modello delle minacce che si conclude con un documento su cui nessuno interviene è fallito.

Le attività di modellazione delle minacce spesso falliscono in modi prevedibili. Eviti queste insidie:

• Voler coprire tutto — tentare di modellare l'intero sistema in una volta sola; definisca invece un ambito ristretto
• Paralisi da analisi — discussioni interminabili senza arrivare a decisioni
• Trattarla come un adempimento — produrre un documento per soddisfare un auditor senza mai intervenire
• Mancanza di seguito — identificare le minacce senza mai tenere traccia delle mitigazioni

Mantenga l'attività circoscritta, con tempi definiti e collegata ad azioni concrete.

Se non ha mai eseguito una modellazione delle minacce, inizi in piccolo con questa procedura essenziale:

• Disegni un diagramma semplice del sistema e dei flussi di dati
• Indichi dove i dati attraversano un confine di attendibilità
• Per ogni confine, si chieda che cosa potrebbe fare un attaccante
• Annoti le minacce principali e una mitigazione per ciascuna
• Assegni i responsabili e riprenda l'analisi in seguito

Anche una sessione di 30 minuti alla lavagna permette di individuare problemi che altrimenti arriverebbero in produzione.

Metta alla prova la sua comprensione dei fondamenti della modellazione delle minacce.

Ha imparato perché la modellazione delle minacce è importante:

• La modellazione delle minacce permette di individuare sistematicamente cosa può andare storto prima che lo scoprano gli attaccanti
• Anticipa la sicurezza nel ciclo di sviluppo, rendendo le correzioni molto meno costose
• Distinga tra risorse, minacce e vulnerabilità; il rischio nasce dall'intersezione tra questi elementi
• Esegua la modellazione in fase di progettazione e in occasione dei cambiamenti importanti, coinvolgendo un team interfunzionale
• Eviti insidie come tentare di coprire tutto e non dare seguito alle attività; produca sempre risultati concreti

Ora imparerà il framework STRIDE per classificare le minacce.