Threat modeling: trasformare l’architettura in decisioni di sicurezza

Il threat modeling si chiede che cosa potrebbe andare storto in un determinato sistema e che cosa dovrebbe fare il team al riguardo. Il suo risultato utile non è un catalogo di possibilità spaventose. È un insieme di decisioni di progettazione e implementazione legate all’architettura, con responsabili ed evidenze che le difese scelte funzionano.

Per un CTO, la domanda centrale è se l’engineering sia in grado di spiegare come le proprietà di sicurezza importanti resistono al comportamento reale del sistema: tentativi ripetuti, job in background, azioni privilegiate del supporto, interruzioni dei fornitori e input malevoli. Un diagramma rende concrete queste conversazioni. Un threat model mantenuto aggiornato trasforma le conclusioni in lavoro di realizzazione.

Le linee guida di OWASP sul threat modeling offrono una base utile: comprendere il sistema, individuare le minacce, decidere come rispondere e valutare se il lavoro è sufficiente. Il flusso di lavoro che segue applica questo ragionamento alle decisioni di engineering.

Descrivete il sistema prima di discutere degli attacchi

Partite da una funzionalità circoscritta, come le esportazioni per i clienti, l’avvio dei pagamenti o gli aggiornamenti dei dispositivi. Modellare un’intera piattaforma in una volta produce spesso osservazioni superficiali, perché nessuno è in grado di spiegare ogni dipendenza con un livello di dettaglio sufficiente.

Esprimete gli asset e gli obiettivi di sicurezza in termini operativi. «Proteggere i dati dei clienti» è troppo generico. «Un utente autenticato può esportare solo i dati appartenenti al tenant per cui è autorizzato» fornisce al team una proprietà da testare. Altri obiettivi possono riguardare l’integrità delle transazioni, la disponibilità del servizio, il ripristino o l’attribuzione delle azioni amministrative.

Individuate utenti, servizi, archivi di dati, dipendenze esterne, punti di ingresso e confini di fiducia. Disegnate i flussi di dati importanti, compresi l’elaborazione asincrona e i percorsi amministrativi. Etichettate i flussi con i dati trasportati, il meccanismo di autenticazione e il contesto di autorizzazione, laddove questi incidano sull’analisi.

Un confine di fiducia segna un cambiamento di assunzioni o di autorità, non necessariamente un perimetro di rete. Un browser che chiama un’API attraversa un confine. Un worker condiviso che agisce per conto di un cliente ne attraversa un altro, anche se entrambi i servizi girano nello stesso cluster.

Per un’applicazione multi-tenant, mostrate dove viene stabilita l’identità del tenant e come raggiunge i controlli di autorizzazione, i job in background e le esportazioni. Includete le identità dei servizi, l’accesso all’object storage, gli strumenti di supporto e le callback esterne. Altrimenti il diagramma rischia di descrivere il percorso ideale tralasciando i percorsi che con maggiore probabilità aggirano l’isolamento.

Registrate le assunzioni separatamente dai fatti. «La coda non può essere scritta dai clienti» richiede evidenze di configurazione a supporto. Le incognite dovrebbero diventare attività di indagine, non difese accettate in silenzio.

Scegliete un metodo che aiuti il team a ragionare

Un metodo fornisce spunti e struttura. Non determina quali minacce contino di più, non dimostra che un progetto sia sicuro e non sostituisce la conoscenza del sistema.

STRIDE per spunti sistematici

STRIDE esamina sei categorie. Applicatele ai componenti, ai flussi e ai confini pertinenti, anziché forzare ogni categoria su ogni elemento del diagramma.

Uno scenario può coprire più categorie. Quando opportuno, mantenete un’unica registrazione azionabile anziché creare ticket duplicati per soddisfare la tassonomia.

Altri metodi per domande diverse

PASTA, il Process for Attack Simulation and Threat Analysis, propone un approccio in sette fasi orientato al rischio che collega obiettivi aziendali, perimetro tecnico, scomposizione, analisi di minacce e vulnerabilità, modellazione degli attacchi e trattamento dei rischi. È adatto ad analisi più approfondite, in cui il comportamento degli attaccanti e le conseguenze per l’azienda richiedono un’attenzione esplicita.

Gli attack tree partono da un obiettivo dell’attaccante e lo scompongono in percorsi alternativi o combinati. Per «ottenere l’esportazione di un altro tenant», le alternative potrebbero includere l’aggiramento dell’autorizzazione dell’API, la confusione del contesto tenant del worker o il furto di una credenziale di download. Le relazioni AND rappresentano condizioni che devono verificarsi insieme; le relazioni OR rappresentano alternative.

VAST, Visual, Agile, and Simple Threat modeling, pone l’accento su una modellazione scalabile che copre prospettive applicative e operative. I team che lo prendono in considerazione dovrebbero verificare se i propri strumenti e il proprio processo di sviluppo siano in grado di mantenere queste viste in modo coerente.

Come punto di partenza pratico si consiglia un diagramma dei flussi di dati abbinato a STRIDE, seguito da un attack tree per lo scenario più rilevante. Una metodologia più articolata è utile solo se migliora le decisioni.

Conducete la revisione attorno a scenari concreti

Coinvolgete le persone che conoscono implementazione e gestione operativa: uno sviluppatore, un architetto o technical lead, un revisore di sicurezza e qualcuno che conosce il comportamento in produzione. Includete specialisti di prodotto, privacy o fornitori quando le loro conoscenze incidono sul perimetro.

Prima della sessione, fate circolare il diagramma, gli obiettivi di sicurezza, la configurazione pertinente e le assunzioni non ancora risolte. Durante la revisione, seguite una richiesta o un evento dall’ingresso al completamento. Chiedetevi dove cambia l’identità, dove i dati vengono resi persistenti, che cosa viene ritentato e quale componente ha l’autorità per approvare un’azione.

Scrivete le minacce come scenari, non come etichette. «Problema di autorizzazione» non è abbastanza utile. Una formulazione più efficace è: «Un utente autenticato sostituisce l’identificativo di esportazione di un altro tenant; l’endpoint di download verifica il login ma non la titolarità dell’oggetto, esponendo dati dei clienti».

Distinguete tre concetti:

• Una minaccia descrive un’azione o un evento avverso, come il recupero non autorizzato di un’esportazione.
• Una vulnerabilità è una debolezza che potrebbe renderlo possibile, come un controllo di titolarità mancante.
• Il rischio considera la probabilità e le conseguenze dello scenario nell’ambiente reale.

Una minaccia può meritare un’indagine prima che una vulnerabilità sia confermata. Allo stesso modo, individuare una debolezza non dimostra che ogni attacco immaginabile sia realizzabile.

Includete l’uso improprio da parte di utenti legittimi, gli insider privilegiati, gli errori di configurazione e i malfunzionamenti dei fornitori accanto agli attacchi esterni. Chiedetevi che cosa accade quando una dipendenza va in timeout o restituisce una risposta inattesa. Comportamenti fail-open e tentativi ripetuti incoerenti emergono spesso da queste discussioni.

Esempio pratico: una pipeline di esportazione multi-tenant

L’esempio seguente è illustrativo. Supponiamo che un’applicazione SaaS disponga di un client browser, un’API, un database condiviso, una coda di job, un worker di esportazione e un object storage. Gli utenti dei tenant richiedono esportazioni CSV; il worker genera i file e l’API emette link di download temporanei. Gli amministratori del supporto dispongono di un’interfaccia separata per la risoluzione dei problemi.

Gli obiettivi di sicurezza sono isolamento dei tenant, avvio autorizzato delle esportazioni, consumo di risorse limitato e azioni del supporto attribuibili. Supponiamo che il worker abbia un accesso al database abbastanza ampio da servire più tenant. Ciò rende la sua gestione del contesto tenant una decisione centrale, non un dettaglio implementativo secondario.

Seguite l’autorità lungo il flusso

A livello di API, il principal autenticato è associato all’appartenenza ai tenant consentiti. Un identificativo di tenant fornito dal browser è una richiesta di selezione, non una prova di autorizzazione. L’API verifica l’appartenenza e il permesso di esportazione prima di creare una registrazione del job immutabile che contiene il tenant autorizzato, il richiedente e il perimetro di esportazione consentito.

Il messaggio in coda fa riferimento a tale registrazione. Il worker valida il job e applica un accesso ai dati limitato al tenant quando produce l’esportazione. I metadati dello storage associano l’oggetto risultante al job e al tenant. Prima di emettere un link di download, l’API verifica l’autorizzazione del richiedente attuale rispetto a tale associazione.

Questo progetto richiede comunque decisioni esplicite sulla revoca degli accessi: un utente che perde l’appartenenza dopo aver richiesto un’esportazione deve mantenere l’accesso al file completato? Il team deve definire questa politica e implementarla in modo coerente.

Convertite gli scenari in controlli e test

I link temporanei introducono una finestra di esposizione residua: a seconda del meccanismo, il possesso del link può consentire l’accesso fino alla scadenza. Il team dovrebbe decidere se ciò sia accettabile per i dati in questione o se i download richiedano un intermediario autenticato con verifiche dell’autorizzazione aggiornate.

Non chiudete il modello dopo aver testato solo l’API sincrona. Verificate job ritardati, tentativi ripetuti, richieste annullate, appartenenze scadute, tenant eliminati e malfunzionamenti parziali. Per esempio, un job ritentato non deve riutilizzare un oggetto associato a un altro tenant né pubblicare come riuscita un’esportazione incompleta.

Il deliverable risultante è un’architettura riesaminata, un registro delle minacce, attività di implementazione e risultati di verifica collegati. Non è soltanto il diagramma.

Stabilite le priorità in base a esposizione e conseguenze

Date priorità agli scenari plausibili in base a esposizione, impatto, precondizioni e difese esistenti. Distinguete un errore di autorizzazione direttamente raggiungibile da uno scenario che richiede diverse compromissioni non dimostrate. Considerate, laddove pertinenti, i dati coinvolti, l’interruzione del servizio, le conseguenze finanziarie, le implicazioni per la sicurezza delle persone e la difficoltà di ripristino.

Usate una scala semplice e coerente se aiuta il team, ma registrate la motivazione alla base del punteggio. Un punteggio numerico con input non spiegati crea una falsa precisione. Il CVSS può supportare la valutazione di una vulnerabilità concreta; non sostituisce la comprensione dell’impatto sull’azienda né un caso di abuso architetturale.

Le scelte di trattamento comprendono la modifica del progetto, la riduzione dell’esposizione, l’aggiunta di controlli preventivi o di rilevamento, la rinuncia alla funzionalità o l’accettazione del rischio residuo. I contratti con i fornitori possono ripartire le responsabilità, ma non eliminano le modalità di guasto tecniche.

Il rischio residuo dovrebbe avere un decisore designato, una motivazione, una scadenza o un evento di riesame ed eventuali condizioni operative. Il completamento del lavoro di engineering e l’accettazione del rischio sono decisioni diverse. Un ticket può essere chiuso mentre resta un rischio significativo.

Portate il modello nella realizzazione e nelle evidenze

Per ogni scenario rilevante, registrate identificativo, componenti interessati, precondizioni, conseguenze, difese esistenti, trattamento, responsabile e metodo di verifica. Collegate la registrazione alla versione dell’architettura e alle attività di implementazione pertinenti, in modo che i revisori possano capire quale progetto è stato valutato.

Traducete i trattamenti in criteri di accettazione verificabili. «Migliorare il controllo degli accessi» è vago. «Il tenant A non può richiedere, interrogare, annullare o scaricare l’esportazione del tenant B attraverso alcun endpoint supportato» identifica un comportamento che l’engineering può verificare.

Usate evidenze adeguate all’affermazione:

• La code review può stabilire dove viene applicata l’autorizzazione.
• L’ispezione della configurazione può stabilire i permessi dei servizi e l’esposizione dello storage.
• I test di integrazione negativi possono mettere alla prova i confini tra tenant e tra livelli di privilegio.
• I test di carico e di fault injection possono esaminare la disponibilità e il comportamento in caso di guasto.
• Penetration test mirati possono indagare percorsi d’attacco che richiedono un’esplorazione indipendente.

Nessun singolo artefatto dimostra l’intero modello. Lo screenshot di un’impostazione non dimostra che ogni worker la utilizzi e un test superato non dimostra nulla su un percorso non testato. Registrate ambiente di test, perimetro, risultati e limiti.

Il threat modeling integra la programmazione sicura, la valutazione delle dipendenze, la scansione delle vulnerabilità e il penetration testing. Il suo contributo distintivo è il ragionamento architetturale: può rivelare un’allocazione pericolosa dell’autorità anche quando i singoli componenti non presentano vulnerabilità note.

Mantenete strumenti e automazione al servizio del modello

Un diagramma condiviso e un registro strutturato possono supportare una prima revisione mirata. Gli strumenti dedicati diventano utili quando i team hanno bisogno di librerie di componenti riutilizzabili, identificativi coerenti, collaborazione e collegamenti affidabili tra minacce e registrazioni di realizzazione.

Valutate se uno strumento supporta confini di fiducia, scenari personalizzati, cronologia delle versioni, registrazioni esportabili, titolarità e riferimenti alle evidenze. Le minacce generate automaticamente sono spunti da esaminare, non rilievi confermati. Lunghi elenchi privi di contesto possono nascondere le poche decisioni che contano.

L’assistenza dell’IA può abbozzare descrizioni di scenari, suggerire percorsi mancanti o confrontare le modifiche con un modello precedente. I revisori umani devono comunque validare architettura, fattibilità, copertura delle mitigazioni e rischio residuo. Tenete diagrammi riservati e credenziali fuori dai servizi non approvati. La generazione di threat model è inoltre distinta dal rilevamento a runtime; produrre un modello non equivale a disporre di monitoraggio continuo o di rimedi automatizzati.

Riesaminate il modello quando cambiano l’architettura o le assunzioni

Aggiornate il modello in caso di nuove integrazioni, modifiche all’autenticazione, azioni privilegiate, categorie di dati, esposizione di rete e cambiamenti importanti delle dipendenze. Anche un incidente o un risultato di test inatteso possono invalidare un’assunzione precedente.

Sistemi diversi richiedono un’enfasi diversa. Le applicazioni cloud richiedono attenzione ai permessi delle identità e all’accesso al management plane. I client mobili dovrebbero essere trattati come ambienti controllati dall’attaccante, non come punti di applicazione affidabili. I dispositivi connessi introducono accesso fisico, integrità degli aggiornamenti, ripristino e potenziali conseguenze per la sicurezza delle persone. Le funzionalità basate sull’IA aggiungono contenuti non attendibili e confini nell’uso degli strumenti; l’autorizzazione deve limitare le azioni indipendentemente dall’output del modello.

Misurate se i flussi importanti dispongono di modelli aggiornati, se i trattamenti ad alta priorità hanno evidenze di verifica, se restano assunzioni irrisolte e se i rischi accettati hanno riesami scaduti. Contare solo le minacce premia il volume anziché un’analisi utile. Chiedete periodicamente a un revisore indipendente di mettere in discussione uno scenario critico e le relative evidenze.

Rendete la prima revisione abbastanza piccola da poterla concludere

Secani può preservare il flusso di lavoro attorno a queste decisioni modellando i sistemi e le dipendenze pertinenti, assegnando responsabili e revisori e collegando le evidenze a requisiti, controlli e decisioni. Le assunzioni irrisolte diventano attività; il materiale di origine e le approvazioni umane restano collegati alla revisione. Gli eventuali suggerimenti assistiti dall’IA dovrebbero essere verificati prima dell’approvazione.

Iniziate con un flusso di dati critico. Seguitene l’autorità da un capo all’altro, individuate una manciata di scenari plausibili e concludete con trattamenti assegnati a un responsabile e criteri di verifica espliciti. Pianificate la revisione successiva in funzione dei cambiamenti architetturali che potrebbero invalidare tali decisioni.