Registri e rapporti del modello delle minacce
Sytance · Aggiornato
Un modello delle minacce registra l’architettura del prodotto, gli scenari di attacco, i controlli di sicurezza e i risultati della verifica. Collegando questi record, un revisore può seguire il ragionamento dall’attacco alla misura scelta per affrontarlo. L’esempio del gateway mostra come si integrano i record; le sezioni seguenti spiegano cosa registrare e come riesaminarlo.
Come organizzare il modello
Tenere insieme il diagramma e l’analisi oppure collegarli tramite identificativi stabili. Un documento è adatto a una revisione circoscritta; i record strutturati sono utili quando lo stesso controllo affronta più minacce o il team deve confrontare diverse release.
In Sytance, il team modifica l’architettura e i record delle minacce nell’area di lavoro, quindi collega i requisiti di sicurezza, i design e i record di verifica pertinenti. Il modulo di documentazione usa le informazioni dell’area di lavoro per preparare i rapporti.
Informazioni sul prodotto e ipotesi
Identificare versione del prodotto, distribuzione, finalità e persone che lo utilizzano. Indicare le parti incluse nell’analisi, le dipendenze esterne e le eventuali esclusioni che incidono su un percorso di attacco.
Le indicazioni OWASP sulla scomposizione distinguono punti di ingresso, asset e livelli di fiducia. Usare queste distinzioni per spiegare l’architettura, invece di trasformare ogni asset in un processo separato nel diagramma.
- Contesto: prodotto, release, ambiente, finalità e responsabile della revisione.
- Architettura: revisione del diagramma, processi, archivi, entità esterne e flussi.
- Obiettivi di protezione: dati e funzioni che richiedono riservatezza, integrità o disponibilità.
- Ipotesi: ogni condizione incerta, il relativo responsabile e un modo per confermarla.
Registrare ogni scenario di attacco separatamente
Assegnare a ogni minaccia un identificativo stabile e collegarla al pertinente elemento o flusso del diagramma. Descrivere chi potrebbe attaccare, l’accesso necessario, l’azione, la debolezza e la conseguenza. Indicare le condizioni da cui dipende lo scenario.
Esempio TM-01: un utente del gateway con accesso in sola lettura chiama l’API di scrittura della configurazione. Se l’API verifica l’autenticazione senza controllare l’autorizzazione alla scrittura, l’utente può modificare la destinazione della telemetria. Il flusso interessato va dal browser all’API di gestione e l’attacco minaccia l’integrità della configurazione memorizzata.
Una voce che dice solo «elevazione dei privilegi, rischio alto» non spiega questo scenario. Aggiungere la motivazione del rischio: l’account necessario, l’esposizione dell’endpoint, l’impatto realistico e i controlli esistenti considerati.
Controlli, attuazione e verifica
Per TM-01, il controllo proposto AC-01 richiede che l’API di gestione verifichi autorizzazioni per azione e risorsa a ogni scrittura della configurazione. Il record di attuazione dovrebbe indicare la modifica pertinente. Il record di verifica dovrebbe includere il risultato effettivo della prova per la release indicata.
- Decisione: ridurre, rimuovere o accettare il rischio, con motivazione e responsabile.
- Controllo: comportamento richiesto e fasi della minaccia affrontate.
- Attuazione: componente, riferimento alla modifica e versione del prodotto.
- Verifica: preparazione, azione, risultato atteso, risultato osservato e collegamento alle evidenze.
- Rischio residuo: condizioni irrisolte e decisione autorizzata della revisione.
Risultati attesi e osservati
Per il gateway fittizio, il risultato atteso è che una richiesta di scrittura da un utente in sola lettura venga rifiutata e che la configurazione memorizzata resti invariata. Il risultato osservato registra ciò che è avvenuto durante la prova. Finché la prova non viene eseguita, il campo resta in sospeso.
La stessa distinzione vale per i controlli. «Verifica della firma pianificata» e «verifica della firma attuata e collaudata» comunicano livelli di fiducia diversi. Conservare tale distinzione quando si trasferisce il record in un rapporto o in un altro strumento.
Riesame del modello completato
Chiedere a un revisore di seguire un attacco dal diagramma al controllo selezionato e al risultato della prova. Se non riesce a seguire i collegamenti, stabilire se manca un record o se l’attacco va spiegato meglio.
Verificare che la release indicata corrisponda al diagramma, che ogni scenario abbia una decisione sul trattamento e che i rischi accettati identifichino chi li ha accettati. Mantenere le ipotesi irrisolte in un elenco con il relativo responsabile e un modo per confermarle.
Dopo aver aggiornato i record dell’area di lavoro, aprire Documentazione e selezionare il rapporto pertinente. In base alla configurazione e al piano dell’area di lavoro, Sytance offre anteprime HTML e output PDF o DOCX. Prima di usarlo in una revisione, controllare che il rapporto generato corrisponda alla versione corrente del prodotto, all’analisi e alle evidenze di verifica.