Integrazione della modellazione delle minacce con DevOps
Questo post è stato scritto da Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez e Ben Hanson
Introduzione
La modellazione delle minacce è un metodo di sicurezza importante che consente di identificare e classificare in ordine di priorità le mitigazioni dei rischi più importanti per un'applicazione o un sistema. Questo documento contiene alcune riflessioni su come è possibile adottare la modellazione delle minacce in modo più efficace ed efficiente, integrandola con metodologie e strumenti DevOps moderni e concentrandosi sul valore fornito a tutti i vari attori coinvolti nel ciclo di vita dello sviluppo software.
È questo documento per te?
Questo documento è il risultato del lavoro di un piccolo team di esperti di modellazione della sicurezza e delle minacce di Microsoft e incorpora input e idee di alcuni degli esperti più importanti di microsoft. Tenta di affrontare una domanda semplice ma urgente: cosa dobbiamo fare per garantire che il processo di modellazione delle minacce usato venga aggiornato ai requisiti moderni imposti dalle metodologie Agile e DevOps, in modo da fornire il valore richiesto al costo più basso?
Se si è un proprietario del prodotto, il membro di un team di sicurezza o semplicemente uno sviluppatore che sta valutando di adottare la modellazione delle minacce come parte del ciclo di vita di sviluppo, questo documento è per te.
Analogamente, se è già stata adottata la modellazione delle minacce, è comunque possibile trovare idee pratiche per migliorare il processo.
Tuttavia, il documento è progettato per introdurre idee per migliorare i processi correnti o adottare correttamente la modellazione delle minacce come parte del processo DevOps. Non introduce strumenti o prodotti specifici, anche se è la nostra speranza di vedere queste idee implementate da alcuni strumenti o prodotti in futuro. Pertanto, qui non troverai annunci di nuovi strumenti o anteprime delle funzionalità future.
Perché la modellazione delle minacce è importante?
La modellazione delle minacce è uno degli approcci principali alla progettazione sicura di soluzioni software. Tramite la modellazione delle minacce, si analizza un sistema che identifica i vettori di attacco e si sviluppano azioni per mitigare i rischi derivanti da tali attacchi. La modellazione delle minacce è un componente eccellente di qualsiasi processo di gestione dei rischi. Può anche contribuire a ridurre i costi identificando e risolvendo tempestivamente i problemi di progettazione. Un vecchio studio di NIST ha stimato il costo di correzione di un problema di progettazione nel codice di produzione di circa 40 volte superiore rispetto al ripristino durante la fase di progettazione. Consente inoltre di evitare di incorrere in costi dovuti a eventi imprevisti di sicurezza per eventuali problemi di progettazione. Si consideri che il rapporto costo della violazione dei dati 2022 da IBM Security e l'Istituto Ponemon stima il costo medio di una violazione dei dati pari a $ 4,35 milioni. Per le cosiddette mega violazioni, che coinvolgono la compromissione di oltre 50 milioni di record, il costo medio raggiunge $ 387M!
La modellazione delle minacce è la prima attività che è possibile eseguire per proteggere la soluzione perché opera sulla progettazione della soluzione. Questa caratteristica lo rende la pratica di sicurezza più efficace che è possibile applicare al SDLC.
Microsoft ha una lunga cronologia con la modellazione delle minacce. Nel 1999, due dipendenti Microsoft, Loren Kohnfelder e Praerit Garg, scrisse un documento, The threats to our products. Questo documento ha introdotto l'approccio STRIDE, sinonimo del processo di modellazione delle minacce Microsoft.
La modellazione delle minacce è un processo evolutivo
La modellazione delle minacce non è un processo statico; si evolve man mano che cambiano le esigenze e le tecnologie.
Gli attacchi di Supply Chain come quello recente destinato a SolarWinds dimostrano la necessità di coprire più scenari di modellazione delle minacce rispetto alla soluzione stessa, tra cui sviluppo e distribuzione.
Le vulnerabilità open source come quella recente per Log4j hanno dimostrato la necessità di integrare l'approccio corrente basato sull'adozione di strumenti di analisi della composizione software per analizzare i componenti vulnerabili progettando la soluzione in modo difensivo per limitare l'esposizione.
L'applicazione di nuove tecnologie come Machine Learning introduce nuovi vettori di attacco che devono essere riconosciuti e controllati. Si consideri, ad esempio, la possibilità di riprodurre suoni creati in modo dannoso dalle orecchie umane per causare l'esecuzione di comandi da parte dei servizi di intelligenza artificiale, come illustrato in https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.
In Microsoft, i diversi gruppi di prodotti praticano diverse varianti della modellazione delle minacce in base ai requisiti di sicurezza specifici. Ogni variante mira a garantire un livello adeguato di garanzia di sicurezza agli scenari a cui viene applicata, ma a quale "adeguato" significa cambiare a seconda del contesto specifico.
Ad esempio, la protezione di Windows è diversa dalla protezione di Servizi cognitivi di Azure perché tali sistemi hanno dimensioni e caratteristiche molto diverse. Un aspetto chiave della modellazione delle minacce consiste nel bilanciare i costi rispetto alla tolleranza di rischio per un'applicazione. Anche se ciò può portare alla decisione di evitare del tutto la modellazione delle minacce per alcuni scenari, è così efficace quando si esegue correttamente che è possibile adottare solo per qualsiasi iniziativa IT, inclusi i progetti di sviluppo software e distribuzione dell'infrastruttura.
L'importanza di concentrarsi sul ROI
Gli ultimi due anni hanno visto un costante aumento dell'interesse per la modellazione delle minacce come un processo di sviluppo software chiave. Questo interesse è dovuto all'aumento esponenziale degli attacchi su infrastrutture e soluzioni. Le iniziative come lo standard minimo consigliato NIST per il fornitore o la verifica dello sviluppatore del codice e il Manifesto della modellazione delle minacce hanno aumentato ulteriormente la domanda fino al punto in cui gli approcci correnti hanno mostrato alcuni limiti. Ad esempio, i risultati della modellazione delle minacce dipendono fortemente dal processo adottato e dagli utenti che eseguono il modello di minaccia. Di conseguenza, c'è una preoccupazione per ottenere costantemente una qualità più elevata dall'esperienza.
Ma cosa significa qualità per la modellazione delle minacce? Per noi, un modello di minaccia Qualità deve avere le caratteristiche seguenti:
Deve identificare le mitigazioni eseguibili, le attività che è possibile eseguire per ridurre le potenziali perdite derivanti da attacchi. Praticabile significa che queste mitigazioni devono essere ben definite, il che significa che si ottengono informazioni sufficienti per implementarle e quindi testare l'implementazione. Ciò significa anche che devono essere forniti per consentire un consumo semplice dal team di sviluppo. Con DevOps e Agile, questo significa che esiste un percorso semplice per importare le mitigazioni nel backlog.
Per ogni mitigazione, deve identificarne lo stato. Alcune mitigazioni sono nuove, mentre altre sono già esistenti. Il modello di minaccia deve riconoscere ciò che è già presente e concentrarsi sul rischio corrente per identificare come migliorare la situazione.
Deve identificare chiaramente il motivo per cui ogni mitigazione è necessaria collegandola alle rispettive minacce.
Inoltre, le mitigazioni hanno un livello relativo per ogni minaccia. Ad esempio, la crittografia TLS può essere una mitigazione avanzata del rischio di divulgazione dei dati in transito e allo stesso tempo può essere una mitigazione quasi completa del rischio di spoofing del server.
Le minacce devono essere credibili, ben definite e specifiche per la soluzione.
Le minacce devono avere una gravità associata, che deve considerare sia la probabilità che l'impatto. La gravità deve essere ragionevole e idealmente distorta.
Dovrebbe essere possibile ottenere una visione completa dei rischi e del modo in cui possono essere affrontati. Questa visione sarebbe fondamentale per guidare una conversazione significativa con il team di sicurezza e con i decision maker aziendali, e ci permetterebbe di nascondere le complessità non necessarie.
Questo elenco mostra già un concetto importante: la modellazione delle minacce può offrire valore a molti ruoli coinvolti durante il ciclo di vita del software, ma ogni ruolo ha esigenze e requisiti diversi. Ad esempio, gli sviluppatori devono ricevere informazioni chiare su ciò che devono implementare e su come verificare che il comportamento implementato si comporti come previsto. D'altra parte, il team di sicurezza si occupa in genere della sicurezza complessiva dell'ecosistema dell'infrastruttura e delle applicazioni di proprietà dell'organizzazione; pertanto, devono ricevere informazioni che consentano di decidere se il sistema nell'ambito è abbastanza sicuro e soddisfa i requisiti di conformità. Infine, i proprietari dei prodotti e i decision maker aziendali devono comprendere cosa è necessario per rendere accettabile il rischio per l'organizzazione.
Tali esigenze diverse richiedono di fornire visualizzazioni diverse sul modello di minaccia, ognuna delle quali è incentrata su uno scenario di utilizzo specifico.
Un problema tipico con la modellazione delle minacce è che maggiore è il successo, più è difficile per i pochi esperti disponibili coprire la domanda pur fornendo la qualità elevata prevista da questa esperienza. Di conseguenza, in alcuni casi, la qualità può essere influenzata negativamente. Tutto è buono fino a quando la modellazione delle minacce smette di fornire un valore significativo rispetto all'investimento. Più di alcune organizzazioni sono interessate da questo problema. Ci sono già stati un paio di report di Decision Maker aziendali che iniziano a mettere in discussione la modellazione delle minacce perché non riuscirebbe a fornire un valore significativo per il costo.
Con valore, si fa riferimento al valore business, che è la possibilità di fornire le informazioni necessarie per comprendere i rischi rappresentati dal sistema nell'ambito e guidare un processo decisionale significativo per la selezione delle mitigazioni appropriate da implementare. Inoltre, il valore è correlato anche alla fornitura delle informazioni corrette agli sviluppatori e ai tester. Infine, il valore è correlato alla comunicazione del rischio residuo con tutte le parti coinvolte. Ad esempio, è possibile misurare il valore misurando l'impatto del processo di modellazione delle minacce. Si supponga di misurare il rischio complessivo per la soluzione assegnando un numero alla gravità identificata a ogni minaccia. In tal caso, si prevede che il rischio complessivo diminuisca nel tempo per effetto del modello di minaccia. Se il rischio complessivo rimane costante o aumenta, potrebbe verificarsi un problema. Più ripida è la diminuzione, maggiore è l'impatto del modello di minaccia. Naturalmente, il modello di minaccia non controlla le mitigazioni implementate. È responsabilità del proprietario del prodotto decidere cosa deve essere implementato. Tuttavia, il vantaggio di collegare l'efficacia del modello di minaccia con l'implementazione effettiva delle mitigazioni è che aumenta l'impatto sulla sicurezza effettiva della soluzione, riducendo il rischio che il modello di minaccia rimanga un esercizio teorico.
Al contrario, il costo è correlato alle attività necessarie per eseguire il modello di minaccia stesso, ovvero il tempo richiesto da tutte le parti coinvolte per produrre il modello di minaccia e discuterlo.
Ciò pone la domanda: è possibile definire un processo di modellazione delle minacce incentrato sull'ottimizzazione del valore aziendale e sulla riduzione al minimo dei costi?
Importanza di DevOps
Abbiamo già evidenziato quanto sia importante garantire che la modellazione delle minacce sia una pratica preziosa integrata con il processo DevOps. Ciò significa che il processo deve essere disponibile per tutti i membri del team, in genere semplificandolo e automatizzandolo. Soprattutto, concentrandosi sulla modellazione delle minacce per DevOps, è necessario assicurarsi che l'esperienza sia profondamente integrata con i processi DevOps esistenti.
La modellazione delle minacce non deve diventare ancora un altro onere, ma deve essere un asset per facilitare l'elicitazione e la raccolta dei requisiti di sicurezza, la progettazione di soluzioni sicure, l'inclusione delle attività nello strumento Task & Bug Tracking di scelta e la valutazione del rischio residuo dato lo stato attuale e futuro della soluzione.
Allineamento con DevOps
È possibile usare varie tecniche per allineare la modellazione delle minacce alla pratica devOps corrente.
Minacce e mitigazioni
In primo luogo, è necessario concentrarsi sul processo di modellazione delle minacce su ciò che deve essere fatto. Le minacce, che sono i modelli di attacco e il modo in cui possono verificarsi, sono necessarie per spiegare perché il team deve implementare un controllo di sicurezza. Sono anche un fattore per determinare quando devono essere implementate le mitigazioni. Tuttavia, l'obiettivo reale è determinare cosa deve essere fatto: le mitigazioni. Pertanto, l'approccio deve portare all'identificazione rapida delle mitigazioni necessarie e deve informare il processo decisionale in modo che sia più facile determinare cosa fare e quando. Il risultato finale principale di questo processo decisionale consiste nell'avere le mitigazioni selezionate nel backlog per renderle parte del processo standard. Idealmente, lo strumento di modellazione delle minacce e lo strumento di rilevamento dei bug e attività devono essere sincronizzati per riflettere gli aggiornamenti allo stato di mitigazione nel modello di minaccia. Ciò consentirebbe la revisione del rischio residuo in modo dinamico e automatico, che è fondamentale per supportare decisioni informate come parte delle consuete coreografie della metodologia Agile adottata, come la riunione Sprint Planning.
Cosa puoi fare oggi?
In qualità di esperto di modellazione delle minacce, è necessario assicurarsi di implementare un processo di modellazione delle minacce in grado di identificare chiaramente le azioni e includerle nell'attività e rilevamento dei bug di propria scelta. Un modo può essere adottare uno dei numerosi strumenti di modellazione delle minacce in grado di automatizzare questo processo.
Gli sviluppatori devono concentrarsi sui controlli di sicurezza identificati in base alle esigenze. Il processo deve essere progettato per fornirli allo stesso modo in cui si prevede di ricevere qualsiasi altra attività.
Funzionalità, storie utente e attività
È già stato dichiarato che le mitigazioni rappresentano l'artefatto più importante prodotto dal modello di minaccia relativo all'integrazione di DevOps. Pertanto, è importante definire chiaramente il tipo di oggetti creati da tali mitigazioni nello strumento Task & Bug Tracking di scelta. Alcune mitigazioni possono durare più di uno Sprint. Pertanto, potrebbe essere preferibile crearli come Funzionalità. Ma molti sono più semplici e possono essere implementati in un singolo sprint; sarebbe quindi possibile rappresentarli come storie utente o attività. Anche se la generazione di diversi tipi di elementi di lavoro può essere possibile, questo può comportare un processo complesso che può causare errori e confusione. Per questo motivo, sembra più pratico attenersi a un singolo tipo di elemento di lavoro. Dato che le mitigazioni possono essere considerate elementi figlio di storie utente, è possibile considerarle come Attività, il che implica la riduzione del requisito di esecuzione del tipo di elemento di lavoro specificato in un singolo sprint.
Cosa puoi fare oggi?
Assicurarsi che le mitigazioni identificate dal modello di minaccia siano rappresentate nel backlog. Identificare un modo per rappresentarli chiaramente.
Storie utente
Le mitigazioni non sono l'unico elemento di un modello di minaccia, che potrebbe e dovrebbe essere allineato a ciò che si dispone nello strumento Task & Bug Tracking. Ad esempio, potrebbe essere necessario rappresentare anche le minacce. Questo obiettivo può essere raggiunto estendendo le storie utente tramite l'aggiunta di una clausola WITHOUT al solito "Come [chi sono] voglio [cosa voglio] in modo da poter [fare qualcosa]." Ad esempio: "Come utente, voglio pagare con la mia carta di credito in modo da poter acquistare alcuni beni, SENZA aver rubato i dati della mia carta di credito". La clausola WITHOUT può essere mappata a una o più minacce e talvolta può esprimere i requisiti di sicurezza. Assicurandosi che questo allineamento tra minacce e clausole WITHOUT venga reso esplicito all'interno del modello di minaccia, è possibile garantire che i possibili rischi vengano riflessi e presi in considerazione dal team perché sono inclusi come parte delle storie utente. È anche possibile usare questa relazione per eseguire il mapping di ogni requisito di sicurezza identificato come parte delle storie utente ad almeno una minaccia.
Bello sapere
La clausola WITHOUT non è un'idea originale del team che ha prodotto questa pagina. Non siamo sicuri di chi l'ha introdotta per la prima volta, ma siamo grati a chiunque sia venuto con questa idea.
Figura 1: Allineamento dei requisiti
Ad esempio, l'immagine precedente mostra le situazioni seguenti:
La minaccia A è collegata alla storia utente 1 tramite la clausola WITHOUT 1.
La minaccia B è collegata alla storia utente 2 tramite la clausola WITHOUT 2.
La minaccia B è collegata anche alla storia utente 3. Ma la storia utente 3 non è assegnata ad alcuna clausola WITHOUT. Perché? Rappresenta un'anomalia potenziale da analizzare.
La minaccia B è collegata anche alla storia utente 1. Non è ancora chiaro se dovremmo consentire la presenza di storie utente collegate a più minacce.
La minaccia C è collegata alla storia utente 4, associata a WITHOUT 3 e 4. Non è ancora chiaro se dovremmo consentire la presenza di più clausole WITHOUT.
La minaccia D non è collegata ad alcuna storia utente. Manca una storia utente o una clausola WITHOUT?
La storia utente 5 è collegata a una clausola WITHOUT, ma non ha alcuna minaccia associata. Manca una minaccia o semplicemente un collegamento tra una storia utente e una minaccia?
Raramente si identificano i requisiti di sicurezza come parte del modello di minaccia. Pertanto, la clausola WITHOUT introduce l'opportunità di integrare ulteriormente l'esperienza estendendo i modelli di minaccia con i requisiti di sicurezza e collegandoli alle storie utente correlate. Questo approccio avrebbe un ruolo significativo nell'evoluzione dell'esperienza di modellazione delle minacce, dalla ripetizione di una valutazione nel tempo a diventare lo strumento di progettazione della sicurezza per DevOps.
Cosa puoi fare oggi?
Iniziare a usare la clausola WITHOUT all'interno delle storie utente.
Eseguire il mapping delle minacce identificate alle storie utente con clausole WITHOUT e viceversa.
Un'esperienza integrata
È possibile applicare la stessa idea ad altri scenari. Ad esempio, il modello di minaccia potrebbe collegare i requisiti di sicurezza agli artefatti all'interno del modello di minaccia stesso, ad esempio minacce e mitigazioni, e quelli nello strumento Track & Bug Tracking. Ad esempio, il requisito di implementare il monitoraggio per identificare gli attacchi in corso deve essere mappato a tutte le mitigazioni correlate al monitoraggio e quindi agli artefatti corrispondenti nello strumento Task & Bug Tracking. Di conseguenza, sarebbe facile identificare le situazioni in cui un requisito di sicurezza non è realizzato: in realtà, non sarebbe collegato a nulla.
È possibile usare gli stessi collegamenti tra gli artefatti nello strumento Task & Bug Tracking e le minacce e le mitigazioni identificate dal modello di minaccia per facilitare la definizione delle priorità delle attività di sicurezza. La sicurezza viene in genere implementata per ultima, a volte per risolvere le vulnerabilità reattive identificate da alcuni strumenti o da un test di penetrazione. Al contrario, sarebbe più efficace implementare le mitigazioni insieme alle storie utente o alle funzionalità correlate. Perché attendere di implementare i controlli per proteggere i dettagli della carta di credito quando è necessario implementarli insieme alle funzioni di pagamento correlate? Il modello di minaccia deve evidenziare tali relazioni e fornire un modo semplice per determinare quando si implementa una funzionalità durante uno sprint richiede l'implementazione di alcune funzionalità di sicurezza correlate. Queste informazioni possono essere usate, ad esempio, durante la riunione Sprint Planning per avere una discussione significativa e guidare una definizione di priorità informata. Il meccanismo è semplice. Si supponga che il proprietario del prodotto per un progetto su cui si lavora decida di pianificare una storia utente per il successivo sprint. La storia utente ha una clausola WITHOUT collegata alla minaccia. Il modello di minaccia identifica diverse mitigazioni per la stessa minaccia. Di conseguenza, è possibile dedurre immediatamente che è necessario classificare in ordine di priorità una o più delle mitigazioni identificate.
Figura 2: Assegnazione delle priorità alla sicurezza
Nell'immagine precedente, ad esempio, è possibile notare che la storia utente 1 è collegata alla minaccia 1, che a sua volta è collegata alle mitigazioni A e B. Pertanto, è consigliabile valutare anche l'implementazione di una o entrambe le mitigazioni.
Cosa puoi fare oggi?
Collegare storie utente con clausole WITHOUT agli elementi di lavoro corrispondenti alle mitigazioni selezionate usando il modello di minaccia come riferimento. Quando si pianifica lo sprint successivo, assicurarsi di classificare in ordine di priorità le attività di sicurezza collegate quando si implementa una di queste storie utente con clausole WITHOUT.
Integrazione per evidenziare gli errori di allineamento
Una volta iniziato a pensare a come collegare gli artefatti che compongono il modello di minaccia con quelli nello strumento Task & Bug Tracking, diventa più facile identificare le opportunità per migliorare la qualità di entrambi. La chiave è sfruttare le loro relazioni per evidenziare le discrepanze e sfruttare le informazioni presenti in uno per integrare, integrare e interpretare ciò che è presente nell'altro. Come illustrato in precedenza, è possibile farlo senza influire in modo significativo sul funzionamento del team. Questo perché l'approccio si basa sulle informazioni esistenti e crea relazioni tra i vari oggetti nei vari mondi. Di conseguenza, il modello di minaccia diventerà l'origine della verità per la sicurezza della soluzione. Allo stesso tempo, il backlog è allineato continuamente allo stato della soluzione.
Cosa puoi fare oggi?
Verificare regolarmente che non siano presenti minacce non mappate o storie utente con clausole WITHOUT.
Modellazione delle minacce e operazioni
Tutte queste idee sono principalmente incentrate sullo sviluppo di DevOps. È possibile eseguire operazioni anche per migliorare le operazioni? Lo pensiamo. Ad esempio, sarebbe possibile usare la modellazione delle minacce come strumento per facilitare l'analisi della causa radice perché offre una visione completa del sistema da un punto di vista della sicurezza e quindi può fornire una migliore comprensione delle implicazioni di alcuni attacchi. A tale scopo, sarebbe necessario integrare il modello di minaccia con i feed esistenti dagli strumenti di monitoraggio scelti. Questo approccio può rappresentare un complemento per il siem scelto.
Un'altra idea per l'integrazione della modellazione delle minacce con Operations consiste nell'usare la prima per guidare la progettazione di come potrebbe verificarsi quest'ultimo. Un esempio di questo è la progettazione di eventi per la soluzione. La modellazione delle minacce identifica i possibili attacchi ed è possibile usare tale conoscenza per identificare gli eventi che la soluzione nell'ambito può generare quando tali attacchi hanno esito negativo. Se si esegue una convalida di input rigorosa, un utente malintenzionato dovrà eseguire alcuni tentativi prima di riuscire. Inizialmente, i tentativi hanno esito negativo e uno di essi alla fine ha esito positivo. Generando eventi per ogni errore e attivando avvisi quando viene raggiunta una soglia, è possibile rilevare gli attacchi e intraprendere azioni per correggerle. Queste situazioni vengono rilevate raramente se ci si limita al monitoraggio dell'infrastruttura. Pertanto, è necessario includere eventi personalizzati, che il team deve progettare e implementare prima che il SOC possa sfruttarli.
Inoltre, quest'ultimo potrebbe non sapere molto sulla soluzione. Pertanto, il SOC potrebbe non essere in grado di determinare come reagire quando la convalida dell'input non riesce. Sfortunatamente, quando si verifica una violazione dei dati, è fondamentale reagire rapidamente per ridurre il danno diretto e la probabilità e l'entità delle eventuali multe.
Pertanto, dobbiamo pianificare in anticipo ciò che deve essere monitorato, in quali condizioni potremmo avere un problema e cosa fare quando ciò accade. Il modo migliore per identificare tali eventi consiste nell'basarsi su un modello di minaccia. Pertanto, sarebbe utile sfruttarlo per generare artefatti standardizzati per guidare e accelerare l'implementazione delle configurazioni necessarie per guidare monitoraggio e controllo e facilitare la risposta agli eventi imprevisti.
Cosa puoi fare oggi?
Usare attivamente il modello di minaccia per identificare gli eventi che è possibile generare per ogni minaccia. Tali eventi possono essere forniti dall'infrastruttura o da un elemento che l'applicazione deve generare. Includere gli elementi di lavoro nel backlog per assicurarsi che tali eventi vengano implementati.
Collaborare attivamente con i team addetti alle operazioni e alla sicurezza, incluso il team SOC, per assicurarsi che gli eventi vengano sfruttati per generare avvisi e identificare gli eventi imprevisti di sicurezza.
Impatto sul ROI
È possibile chiedersi perché queste tecniche possono influire positivamente sul ROI della modellazione delle minacce. Dal nostro punto di vista, sono fondamentali per aumentare il valore della modellazione delle minacce per i team DevOps. Il problema riscontrato ripetutamente è che i team percepiscono la sicurezza come un costo che fornisce valore limitato e richiede un lavoro molto imprevisto. A volte, non è chiaro perché dovrebbero investire così tanto tempo per correggere la sicurezza. Di conseguenza, la sicurezza diventa un problema invece di essere un'opportunità. La modellazione delle minacce ha il potenziale per risolvere questi problemi perché fornisce i motivi per implementare la sicurezza. Inoltre, può essere avviato all'inizio del processo di sviluppo ed evitare errori di progettazione che potrebbero costare caro se non rilevati presto. Le tecniche precedenti mirano a integrare meglio la modellazione delle minacce con DevOps. Ciò garantisce che i decision maker aziendali e gli sviluppatori percepiscano la modellazione delle minacce come complemento naturale al processo di sviluppo e operazioni. Di conseguenza, il valore ricevuto adottando la modellazione delle minacce aumenta e i relativi costi diminuiscono a causa dell'integrazione con i vari strumenti già in uso.
Semplificazione del lavoro per i modelli di minaccia
Un altro aspetto importante necessario per migliorare il ROI della modellazione delle minacce è correlato alla riduzione dei costi e all'aumento del numero di persone in grado di consegnarlo mantenendo livelli di qualità più omogenei.
Ci sono molti tentativi di affrontare la carenza di persone competenti. Alcuni di essi si basano sul coinvolgimento attivo dell'intero team DevOps nell'esercizio di modellazione delle minacce. L'idea è identificare un leader dell'iniziativa, ovvero qualcuno con conoscenze intermedie sul processo, ma non è necessariamente un esperto, e farle condurre la discussione tra gli altri membri del team. Questo approccio è attivamente approvato dai firmatari del Manifesto della modellazione delle minacce.
Siamo d'accordo che questo approccio consente di ottenere un buon valore e rappresenta un miglioramento rispetto alla situazione attuale. Fornisce anche informazioni dettagliate valide e consente al team di crescere la propria cultura di sicurezza. Tuttavia, non è senza svantaggi perché copre solo pochi problemi, lasciando fuori molto. Questo crea un problema di coerenza perché sarebbe troppo facile scendere dal buco del coniglio e sprecare tempo prezioso su questioni secondarie, mancando quelli importanti. L'esperienza del leader avrebbe un ruolo significativo nel impedire che queste situazioni si verifichino. Inoltre, questo approccio richiede molto tempo da parte di tutti i membri del team per discutere ogni problema.
Per questo motivo, anche la spesa di un paio di ore per sprint per questo esercizio può rappresentare un investimento significativo. Tutti sanno che la maggior parte dei team tende a perdere tempo sulle grandi riunioni che coinvolgono tutti e quelle sessioni di modellazione delle minacce non fanno eccezione. Tuttavia, questo approccio è eccellente per i piccoli prodotti, in cui il team comprende una manciata di membri senior.
Un approccio diverso
Date le limitazioni dell'approccio precedente, preferiamo limitare il numero di riunioni, la loro durata e il numero di partecipanti. Pertanto, la responsabilità del modello di minaccia sarebbe più significativa: non solo condurre i colloqui, ma anche creare e mantenere il modello di minaccia stesso. Questo approccio richiede competenze e competenze più significative. I modelli di minaccia possono essere rappresentati dai promotori della sicurezza o dai membri del team di sicurezza interno. La maggior parte delle organizzazioni andrebbe per la prima volta perché il team di sicurezza è in genere completamente prenotato.
I promotori della sicurezza sono membri dei team DevOps con particolare interesse per la sicurezza. Non sono esperti in alcun modo, ma hanno una conoscenza di base e la volontà di migliorare il comportamento di sicurezza del proprio team. L'idea è creare una connessione privilegiata tra i promotori della sicurezza e il team di sicurezza interno in modo che il primo sia autorizzato a aiutare i team a fare la cosa giusta, mentre il team di sicurezza può ridurre il carico di lavoro. Con la modellazione delle minacce, i promotori della sicurezza fungerebbero da modellatori di minacce e il team interno della sicurezza avrebbe la responsabilità di guidarli ed esaminarne il lavoro.
Cosa puoi fare oggi?
Esaminare la possibilità di adottare un programma Security Champions e di sfruttarlo per rafforzare ulteriormente il ciclo di vita di sviluppo software sicuro.
Ruolo delle knowledge base
Un problema significativo con la modellazione delle minacce è garantire che la qualità dell'esperienza e il valore per il team DevOps sia elevato indipendentemente da chi esegue il modello di minaccia. Con i promotori della sicurezza, questo problema diventa ancora più urgente. Un'idea per risolvere questo problema consiste nel fornire knowledge base per guidare la creazione del modello di minaccia. Le Knowledge Base per la modellazione delle minacce sono pacchetti di informazioni su un contesto specifico: contengono una definizione delle entità correlate a tale contesto, i possibili modelli di attacco su tali entità e le mitigazioni standard che possono essere applicate. Le knowledge base consentono all'organizzazione di ottenere risultati migliori e più coerenti perché rappresentano materiale di riferimento che guida i modelli di minaccia in modo prescrittivo. Le Knowledge Base devono avere regole che consentono di applicare automaticamente minacce e mitigazioni a un sistema. Questa automazione ci permetterebbe di superare il fatto che alcuni modelli di minaccia potrebbero non avere l'esperienza necessaria per determinare se deve essere applicata una minaccia o se una mitigazione è efficace.
Le knowledge base non sono una nuova idea: molti attuali strumenti di modellazione delle minacce li supportano già in qualche modo. Ma molte implementazioni correnti hanno svantaggi significativi. Ad esempio, dovrebbe essere possibile gestire facilmente le knowledge base. La loro manutenibilità è un problema che non è ancora risolto. Ad esempio, non è facile identificare le migliori fonti di informazioni da usare per compilarle. Inoltre, la manutenzione è in genere manuale. La creazione e la manutenzione delle knowledge base devono essere responsabilità del team di sicurezza interno dell'organizzazione. Speriamo che le aziende inizieranno a fornire knowledge base per gli strumenti di modellazione delle minacce più comuni per sollevare alcuni dei carichi di lavoro dei clienti in futuro. Queste knowledge base devono essere flessibili per supportare e facilitare l'adozione anche da parte delle organizzazioni più mature, che devono adattare le knowledge base a tali pratiche, criteri e normative.
Cosa puoi fare oggi?
Considerare la possibilità di dedicare parte dello sforzo del team di sicurezza centralizzato per lo sviluppo di knowledge base che possono essere usate dai vari team di sviluppo per accelerare la modellazione delle minacce.
Utilizzo di knowledge base
Un altro problema con le knowledge base è che a volte sono troppo complesse da utilizzare. Molti di loro cercano di essere completi includendo problemi essenziali e meno critici. Purtroppo, non tutti sono richiesti da tutti i sistemi. È consigliabile adottare un approccio più semplice quando il sistema che si sta analizzando è di piccole dimensioni e non gestisce i dati sensibili. Al contrario, è consigliabile approfondire se il sistema è complesso e elabora i dati personali e di alto valore aziendale. Pertanto, dovrebbe essere possibile applicare versioni diverse della conoscenza a seconda del contesto o contrassegnare alcuni modelli di attacco e le mitigazioni associate come "TOP". Di conseguenza, i modelli di minaccia sarebbero in grado di decidere se vogliono un'esperienza completa o andare facilmente e ridurre al minimo il lavoro richiesto.
Parlando di efficienza, è fondamentale garantire che le attività siano semplificate e automatizzate il più possibile per ridurre la quantità di lavoro necessaria. Si ritiene che un punto di riferimento ideale per eseguire un modello di minaccia di una soluzione di dimensioni medie deve essere 1 giorno di lavoro per il modello di minaccia. Tali risultati sono possibili solo se lo strumento di scelta fornisce acceleratori per consentire di ridurre il tempo necessario. Ad esempio, se lo strumento applica 20 diversi tipi di mitigazioni in 100 posizioni diverse e si è richiesto di specificare per ognuno di essi il relativo stato, si sarebbe 5 volte più efficiente concentrandosi sul primo anziché sul secondo. Lo strumento scelto deve fornire questa funzionalità, pur concedendo la possibilità di eseguire un lavoro più accurato quando necessario.
Cosa puoi fare oggi?
Se le knowledge base usate oggi non supportano il concetto di minacce e mitigazioni "TOP", prendere in considerazione la possibilità di rimuovere ciò che raramente è necessario o utile, per consentire di concentrarsi solo su ciò che realmente conta.
A volte il problema è che le knowledge base adottate tentano di essere generiche e coprono più scenari. È possibile migliorare la situazione specializzandoli.
Porre le domande giuste
Durante l'analisi, è stata presa in considerazione la possibilità di usare uno strumento per supportare un framework domande per guidare le prime fasi dell'analisi. Abbiamo notato che la maggior parte dei modelli di minacce inesperti non può porre le domande giuste per ottenere le informazioni necessarie per la loro analisi. Alcuni dei nostri esperti hanno dimostrato che è possibile determinare alcune domande cruciali in base a un diagramma di sistema nell'ambito. Queste domande possono anche essere applicate automaticamente, con alcune regole di generazione. Il problema è che questo approccio potrebbe non fornire il valore che sembra promettere. Ciò sarebbe dovuto al fatto che è necessario comprendere la logica alla base di ogni domanda. In caso contrario, non sarebbe possibile valutare la risposta e determinare se è soddisfacente. Tuttavia, la generazione di domande automatizzate può offrire un valore significativo ai modelli di minaccia meno esperti, migliorando la comprensione dei sistemi nell'ambito.
Cosa puoi fare oggi?
Adottare un approccio strutturato per porre domande. Ad esempio, il team ha avuto buoni risultati adottando Microsoft STRIDE come riferimento. A tale scopo, è possibile porre ogni componente delle domande sulla soluzione, ad esempio:
Spoofing: in che modo il componente esegue l'autenticazione per i servizi e le risorse usati?
Manomissione: il componente convalida i messaggi ricevuti? La convalida è debole o rigorosa?
Ripudio: il componente registra le interazioni in un log di controllo?
Divulgazione di informazioni: il traffico in ingresso e in uscita il componente è crittografato? Quali protocolli e algoritmi sono consentiti?
Denial of Service: il componente è configurato in disponibilità elevata? È protetto dagli attacchi DDoS?
Elevazione dei privilegi: agli utenti vengono assegnati i privilegi minimi necessari? La soluzione combina il codice destinato agli utenti normali con quello per gli utenti con privilegi elevati?
Tecniche come questa possono essere insegnate e possono essere migliorate con esperienza. È quindi importante implementare un approccio di Apprendimento continuo progettato per raccogliere le informazioni e distribuirle all'interno dell'organizzazione.
Impatto sul ROI
In fondo, è possibile identificare molte idee per migliorare l'efficienza dell'esperienza di modellazione delle minacce, la sua qualità e infine aumentare il ROI. Questo sforzo dovrebbe tuttavia essere considerato un processo in corso, che dovrebbe essere indirizzato al miglioramento continuo della pratica.
Conclusioni
La modellazione delle minacce è una metodologia eccellente per migliorare la sicurezza dell'organizzazione. Se eseguita correttamente, può fornire valore per un costo molto ragionevole. Sono già state identificate varie tecniche che possono rivelarsi essenziali per migliorare il valore della modellazione delle minacce per la protezione di soluzioni moderne, tra cui:
Allineare il modello di minaccia con la procedura devOps
Concentrarsi sulle mitigazioni
Collegare le mitigazioni con le storie utente
Evidenziare le discrepanze tra il modello di minaccia e il backlog
Usare il modello di minaccia per promuovere un monitoraggio e un controllo più completi per la sicurezza
Semplificare la creazione di modelli di minaccia e aumentare la coerenza dei risultati
Affidarsi ai promotori della sicurezza
Adottare knowledge base per automatizzare l'identificazione delle minacce e delle mitigazioni
Creazione di knowledge base migliori
Fornire un framework di domande supportato dall'automazione
Speriamo che alcuni di essi siano già disponibili nello strumento di modellazione delle minacce preferito. Altri saranno inclusi in futuro. Sappiamo che massimizzare il ROI per la modellazione delle minacce è un impegno a lungo termine che richiede risposte che non abbiamo ancora. Sappiamo anche che alcune domande sono ancora sconosciute. Questo documento dovrebbe fornire un po ' di cibo per pensare e speriamo che possa aiutare a migliorare il modo in cui si esegue la modellazione delle minacce. Speriamo che possa essere un faro per voi e noi, e che sarà utile indirizzare i nostri sforzi per gli anni a venire.