Un modello di minaccia utile spiega cosa proteggi, chi o cosa può influenzarlo, dove cambia la fiducia e come ridurrai e testerai i rischi più importanti. Parti dal progetto reale invece che da un elenco generico di strumenti.
Definisci un ambito abbastanza piccolo da poter ragionare
Inizia con un servizio funzionante: un portale clienti, un sito editoriale o un'applicazione interna. Annota i componenti che gestisci e i sistemi esterni su cui fai affidamento. Un modello di minaccia dovrebbe rendere visibili le ipotesi, non suggerire che ogni possibile attacco sia stato risolto. Mantieni la prima versione abbastanza piccola che le persone che distribuiscono l'applicazione possano spiegarla senza un consulente separato che interpreti il diagramma.
Elenca i risultati e gli asset di valore. Questi possono includere dati dei clienti, accesso amministrativo, stato dei pagamenti, contenuti pubblicati e la capacità di ripristinare il servizio. La disponibilità può essere un asset anche quando le informazioni sono pubbliche. Decidi quali guasti sarebbero scomodi e quali danneggerebbero persone o l'organizzazione. Questa distinzione ti aiuta a dare priorità ai controlli invece di trattare ogni avviso allo stesso modo.
Disegna i punti in cui la fiducia cambia
Le linee guida di OWASP sul modello di minaccia usano flussi di dati e confini di fiducia per rendere comprensibile un design. Per una piccola applicazione ospitata, disegna browser, processo web, database, amministratore, destinazione di backup e integrazioni esterne. Segna le informazioni che si spostano tra loro. Una richiesta che attraversa da un client non attendibile a un'operazione server privilegiata merita validazione e autorizzazione esplicite.
Non presumere che trovarsi nella stessa macchina renda ogni componente ugualmente attendibile. Un processo di upload pubblico non dovrebbe avere gli stessi permessi dell'amministrazione del database. Un job di backup può aver bisogno di accesso in lettura senza la capacità di modificare i record applicativi attivi. Separare questi ruoli rende più facile contenere l'effetto di un componente compromesso e rivedere i permessi necessari.
Scegli scenari di guasto concreti
Usa una manciata di eventi plausibili per mettere alla prova il design. Un attaccante ruba una password amministrativa; un utente richiede il record di un altro utente; un upload riempie il disco; un deployment espone un file di configurazione; una copia di ripristino non può essere ripristinata. Descrivi la condizione iniziale, il componente interessato e la conseguenza. Uno scenario specifico è più facile da testare di un'istruzione generica a migliorare la sicurezza.
Includi errori e abusi legittimi del flusso di lavoro oltre alle intrusioni esterne. Un nuovo tentativo può creare due operazioni valide, oppure due richieste possono competere per modificare lo stesso oggetto. Le linee guida OWASP sulla logica di business evidenziano queste ipotesi di processo. Verifica chi è autorizzato a portare un flusso di lavoro allo stato successivo e se ripetere o riordinare una richiesta cambia il risultato in modo imprevisto.
| Scenario | Controllo da esaminare | Prove da raccogliere |
|---|---|---|
| Credenziale amministrativa rubata | Accesso limitato e un secondo fattore dove supportato | Un accesso non autorizzato non può essere completato |
| Oggetto di un altro utente richiesto | Autorizzazione degli oggetti lato server | Un test isolato restituisce un risultato di accesso negato |
| Disco esaurito dagli upload | Controlli su dimensione, quota e conservazione | Un limite viene applicato prima del guasto del servizio |
| Richiesta di flusso di lavoro duplicata | Idempotenza e confini delle transazioni | Una richiesta ripetuta crea un solo esito |
Dai priorità in base all'impatto e a un percorso credibile
Per ogni scenario, registra il suo impatto potenziale e le condizioni necessarie perché si verifichi. Evita di far finta che un punteggio numerico ipotizzato sia una probabilità precisa. Puoi comunque distinguere una password debole esposta a Internet da un evento locale altamente condizionato. Assegna un responsabile e un passo successivo pratico ai rischi importanti, così il modello crea lavoro che qualcuno può effettivamente completare.
Considera il ciclo di vita delle informazioni oltre alla compromissione dell'applicazione. Un'esportazione diagnostica può divulgare dati non necessari durante un'operazione altrimenti normale. Un campo dell'account conservato può creare esposizione molto tempo dopo la fine del suo scopo. La revisione della privacy può quindi rimuovere informazioni o abbreviare la conservazione, mentre la revisione della sicurezza limita l'accesso a ciò che rimane. Entrambe le modifiche appartengono al modello quando proteggono il progetto.
Testa i controlli in un ambiente autorizzato
Crea un ambiente di staging con autorizzazioni rappresentative e record fittizi. Verifica l'accesso negato, i limiti delle richieste, i nuovi tentativi del flusso di lavoro e il ripristino. Non usare dati reali dei clienti quando dati sintetici possono dimostrare il comportamento. L'obiettivo è verificare il controllo, non generare traffico di attacco impressionante. Rimani all'interno dei sistemi che possiedi o che sei esplicitamente autorizzato a valutare.
Registra cosa è passato, cosa ha fallito e cosa rimane sconosciuto. Il risultato di uno scanner può contribuire come prova, ma non sostituisce un test delle regole di business dell'applicazione. Allo stesso modo, un'opzione di protezione di rete non verifica l'autorizzazione degli oggetti o la gestione dei file segreti. Allega i risultati utili allo scenario, così i futuri manutentori capiscono perché esiste un particolare controllo.
Mantieni il modello collegato al cambiamento
Esamina le parti rilevanti quando aggiungi un'integrazione, esponi un nuovo endpoint, modifichi un privilegio o sposti dati verso un'altra destinazione. Non è necessario ridisegnare l'intera architettura per una piccola modifica di testo. L'innesco è un'ipotesi cambiata su accesso, informazioni o comportamento del sistema. Tieni il modello accanto alla documentazione di distribuzione e ripristino, invece di lasciarlo come risultato di un workshop una tantum.
SwissOctet fornisce un catalogo di scelte infrastrutturali, non un modello di minaccia completo dell'applicazione. Scegli la configurazione e le opzioni che supportano i tuoi controlli, poi verifica la distribuzione che realizzi. Un modello piccolo e mantenuto con azioni testate è più utile di una grande raccolta di prodotti di sicurezza senza una chiara spiegazione dei rischi che affrontano.
La tua checklist pratica.
- Elenca gli asset e le conseguenze del guasto.
- Disegna i flussi di dati e i confini di fiducia.
- Scegli scenari specifici di intrusione, errore e flusso di lavoro.
- Assegna controlli e responsabili ai rischi importanti.
- Esegui test con dati sintetici in un ambiente autorizzato.
- Rivedi il modello quando cambia un'ipotesi rilevante.
I dettagli che contano.
Serve un framework formale per iniziare?+
No. Un piccolo diagramma e un insieme documentato di scenari possono essere utili. Un framework aiuta a garantire che i rischi vengano esaminati in modo coerente.
Uno scanner di vulnerabilità sostituisce il threat modeling?+
No. Gli scanner possono trovare debolezze tecniche, mentre un modello di minaccia esamina anche ipotesi di progettazione, autorizzazioni e flussi di lavoro aziendali.
Con quale frequenza devo aggiornare il modello?+
Aggiorna le parti interessate quando cambiano flussi di dati, integrazioni, privilegi o funzionalità esposte, e rivedi regolarmente i rischi irrisolti.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- OWASP: Cheat Sheet sul Threat Modeling cheatsheetseries.owasp.org
- OWASP: Threat modeling nella pratica devguide.owasp.org
- OWASP: Sicurezza della logica di business cheatsheetseries.owasp.org
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.