Cyber threat intelligence: cosa state comprando davvero

C’è un paradosso nel modo in cui le aziende comprano threat intelligence. Spendono per sapere tutto degli attaccanti — chi sono, come lavorano, quali strumenti usano — e alla fine dell’anno non sanno rispondere alla sola domanda che il consiglio di amministrazione pone davvero: noi siamo esposti oppure no.

Non è un difetto di esecuzione. È strutturale, e conviene capirlo prima di firmare un contratto.

La threat intelligence è una delle poche discipline della sicurezza informatica che non nasce nell’informatica. Ciclo produttivo, valutazione delle fonti, tecniche analitiche, linguaggio della probabilità: viene tutto dall’intelligence militare e governativa, adattato al dominio cyber in pochi anni fra il 2011 e il 2015. Da lì arriva anche il suo equivoco fondativo. In quella tradizione, un elenco di indirizzi IP non è intelligence. È materia prima. Buona parte di ciò che oggi si vende sotto quel nome si ferma esattamente lì.

Quello che segue è l’impianto tecnico della disciplina: come si produce l’intelligence, con quali modelli si analizzano le intrusioni, come si valutano le fonti, come si tiene sotto controllo il ragionamento di chi analizza. E dove si ferma.

1. Dato, informazione, intelligence: dove passa il confine
2. Il ciclo produttivo e le domande giuste
3. Tre livelli, tre prodotti, tre destinatari
4. I quattro modelli su cui si regge l’analisi
5. Quanto vale una fonte: il codice Admiralty
6. Il nemico interno: i bias dell’analista
7. Standard e protocolli di condivisione
8. Dove la threat intelligence si ferma
9. Dal modello alla prova: il threat-led testing
10. Attribuzione: il problema più difficile e il meno utile

Dato, informazione, intelligence: dove passa il confine

Partiamo da una distinzione che sembra pedante e non lo è per niente.

Un hash è un dato. Sapere che quell’hash appartiene a un file distribuito in una campagna di gennaio è informazione. Sapere che quella campagna colpiva aziende manifatturiere delle vostre dimensioni, e che il vostro perimetro quel file non lo intercetta, è intelligence. Tre stadi, costo crescente ad ogni passaggio. Quasi tutto il mercato si ferma al primo e vi lascia il resto.

Questo spiega perché tanti programmi di threat intelligence, dopo dodici mesi, producano solo rumore. Il fornitore consegna volumi enormi di indicatori, il vostro team non ha il tempo di stabilire quali riguardino davvero la vostra infrastruttura, e gli allarmi finiscono ignorati per stanchezza. La causa non è la quantità di dati. È che nessuno ha definito a monte quali domande l’intelligence dovesse servire.

Una seconda distinzione conta più di quanto sembri. Gli indicatori di compromissione guardano indietro: sono tracce di un’intrusione già avvenuta. Gli indicatori di attacco descrivono un comportamento in corso, e guardano avanti. La differenza pesa perché un attaccante cambia un hash in un secondo, mentre cambiare il proprio modo di lavorare gli costa mesi.

Il ciclo produttivo e le domande giuste

Il modello procedurale è il ciclo di intelligence: direzione, raccolta, elaborazione, analisi, disseminazione, feedback. Sei fasi. La parola importante è “ciclo”: il feedback non chiude il processo, riscrive i requisiti della fase iniziale. Chi lo tratta come una catena di montaggio lineare produce report che nessuno legge.

Tutto l’impianto regge sulla prima fase, e la prima fase regge su una cosa sola: i requisiti informativi. Formularli bene è meno ovvio di quanto sembri. “Quali sono le minacce al nostro settore” non è un requisito, è una conversazione da corridoio. “Quali tecniche di accesso iniziale sono state osservate negli ultimi novanta giorni contro organizzazioni che espongono il nostro stesso stack applicativo” lo è, perché ha un perimetro, una scadenza e qualcuno che deve deciderci qualcosa.

Esiste anche una variante operativa del ciclo, nota con la sigla F3EAD e presa in prestito dalla dottrina delle operazioni speciali. Il suo pregio è pratico: quello che si raccoglie mentre si contiene un incidente rientra subito nel ciclo analitico, invece di finire in un archivio che nessuno riaprirà. È il modo di lavorare delle squadre di difesa descritte nell’articolo sul blue team.

Tre livelli, tre prodotti, tre destinatari

La divisione in strategico, operativo e tattico non riguarda la difficoltà tecnica. Riguarda chi deve decidere e con quale orizzonte. Confondere i livelli è la causa numero uno delle trattative finite male: l’azienda credeva di comprare analisi, il fornitore vendeva un abbonamento a un flusso di dati, e nessuno dei due mentiva.

Il livello operativo è il più interessante e il meno offerto. Serve gente capace di ricostruire una catena d’attacco completa partendo da frammenti, e quella gente costa. In compenso è l’unico livello che si traduce direttamente in qualcosa di verificabile: le TTP documentate diventano gli scenari che un purple team assessment riproduce in ambiente controllato, per vedere se i vostri controlli se ne accorgono.

I quattro modelli su cui si regge l’analisi

Quattro modelli, tutti pubblicati fra il 2011 e il 2013, costituiscono ancora oggi il vocabolario condiviso della disciplina. Nessuno ha rimpiazzato gli altri perché guardano lo stesso fenomeno da angoli diversi, e nella pratica si usano insieme.

La Cyber Kill Chain

Nasce nel 2011 da tre ricercatori di Lockheed Martin. Scompone l’intrusione in sette fasi: ricognizione, weaponization, delivery, exploitation, installazione, comando e controllo, azioni sull’obiettivo. Il contributo vero non è l’elenco. È l’asimmetria che ne deriva, ed è la frase più citata della sicurezza difensiva: l’attaccante deve riuscire in tutte le fasi, a voi ne basta spezzare una.

Ha i suoi limiti, ed è giusto dirlo: sulle minacce interne e sui movimenti laterali dopo il primo accesso la linearità del modello si sfalda. Resta utile per la fase iniziale, la ricognizione, che si nutre quasi solo di open source intelligence. È anche l’unica fase su cui potete intervenire direttamente, riducendo quello che di voi è pubblicamente visibile.

Il Diamond Model

Caltagirone, Pendergast e Betz, 2013. Ogni evento di intrusione viene descritto come la relazione fra quattro vertici: avversario, capacità, infrastruttura, vittima. Fin qui sembra uno schema da lavagna.

Il valore sta negli assi che collegano i vertici, e in quello che ci si fa sopra: il pivoting. Da un server di comando e controllo si risale agli strumenti osservati, dagli strumenti ad altri episodi che condividono le stesse capacità, da lì a un profilo di avversario. Un’osservazione isolata diventa un’ipotesi investigativa da verificare, e catene di eventi correlati compongono quella che si chiama campagna. È l’impalcatura con cui si ricostruiscono gli incidenti reali.

MITRE ATT&CK

Qui cambia la natura dell’oggetto: ATT&CK non è un modello concettuale ma un catalogo, costruito osservando intrusioni realmente accadute. Le tecniche sono organizzate per tattica — cioè per obiettivo intermedio dell’attaccante, dall’accesso iniziale all’impatto — e ciascuna ha un codice stabile.

Sembra burocrazia. È invece la cosa più utile del lotto, perché crea un linguaggio comune: se un rapporto cita un codice tecnica, chiunque sa esattamente di cosa si parla, può controllare se i propri controlli la intercettano e può misurare la copertura difensiva in modo confrontabile. Su questa mappatura si regge la differenza fra un test generico e uno guidato dalle minacce, che si sovrappone in parte alla distinzione fra penetration testing e red teaming.

La Pyramid of Pain

David Bianco, 2013. Ordina gli indicatori secondo quanto costa all’attaccante aggirarli.

La lettura è brutale ma onesta. Se il vostro programma di difesa vive sui primi due livelli, state comprando protezione che l’avversario annulla in pochi minuti senza spendere nulla. Salire verso il rilevamento comportamentale costa molto di più da implementare, però quello che costruite lassù non scade la settimana dopo.

Più si sale nella piramide, più costa all’attaccante aggirare il controllo: un hash si cambia modificando un byte, un modo di lavorare richiede di riaddestrare gli operatori.

Quanto vale una fonte: il codice Admiralty

Un prodotto di intelligence serio non presenta mai i propri giudizi come fatti nudi. La dottrina NATO usa da decenni una doppia valutazione — il cosiddetto codice Admiralty — che misura separatamente due cose: quanto è affidabile chi parla e quanto è credibile ciò che dice.

Tenere separati i due assi non è una finezza da manuale. Una fonte storicamente ottima può riportare, quel giorno, qualcosa che nessuno ha potuto verificare. E una fonte pessima può inciampare in un dato poi confermato per altre vie. Una sigla come B2 comunica al lettore il peso esatto di quello che sta leggendo, cosa che un rapporto senza valutazione non fa in nessun modo.

Usatelo come criterio di selezione dei fornitori. Chi consegna affermazioni senza dichiarare provenienza e grado di confidenza vi sta chiedendo fiducia cieca. Il punto diventa spinoso con le fonti chiuse — forum criminali, canali riservati, mercati di credenziali — perché in quegli ambienti circola anche disinformazione messa lì apposta dagli stessi soggetti che si vorrebbero osservare.

Il nemico interno: i bias dell’analista

L’eredità più utile della tradizione dell’intelligence non riguarda la raccolta. Riguarda il controllo di chi ragiona. Il testo di riferimento resta lo studio di Richards Heuer sulla psicologia dell’analisi, che documenta una cosa scomoda: i fallimenti analitici nascono più spesso da errori cognitivi che da mancanza di dati.

Tre bias si presentano con regolarità imbarazzante. Il primo è la conferma: una volta formulata un’ipotesi, ogni nuova evidenza sembra sostenerla. Il secondo è l’ancoraggio, e nel nostro campo ha una forma riconoscibile — il primo gruppo di attaccanti che viene in mente diventa la spiegazione, semplicemente perché è quello di cui si è letto di più. Il terzo è la disponibilità: le minacce sui giornali questa settimana vengono sovrastimate rispetto a quelle statisticamente probabili.

La contromisura si chiama analisi delle ipotesi concorrenti e funziona al contrario dell’istinto. Si elencano tutte le spiegazioni plausibili, si costruisce una matrice fra evidenze e ipotesi, e poi si cerca cosa smentisce ciascuna ipotesi anziché cosa la conferma. Vince quella che sopravvive a più tentativi di demolizione, non quella con più prove a favore. Il rovesciamento è tutto il metodo.

C’è poi la questione delle parole. Sherman Kent si occupò del problema quando si accorse che espressioni come “probabile” o “è possibile” venivano lette da persone diverse con scarti enormi. La regola che ne derivò è semplice: a ogni formula si associa un intervallo numerico dichiarato, così che l’incertezza venga trasmessa e non indovinata.

L’indagine di Kent nacque da un caso concreto. Una stima nazionale statunitense degli anni Cinquanta definiva un certo evento una “seria possibilità”. Interrogati separatamente, i membri del gruppo che l’aveva scritta attribuirono a quella formula probabilità comprese fra il venti e l’ottanta per cento. L’avevano firmata tutti.

Standard e protocolli di condivisione

Perché l’intelligence circoli fra organizzazioni serve un formato comune. Quello di riferimento è STIX, che rappresenta indicatori, attori, campagne, malware e le relazioni fra loro come un grafo tipizzato; il protocollo di trasporto associato, TAXII, definisce come produttori e consumatori si scambiano il materiale.

Le piattaforme di gestione fanno il resto: raccolgono eventi, correlano attributi, generano regole di rilevamento, distribuiscono a comunità settoriali. Vale però la pena essere chiari su un punto. La qualità di questi ambienti dipende pochissimo dal software e moltissimo da quanta disciplina ha chi ci mette dentro i dati: un archivio popolato a caso produce correlazioni false in quantità industriale.

Serve infine un protocollo di riservatezza, e qui si usa il Traffic Light Protocol nella versione mantenuta da FIRST: quattro etichette, dalla più restrittiva — che vieta al destinatario ogni ridistribuzione — fino a quella che consente diffusione pubblica, con un livello intermedio dotato di variante ristretta alla sola organizzazione ricevente. Non è etichettatura formale: stabilisce di chi è la responsabilità se il materiale finisce dove non doveva, questione che si incrocia con gli obblighi di segnalazione della direttiva NIS2.

Dove la threat intelligence si ferma

Rileggete l’elenco di tutto quello che abbiamo descritto: modelli, standard, tecniche analitiche, valutazione delle fonti. Hanno un unico oggetto, l’avversario. Nessuno di essi contiene una sola informazione sulla vostra infrastruttura, per il motivo più semplice del mondo: non la guarda nessuno di loro.

Il Diamond Model ha un vertice chiamato “vittima”, è vero. Ma è popolato con i dati delle vittime osservate altrove. Non con i vostri.

Ne discende un limite che più dati non risolvono. Sapere che un gruppo attivo nel vostro settore entra sfruttando una certa categoria di difetti nei servizi esposti è conoscenza di valore alto. Non risponde però alla domanda che vi verrà fatta in consiglio: quella tecnica, applicata alla nostra configurazione, con i nostri controlli compensativi e la nostra segmentazione, apre una porta oppure no?

Quella risposta è sperimentale, non documentale. Si ottiene eseguendo la tecnica contro i sistemi veri e guardando cosa succede — che è precisamente ciò che separa un test offensivo da una valutazione teorica del rischio. Le due cose non competono, rispondono a domande diverse, come chiarisce il confronto fra vulnerability assessment e penetration test: uno misura la superficie, l’altro verifica se quella superficie cede davvero.

Dal modello alla prova: il threat-led testing

L’integrazione fra le due discipline ha già una forma codificata, e si chiama threat-led penetration testing. Qui l’intelligence non è un servizio parallelo che va per conto suo: è la fase preparatoria obbligatoria del test. Si costruisce un profilo di minaccia specifico per l’organizzazione, se ne ricavano scenari basati su TTP realmente osservate, e solo dopo si passa alla fase attiva sul perimetro concordato.

Nel settore finanziario europeo questa sequenza è normativa, con requisiti stringenti su durata, separazione dei ruoli e accreditamento dei fornitori — il quadro è descritto nell’analisi del rapporto fra DORA e Circolare 285. Fuori dal perimetro regolamentato nessuno vi obbliga a quell’apparato, e sarebbe sproporzionato applicarlo. La logica però resta identica, e funziona anche in versione leggera.

Il guadagno è la selettività. Un penetration test non guidato copre molte tecniche con poca profondità; uno guidato dalle minacce concentra lo sforzo su quello che gli attaccanti stanno davvero facendo ad aziende come la vostra. Alla fine non ricevete un elenco di rilievi tutti uguali, ma un giudizio circostanziato su quanto siete esposti — che è poi la domanda da cui siamo partiti.

Attribuzione: il problema più difficile e il meno utile

Stabilire chi c’è dietro un’intrusione è tecnicamente la parte più ardua del mestiere. È anche quella su cui la comunicazione commerciale è più disinvolta, e vale la pena spiegare perché.

Ogni elemento su cui si fonda un’attribuzione tecnica — infrastruttura, strumenti, tracce linguistiche, orari di attività, riuso di codice — è un elemento che l’avversario controlla. Se lo controlla, può manipolarlo. Esistono casi documentati di operazioni costruite deliberatamente con i marcatori di qualcun altro, per mandare gli analisti nella direzione sbagliata. Da qui l’abitudine, ormai diffusa, di usare designazioni neutre per i cluster di attività: descrivono un insieme di comportamenti osservati senza pretendere di dire chi sia.

Ma il punto pratico, per un’azienda privata, è un altro. Sapere quale sigla venga associata a una campagna quasi mai cambia le contromisure da adottare, perché quelle discendono dalle tecniche impiegate, non dall’identità di chi le impiega. Investire sui livelli alti della piramide degli indicatori e verificare periodicamente la propria esposizione rende molto di più. Sull’attribuzione persino i servizi statali si esprimono con gradi di confidenza dichiarati, mai con certezze. Se lo fa un fornitore, diffidate.