Esempio STRIDE: un gateway industriale
Sytance · Aggiornato
STRIDE usa sei categorie di minacce per esaminare come un sistema potrebbe essere attaccato. Il gateway industriale fittizio seguente illustra uno scenario per ciascuna categoria, con un controllo proposto e un criterio di prova. Gli esempi descrivono possibili attacchi e prove pianificate.
Il gateway e i suoi confini di fiducia
Un operatore usa un browser per chiamare l’API di gestione del gateway. L’API legge e scrive in un archivio di configurazione locale. Un controller locale invia dati operativi al gateway, che inoltra la telemetria a un servizio remoto. Un servizio di aggiornamento separato fornisce pacchetti firmware.
In questo esempio, le connessioni di gestione e telemetria usano TLS. L’autenticazione dell’interfaccia del controller e il meccanismo di fiducia degli aggiornamenti restano questioni progettuali aperte. La posizione nella rete locale non stabilisce di per sé l’identità o l’autorità del mittente.
- Browser → API di gestione: sessioni, richieste di stato e modifiche della configurazione.
- API di gestione → archivio di configurazione: impostazioni memorizzate e accesso ai segreti.
- Controller locale → gateway: input operativo dalla rete del sito.
- Gateway → servizio di telemetria: identità del dispositivo e dati di telemetria.
- Servizio di aggiornamento → gateway: metadati del pacchetto e contenuto firmware.
Spoofing dell’identità sull’interfaccia del controller
Un attaccante sulla rete del sito invia messaggi che dichiarano di provenire dal controller locale. Se il gateway si fida solo di un indirizzo di origine, dati operativi contraffatti possono entrare nel flusso di telemetria.
Controllo proposto: stabilire l’identità del dispositivo e verificarla prima di accettare i messaggi. Se il controller non supporta l’autenticazione, valutare altri modi per proteggere l’interfaccia e gli attacchi che restano possibili. Un segmento di rete da solo non prova l’origine del messaggio.
Criterio di verifica: i messaggi provenienti da un’identità di prova non riconosciuta vengono rifiutati, mentre quelli del controller approvato continuano a funzionare. Acquisire il rifiuto e confermare che il valore contraffatto non sia arrivato al servizio di telemetria.
Manomissione del firmware prima dell’installazione
Un attaccante sostituisce un pacchetto ottenuto tramite un punto di distribuzione compromesso. La cifratura del trasporto fino a tale punto non dimostrerebbe che il pacchetto sia stato autorizzato dal fabbricante.
Controllo proposto: verificare la firma del pacchetto rispetto a un trust anchor autorizzato prima dell’installazione. Vincolare la verifica ai byte da installare e al prodotto consentito. Decidere separatamente come gestire versioni firmate meno recenti e chiavi di firma revocate.
Criterio di verifica: un pacchetto alterato e uno firmato con una chiave non attendibile vengono rifiutati prima dell’installazione. Dopo il rifiuto, il gateway deve restare nello stato operativo o di ripristino specificato.
Modifiche della configurazione non tracciabili
Un operatore autorizzato modifica la destinazione della telemetria, ma il record non contiene l’identità individuale né l’esito. Il team non può attribuire in modo affidabile la modifica o distinguere una scrittura riuscita da una richiesta respinta.
Controllo proposto: registrare identità autenticata, azione, obiettivo, ora ed esito. Proteggere l’accesso ai registri e definire il comportamento quando lo spazio di archiviazione è esaurito. Non inserire password o token di accesso nel registro.
Criterio di verifica: una modifica controllata genera il relativo record, un utente non autorizzato non può modificarlo e il comportamento di audit a spazio esaurito corrisponde alla policy documentata.
Segreti esposti tramite la lettura della configurazione
Un endpoint di stato restituisce l’intero oggetto di configurazione, comprese le credenziali di telemetria. Un utente autorizzato a visualizzare lo stato riceve informazioni non necessarie al proprio ruolo.
Controllo proposto: restituire una risposta specifica per lo scopo con i campi segreti omessi e applicare le autorizzazioni alle letture della configurazione. La cifratura in transito non elimina una risposta con dati eccessivi.
Criterio di verifica: esaminare le risposte per ogni ruolo supportato e confermare che i valori segreti non compaiano nelle risposte, negli errori o nei registri.
L’elaborazione degli input esaurisce le risorse del gateway
Un mittente invia messaggi del controller sovradimensionati o ripetuti. Analisi e buffering consumano risorse necessarie al gateway anche per la gestione e la telemetria.
Controllo proposto: limitare le dimensioni dei messaggi e delle code, convalidare gli input prima delle operazioni costose e isolare l’elaborazione critica. Definire i limiti sulla base della capacità misurata e del comportamento richiesto al prodotto in condizioni di sovraccarico.
Criterio di verifica: in un ambiente di prova autorizzato, esercitare i casi di sovraccarico concordati e osservare memoria, profondità delle code, disponibilità del servizio e ripristino. I limiti di accettazione derivano dai requisiti di questo prodotto; non si presume alcuna frequenza universale.
Un utente in sola lettura raggiunge un’operazione di scrittura
Un utente può autenticarsi e visualizzare lo stato. Chiama direttamente un’API di scrittura della configurazione, aggirando l’interfaccia. Se l’API verifica solo l’autenticazione, l’utente acquisisce una capacità riservata agli amministratori.
Controllo proposto: applicare sul server autorizzazioni per azione e risorsa a ogni percorso di scrittura. Mantenere la stessa regola per le richieste normali, le operazioni in blocco e gli endpoint di manutenzione.
Criterio di verifica: le richieste di scrittura dirette da un account in sola lettura non riescono e la configurazione memorizzata resta invariata. Ripetere con un account autorizzato per verificare che l’operazione prevista continui a riuscire.
Copertura e rischi residui
Le sei categorie seguono le definizioni STRIDE di Microsoft. Gli scenari di attacco e i controlli dipendono dall’architettura del gateway descritta sopra.
Un prodotto reale può presentare più scenari di attacco in una categoria e un attacco può rientrare in più categorie. L’analisi deve inoltre comprendere le interfacce di produzione, manutenzione e ripristino, se presenti nel prodotto.
Dopo aver implementato e collaudato un controllo, valutare gli attacchi ancora possibili rispetto ai criteri di rischio concordati. La decisione risultante si applica alla release del prodotto analizzata.