Modellazione delle minacce: architettura, scenari di attacco e controlli
Sytance · Aggiornato
La modellazione delle minacce è un metodo strutturato per identificare come un prodotto potrebbe essere attaccato e scegliere misure per ridurre il rischio. L’analisi parte dall’architettura del prodotto e spiega come potrebbe riuscire un attacco, quali elementi interesserebbe e come verificare la protezione proposta.
Versione del prodotto e distribuzione
Un modello delle minacce si applica a una specifica versione e distribuzione del prodotto. Un gateway connesso a Internet e lo stesso gateway su una rete di manutenzione isolata possono avere punti di ingresso e ipotesi operative diversi.
Invitare le persone che conoscono architettura, sviluppo, uso del prodotto e sicurezza. Prima della sessione, raccogliere materiale sufficiente per spiegare un’operazione normale dall’inizio alla fine.
- La release, la distribuzione supportata e gli utenti previsti.
- L’architettura, le interfacce esterne e i dati scambiati.
- I privilegi di ciascun utente, servizio e processo locale.
- I dati sensibili, le credenziali e le funzioni del prodotto da proteggere.
- I controlli esistenti e le ipotesi ancora da confermare.
Flussi di dati e confini di fiducia
Un diagramma dei flussi di dati (DFD) mostra entità esterne, processi, archivi di dati e relativi movimenti. Un confine di fiducia indica un cambiamento di fiducia o autorità. Può trovarsi tra un browser e un’API, tra due account del sistema operativo oppure tra un dispositivo e un servizio remoto.
Per ogni flusso indicare direzione, descrizione dei dati e meccanismo di protezione. Un riquadro con etichetta «cloud» nasconde troppi dettagli se i diversi servizi hanno identità e autorizzazioni distinte. Suddividere il riquadro quando tale differenza modifica l’analisi.
Per l’esempio del gateway industriale, iniziare dal browser dell’operatore, dall’API di gestione del gateway, dall’archivio di configurazione locale, dal controller locale, dal servizio di telemetria e dal servizio di aggiornamento. Mostrare gestione e telemetria come connessioni TLS. Considerare la verifica della firma degli aggiornamenti un controllo proposto finché la relativa implementazione non è accertata.
Dalle categorie STRIDE agli scenari di attacco
STRIDE raggruppa le minacce in spoofing, manomissione, ripudio, divulgazione di informazioni, negazione del servizio ed elevazione dei privilegi. Usare queste categorie per porre domande su ogni processo e flusso pertinente. Il solo nome di una categoria non descrive un attacco.
Ad esempio: un utente con accesso in sola lettura invia direttamente all’API di gestione una richiesta di modifica della configurazione. Se l’API verifica il login ma non l’autorizzazione all’azione, l’utente può modificare la configurazione del gateway. Ciò identifica un attore, un punto di ingresso, un controllo mancante e un impatto.
Collegare ogni scenario alla relativa interfaccia, processo o flusso nel diagramma. Gli scenari con diverse condizioni di attacco o controlli richiedono analisi separate. Se una condizione è sconosciuta, ad esempio l’autenticazione sull’interfaccia del controller, registrare cosa occorre confermare.
Priorità dei rischi e controlli di sicurezza
Le priorità dei rischi dipendono dall’accesso e dalle capacità necessari all’attaccante, dalla probabilità di successo e dalle conseguenze per il prodotto. Un metodo di valutazione concordato rende coerenti tali giudizi. Esplicitare il ragionamento alla base di un punteggio consente ad altri di riesaminarlo.
Scegliere una risposta che il team possa attuare. Per lo scenario di modifica della configurazione, richiedere che l’API applichi l’autorizzazione del chiamante a ogni operazione di scrittura. Assegnare un responsabile, una release obiettivo e una verifica che dimostri il funzionamento del controllo.
TLS protegge una connessione di trasporto, ma non stabilisce se un utente autenticato possa modificare la configurazione. Valutare il controllo rispetto alla precisa fase dell’attacco che deve impedire. Se il team accetta il rischio residuo, conservare la motivazione e l’identità della persona autorizzata a prendere tale decisione.
Verifica e aggiornamenti del modello
Un controllo proposto e un controllo verificato rappresentano stati diversi. Collegare un controllo attuato alla modifica pertinente e al relativo esito di verifica. Per l’esempio API, inviare una richiesta di scrittura con un utente in sola lettura e confermare sia il rifiuto sia l’assenza di modifiche alla configurazione.
Riesaminare il modello se cambiano un’interfaccia, un’autorizzazione, un componente, una distribuzione o un meccanismo di aggiornamento. Anche nuove informazioni sulle vulnerabilità possono invalidare un’ipotesi precedente. Conservare il modello precedente affinché il team possa spiegare a quali release si applicava una decisione.