Un team di sviluppo può fare il threat modeling di una funzionalità in un'ora, se risponde a quattro domande in ordine e ne esce con dei ticket anziché con un documento. Le domande provengono dal Threat Modeling Manifesto: su cosa stiamo lavorando, cosa può andare storto, cosa intendiamo fare al riguardo e se abbiamo fatto un lavoro sufficientemente buono. Non serve un security architect, perché il lavoro non dipende dalle capacità innate di una sola persona.
L'ora in sintesi
| Minuti | Domanda | Risultato |
|---|---|---|
| Prima | - | Una persona prepara la bozza del diagramma di flusso dei dati |
| 0-10 | Su cosa stiamo lavorando | Diagramma corretto, punti di ingresso numerati |
| 10-30 | Cosa può andare storto | Elenco delle minacce, raggruppate per categoria STRIDE |
| 30-45 | Cosa intendiamo fare al riguardo | Una risposta per ogni minaccia |
| 45-55 | Ticket e test | Un ticket e un test per ogni mitigazione |
| 55-60 | Abbiamo fatto un lavoro sufficientemente buono | Verifica di completezza |
Prima della sessione
Scelga una sola funzionalità, non un intero prodotto. Individuare i problemi in fase di progettazione è molto più efficiente che risolvere le falle in produzione, quindi la sessione va svolta prima dell'inizio dello sviluppo.
Inviti uno sviluppatore, il responsabile dei requisiti e, se è coinvolta l'infrastruttura, una persona del team Operations. Una di loro porta una bozza del diagramma di flusso dei dati, realizzata con uno strumento i cui file il team potrà modificare in seguito.
Minuti 0-10: su cosa stiamo lavorando
Il gruppo corregge la bozza. L'OWASP Threat Modeling Cheat Sheet richiede una visione chiara di trust boundary, flussi di dati, data store, processi ed entità esterne, che spesso rappresentano possibili punti di attacco. Verifichi che ciascuno di questi elementi sia presente nel diagramma.
Se alcuni partecipanti non sono tecnici, è meglio ragionare sui flussi alla lavagna anziché insistere sulla notazione DFD.
Numeri i punti di ingresso man mano che procede, usando la notazione major.minor per quelli a più livelli (1, 1.2, 1.2.1), come fa la pagina del processo della community OWASP, e segni anche i punti di uscita. Un messaggio di errore in una pagina di login può abilitare attacchi attraverso il punto di ingresso corrispondente, come l'account harvesting ("username not found") o la SQL injection (tramite gli errori delle eccezioni SQL).
Minuti 10-30: cosa può andare storto
Per una progettazione tecnica, parta da STRIDE. Faccia passare ogni componente, flusso di dati e trust boundary attraverso le sei categorie e annoti per ogni minaccia l'ID del punto di ingresso coinvolto.
| Categoria | Viola | Esempio |
|---|---|---|
| Spoofing | Autenticazione | Token di autenticazione rubato e usato per impersonare un utente |
| Tampering | Integrità | Aggiornamenti non voluti del database tramite l'applicazione |
| Repudiation | Tracciabilità | Log manipolati per coprire le azioni compiute |
| Information Disclosure | Riservatezza | Dati estratti da un database di account utente |
| Denial of Service | Disponibilità | Utente bloccato da numerosi tentativi di autenticazione falliti |
| Elevation of Privileges | Autorizzazione | Un JWT manomesso per cambiare il ruolo |
Per una regola di business, aggiunga i misuse case: azioni eseguite fuori sequenza, ripetutamente, in modo concorrente o per ottenere un esito non previsto. Per un singolo obiettivo dell'attaccante articolato in più passaggi, usi un attack tree. Non aggiunga tecniche solo per sembrare più accurato: spieghi perché ciascuna è adatta e cosa lascia scoperto.
Probabilità per impatto suona ordinato, ma entrambi sono difficili da stimare e il prodotto ignora il costo della correzione. In un'ora basta una valutazione approssimativa alta, media o bassa per ogni minaccia.
Un esempio pratico: il reset della password
Prenda il reset della password. Il diagramma mostra il browser, l'applicazione web, il database utenti e un servizio di posta, con una trust boundary tra Internet e l'applicazione. La richiesta di reset è il punto di ingresso 3 e il link inviato via e-mail è il 3.1 (ID a titolo illustrativo).
Il gruppo individua quattro minacce. Un link di reset funziona per una persona diversa dal titolare (spoofing). Un messaggio "nessun account con questo indirizzo" rivela chi è registrato (information disclosure). Gli eventi di reset non vengono registrati nei log (repudiation). Qualcuno innesca reset ripetuti contro una vittima (denial of service).
Minuti 30-45: cosa intendiamo fare al riguardo
A ogni minaccia si assegna una di queste quattro risposte:
- Mitigare: ridurre la probabilità che la minaccia si concretizzi.
- Eliminare: rimuovere la funzionalità o il componente che la causa.
- Trasferire: spostare su un'altra parte la responsabilità contrattuale o finanziaria.
- Accettare: non fare nulla, perché le altre opzioni non sono compatibili con i vincoli di business.
Il trasferimento di per sé non riduce né la probabilità né il danno, quindi annoti chi è responsabile dei controlli rimanenti e del rischio residuo. Per le minacce accettate, registri chi ha accettato il rischio e per quale motivo.
Minuti 45-55: ticket e test
Trasformi ogni mitigazione concordata in un requisito che uno sviluppatore possa prendere in carico. Basta una riga per minaccia:
| ID minaccia | STRIDE | Ticket | Test |
|---|---|---|---|
| 3.1-S | Spoofing | Rendere i link di reset monouso e di breve durata | Un link usato o scaduto viene rifiutato |
| 3-I | Information Disclosure | Restituire un'unica risposta generica per qualsiasi indirizzo | Indirizzi noti e sconosciuti ricevono risposte identiche |
| 3-R | Repudiation | Registrare nei log ogni richiesta di reset | Un tentativo di reset compare nel log |
È la colonna dei test a rendere il modello qualcosa di più di un diagramma. Ogni mitigazione richiede una verifica che fallisca quando il controllo manca. Gli abuse case si traducono direttamente in test: ripetere la richiesta (replay), inviare i passaggi fuori sequenza, inviare due richieste contemporaneamente. Inserisca i ticket nel backlog della funzionalità, con l'ID della minaccia nel titolo.
Minuti 55-60: abbiamo fatto un lavoro sufficientemente buono
Cominci con una verifica semplice: esistono documenti che mostrano un diagramma, un elenco delle minacce e un elenco dei controlli? Se ne manca uno, la sessione non è conclusa. Verifichi che ogni minaccia abbia una risposta, che ogni mitigazione indichi come il team la implementerà e che i rischi accettati ne riportino la motivazione.
Poi mantenga vivo il modello. Lo aggiorni insieme al sistema e, quando il progetto cambia, riesegua solo le parti interessate.
Da dove iniziare
- Scelga una funzionalità imminente e fissi un'ora con uno sviluppatore, il responsabile dei requisiti e una persona del team Operations.
- Faccia preparare a una persona la bozza del diagramma di flusso dei dati con le trust boundary segnate. Nei primi dieci minuti il gruppo la corregge e numera i punti di ingresso.
- Applichi STRIDE a ogni componente e flusso per 20 minuti, annotando per ogni minaccia l'ID del punto di ingresso interessato.
- Assegni una risposta a ciascuna minaccia, annoti chi è responsabile di ogni rischio accettato o trasferito, quindi crei un ticket e un test per ogni mitigazione.
- Conservi il diagramma, l'elenco delle minacce e l'elenco dei controlli insieme alla documentazione della funzionalità. Se desidera un parere esterno sul primo modello, il nostro servizio di consulenza può rivederlo, e le minacce registrate costituiscono un ottimo perimetro per un successivo penetration test.
