Guida alla Threat Intelligence per le aziende: tipi, ciclo e metriche
La threat intelligence è diventata una voce di bilancio prima ancora di diventare una pratica. Il rapporto Cost of a Data Breach 2025, realizzato da IBM con il Ponemon Institute, ha misurato in 7,19 milioni di real (R$) il costo medio di una violazione di dati in Brasile: il 6,5% in più rispetto ai 6,75 milioni del 2024. Nello stesso studio, l’adozione di intelligence sulle minacce guida la classifica dei fattori che hanno ridotto quel costo: 655.110 real in meno, in media, per ogni violazione.
Il problema è che «avere threat intelligence» e «sottoscrivere un feed» sono diventati sinonimi. Sono due cose diverse, e la differenza è esattamente ciò che separa un programma capace di cambiare decisioni da uno che produce soltanto PDF.
Questa guida è per chi deve costruire, correggere o giustificare un programma di intelligence sulle minacce: che cos’è e che cosa non è, i quattro tipi, le sei fasi del ciclo, come si distingue da SIEM e antivirus, gli errori che svuotano l’operatività, come misurare il risultato e che cosa cambia quando si opera in Brasile.
Che cos’è la threat intelligence
La cyber threat intelligence (CTI) è il processo che trasforma il dato grezzo sugli avversari in un prodotto capace di rispondere a una domanda di chi decide, con un grado di confidenza dichiarato, entro il tempo in cui quella decisione può ancora essere presa.
Si noti che la definizione contiene tre requisiti, e tutti e tre sono verificabili:
- Risponde a una domanda che qualcuno ha posto. L’intelligence non nasce dalla raccolta: nasce dal requisito.
- Arriva prima della decisione. Un’analisi corretta consegnata dopo l’applicazione della patch è cronaca, non intelligence.
- Cambia qualcosa. Un blocco, una priorità di remediation, una clausola contrattuale, un investimento, una comunicazione al cliente.
Se non riesci a indicare quale decisione ha cambiato il tuo deliverable, quello che hai è contenuto — magari anche buon contenuto, ma non è intelligence.
Che cosa non è threat intelligence
- Un feed di IOC. Un elenco di IP, hash e domini malevoli è materia prima. Diventa intelligence quando qualcuno ne valuta la rilevanza per il tuo ambiente, il contesto e la validità temporale.
- Una newsletter di sicurezza. La notizia di una vulnerabilità in una tecnologia che non usi non è intelligence per te.
- L’output di uno scanner di vulnerabilità. Quella è postura interna. La minaccia è ciò che esiste all’esterno, con intenzione e capacità.
- Il monitoraggio del dark web senza requisiti. Se non definisci che cosa cerchi e che cosa farai quando lo troverai, il risultato è una dashboard elegante e nessun responsabile.
- L’attribuzione. Sapere che il gruppo si chiama X raramente cambia ciò che il tuo team farà lunedì mattina.
I quattro tipi di threat intelligence
| Tipo | Chi la consuma | Vita utile |
|---|---|---|
| Strategica | Consiglio di amministrazione, CISO | Da mesi ad anni |
| Operativa | Responsabili del SOC, incident response | Da settimane a mesi |
| Tattica | Detection e threat hunting | Da mesi ad anni |
| Tecnica | Automazione, blocco | Da ore a giorni |
Il confine fra «tattica» e «operativa» è il più contestato della letteratura, e discutere l’etichetta è tempo perso. Ciò che conta è sapere, per ogni prodotto che generi, chi lo consuma e per quanto tempo il dato mantiene valore.
Strategica
Risponde a domande di investimento e di rischio: qual è l’esposizione del nostro settore al ransomware nei prossimi dodici mesi? Aprire una sede in quel Paese cambia il nostro profilo di minaccia? Il budget di sicurezza deve andare sull’identità o sulla superficie esterna?
Formato: report breve, linguaggio di business, senza gergo. Cadenza trimestrale o annuale. È l’unico tipo che deve essere leggibile da chi non è tecnico.
Operativa
Risponde a «chi, quando e perché»: campagne in corso, motivazione, settori bersaglio, stagionalità. Una campagna di phishing a tema Black Friday rivolta al retail brasiliano è intelligence operativa.
Formato: alert di campagna con contesto e raccomandazione. Si consuma in giorni o settimane.
Tattica
Descrive tattiche, tecniche e procedure (TTP) dell’avversario: come entra, come si muove lateralmente, come persiste, come esfiltra. È l’input del team di detection e del threat hunting, ed è il posto naturale per mappare tutto su MITRE ATT&CK.
È il tipo con il miglior rapporto fra sforzo e durata: cambiare una tecnica costa caro all’avversario; cambiare un dominio, no.
Tecnica
Indicatori di compromissione: IP, hash di file, domini di comando e controllo, URL di phishing, certificati. Serve per automazione e blocco, e invecchia in fretta — a volte nel giro di ore.
Vale la pena ricordare qui la Pyramid of Pain di David J. Bianco (2013): alla base ci sono gli hash, che l’avversario cambia in pochi secondi; in cima ci sono le TTP, che cambia soltanto con dolore. Un programma che consuma solo la base della piramide spende molto e infastidisce poco.
Il ciclo dell’intelligence: sei fasi
Il ciclo è ereditato dalla dottrina di intelligence — la Joint Publication 2-0 del Dipartimento della Difesa statunitense descrive lo stesso processo in sei tappe. Funziona nella sicurezza informatica per la stessa ragione per cui funziona lì: obbliga a partire dalla domanda e a chiudere con la critica.
1. Direzione
È la fase in cui si scrivono i PIR (priority intelligence requirements), cioè le domande prioritarie a cui il programma esiste per rispondere. È la fase che si salta più spesso ed è quella che spiega la maggior parte dei programmi falliti.
Un PIR scadente: «voglio sapere di ransomware».
Un PIR utilizzabile: «Negli ultimi 90 giorni, qualche gruppo ransomware ha sfruttato attivamente una delle cinque tecnologie esposte sul nostro perimetro? Owner: vulnerability manager. Decisione collegata: priorità della finestra di manutenzione del mese».
Un PIR funziona se ha un owner, una scadenza, una decisione appesa e se è effettivamente rispondibile con le fonti che possiedi davvero.
2. Raccolta
Fonti esterne: OSINT, feed commerciali e aperti, forum e marketplace chiusi, canali di messaggistica, community di condivisione settoriale, report dei vendor.
Fonti interne: i tuoi log, gli incidenti passati, i ticket antifrode, la telemetria degli endpoint, le segnalazioni di phishing dei dipendenti. È la fonte più rilevante che esista per il tuo ambiente ed è la più ignorata. Chi ti ha già attaccato è il miglior indicatore di chi ti attaccherà.
3. Elaborazione
Normalizzazione, deduplicazione, traduzione, arricchimento e standardizzazione del formato (STIX, MISP). Senza questa fase l’analista diventa un addetto alle pulizie dei dati e il programma non scala.
4. Analisi
L’unica fase che non si esternalizza. È qui che qualcuno valuta la rilevanza, correla con l’ambiente, formula ipotesi e dichiara il grado di confidenza. Usa una scala standardizzata: l’Admiralty Code (affidabilità della fonte da A a F, credibilità dell’informazione da 1 a 6) è il più semplice da adottare ed elimina già buona parte dell’ambiguità.
Un’analisi senza grado di confidenza dichiarato costringe il lettore a indovinare se hai ragione, e il lettore che deve indovinare ignora.
5. Diffusione
Lo stesso risultato diventa tre prodotti diversi a seconda del destinatario: una pagina per il vertice aziendale, una regola di detection per il SOC, una timeline per il team di risposta. Mandare a tutti e tre lo stesso report di 40 pagine equivale a non mandarlo a nessuno.
6. Feedback
La fase che quasi nessuno esegue. Chiedi a ciascun destinatario: l’hai usata? che cosa hai deciso? che cosa mancava? che cosa era superfluo? Senza questo passaggio i PIR non migliorano mai e il ciclo diventa una linea retta che finisce in archivio.
La threat intelligence non è un SIEM e non è un antivirus
| Livello | Domanda a cui risponde | Dove fallisce da sola |
|---|---|---|
| Antivirus / EDR | Questo è malevolo su questa macchina? | Non sa chi ti attacca né perché |
| SIEM / detection | È successo qualcosa di anomalo nei miei log? | Vede solo ciò che è già entrato |
| Threat intelligence | Chi mi attaccherà probabilmente, con che cosa, e che cosa faccio prima? | Non agisce: ha bisogno delle altre due |
La confusione è frequente perché tutti e tre consumano indicatori. La differenza sta nel punto di osservazione: l’EDR guarda dentro l’host, il SIEM guarda dentro la rete, la CTI guarda fuori dall’organizzazione.
E il rapporto è di alimentazione, non di sostituzione. L’indicatore tecnico scende verso il SIEM e l’EDR. La TTP diventa regola di detection e ipotesi di hunting. L’analisi strategica diventa budget. Un programma di intelligence che non ha una via d’uscita verso gli strumenti di detection è un programma di lettura.
Cinque errori che svuotano un programma di CTI
1. Comprare un feed di IOC e chiamarlo intelligence. Il volume non è qualità. Prima di sottoscrivere qualsiasi feed, chiedi: qual è l’origine dell’indicatore, qual è il tasso di falsi positivi misurato, qual è la vita utile media, copre fonti in portoghese e consegna in un formato che il mio stack ingerisce senza lavoro manuale?
2. Raccogliere senza PIR. La raccolta senza requisiti produce volume, e il volume produce la sensazione del lavoro fatto. È l’errore che consuma più budget con meno effetto.
3. Inseguire l’attribuzione. Il nome del gruppo è interessante e quasi mai azionabile. La TTP è azionabile quasi sempre.
4. Ignorare le fonti interne. Molte aziende pagano cara l’intelligence esterna e non hanno mai letto il proprio storico di incidenti.
5. Non chiudere il ciclo. Un report che nessuno legge è puro costo. Se non chiedi nulla al destinatario, chi produce non scoprirà mai di aver sbagliato bersaglio.
Come misurare se il programma funziona
Esistono due famiglie di metriche, e una delle due inganna.
Evita le metriche di produzione: numero di report pubblicati, numero di IOC ingeriti, numero di fonti sottoscritte. Salgono tutte quando lavori di più, e nessuna sale quando ci azzecchi di più.
Preferisci le metriche di effetto:
- Copertura dei PIR — percentuale dei requisiti in vigore con risposta aggiornata entro la scadenza.
- Tempo di operativizzazione — ore fra l’arrivo di un indicatore rilevante e il blocco o la regola in produzione.
- Detection originate dall’intelligence — quante detection del trimestre esistono perché la CTI ha segnalato per prima.
- Precisione della fonte — percentuale di indicatori che hanno generato un alert utile, misurata per feed. Un feed che produce solo rumore va cancellato con i numeri alla mano.
- Decisioni influenzate — registro puntuale delle decisioni (remediation prioritizzata, fornitore rivalutato, progetto rinviato) che citano un prodotto di intelligence.
- Copertura ATT&CK — quali tecniche del tuo modello di minaccia rilevi oggi, rispetto al trimestre precedente.
- Consumo — chi ha aperto, chi ha risposto al feedback. Una lettura bassa è il segnale di un prodotto sbagliato, non di un lettore distratto.
Scegline da tre a cinque, misurale per trimestre e pubblicale insieme a ciò che non sei riuscito a misurare. Una metrica senza riserve è marketing interno.
Il contesto brasiliano: che cosa cambia qui
L’orologio legale è di tre giorni lavorativi
L’art. 48 della LGPD (Legge 13.709/2018) — la legge brasiliana sulla protezione dei dati personali — obbliga il controlador (il titolare del trattamento, secondo la terminologia brasiliana) a comunicare l’incidente che possa comportare rischio o danno rilevante per gli interessati. La Risoluzione CD/ANPD n. 15/2024 ha fissato i termini:
- Tre giorni lavorativi per comunicare all’ANPD, l’autorità brasiliana per la protezione dei dati (art. 6), e all’interessato (art. 9), a decorrere dal momento in cui il controlador viene a conoscenza del fatto che l’incidente ha coinvolto dati personali.
- Venti giorni lavorativi per integrare le informazioni in modo motivato (art. 6, § 3).
- Termini raddoppiati per gli agenti di trattamento di piccole dimensioni (art. 6, § 8, e art. 9, § 6).
- L’art. 5 elenca i criteri di rischio rilevante: dati sensibili, di minori o anziani, finanziari, di autenticazione ai sistemi, protetti da segreto oppure trattati su larga scala.
- L’art. 10 impone di conservare il registro di ogni incidente — compresi quelli non comunicati — per almeno cinque anni.
La conseguenza pratica per l’intelligence è diretta: scoprire presto ha un valore giuridico, non solo tecnico. Una fuga di credenziali individuata dal monitoraggio esterno prima del contatto dell’attaccante cambia chi controlla l’orologio. E la comunicazione richiesta dall’art. 6, § 2 chiede esattamente ciò che un programma maturo già produce: natura e categoria dei dati coinvolti, rischi, impatti possibili e misure adottate.
Il settore finanziario ha regole proprie
La Risoluzione CMN n. 4.893/2021 impone una politica di sicurezza informatica e un piano di azione e risposta agli incidenti agli istituti finanziari e agli altri soggetti autorizzati a operare dalla Banca Centrale del Brasile. Gli istituti di pagamento, gli intermediari e le società di consórcio ne restano fuori e seguono norme proprie del BCB: conviene verificare quale si applica prima di disegnare il processo.
I vettori misurati in Brasile
Sempre dalla rilevazione IBM sul Brasile nel 2025: il phishing è stato il vettore iniziale più frequente, con il 18% delle violazioni (costo medio di 7,18 milioni di real); la compromissione di terze parti, il 15% — ed è la più costosa, con 8,98 milioni; lo sfruttamento di vulnerabilità, il 13% (7,61 milioni). Per settore, la sanità guida con 11,43 milioni, seguita da finanza (8,92 milioni) e servizi (8,51 milioni).
Due dei tre vettori principali stanno fuori dal tuo perimetro: il marchio usato per ingannare il tuo cliente e il fornitore compromesso che ha accesso al tuo ambiente. Nessuno dei due compare nel tuo SIEM prima del danno. Entrambi compaiono nella raccolta esterna.
La lingua è una barriera di copertura
I feed internazionali sono anglofoni per impostazione predefinita. Un kit di phishing in portoghese, un canale di messaggistica che vende un archivio con i CPF (il codice fiscale brasiliano), l’annuncio di un accesso a una specifica azienda brasiliana: niente di tutto questo arriva tradotto, e buona parte non arriva affatto. La copertura in portoghese non è una preferenza regionale: è un requisito di raccolta per chi opera in Brasile.
Un programma minimo in 90 giorni
- Giorni 1–30. Scrivi da tre a cinque PIR, ciascuno con owner e decisione collegata. Censisci gli asset esposti: domini, marchi, range di IP, applicazioni, fornitori critici. Definisci chi sono i tre destinatari dell’intelligence.
- Giorni 31–60. Accendi la raccolta minima che risponde a quei PIR. Crea un canale di diffusione per ciascun destinatario, con un formato dedicato. Apri la via d’uscita verso SIEM ed EDR.
- Giorni 61–90. Misura tre indicatori di effetto. Fai la riunione di feedback con ogni destinatario. Taglia ciò che nessuno ha letto.
Un programma piccolo che chiude il ciclo produce più di uno grande che si limita a raccogliere.
Dove si inserisce la piattaforma OODA Intelligence
La piattaforma conta 41 moduli, e il modo utile di guardarli è per fasi del ciclo, non per elenco:
- Raccolta: Collection (canali di messaggistica, forum clearnet e darknet, feed), Threat Monitoring (monitoraggi per parola chiave con avvisi multicanale), EASM e Recon per la superficie esterna.
- Raccolta mirata su marchio, infrastruttura ed esposizione: Threat Intelligence, con i sotto-moduli di dominio, rete, phishing e abuso del marchio, e Data Leak Detection per credenziali e archivi esposti.
- Elaborazione e analisi: Search Intelligence per la ricerca unificata su quanto raccolto e Investigate per le indagini con tracciabilità forense.
- Diffusione: SIEM Bridge, MISP Sync, Intelligence Reports e l’API REST.
- Registro e feedback: Incident Management e Audit & Compliance — quest’ultimo collegato direttamente agli obblighi di registrazione imposti dalla Risoluzione ANPD n. 15/2024, tema che approfondiamo nell’articolo su LGPD e sicurezza informatica.
Esiste inoltre una linea di raccolta dedicata alla stampa e al fact-checking: 76 fonti giornalistiche registrate alimentano News Intelligence, mentre Disinfo Verify incrocia le affermazioni con un archivio di verifiche pubblicate dalle agenzie di fact-checking. È lo strato che risponde al rischio reputazionale e alla disinformazione rivolta al marchio.
Una precisazione onesta per chiudere: nessuno strumento scrive il tuo PIR né decide che cosa è rilevante per il tuo business. La piattaforma accorcia raccolta, elaborazione e diffusione, cioè la parte di lavoro manuale. Direzione e analisi restano lavoro umano — ed è esattamente per questo che il tuo programma va organizzato attorno al ciclo, non attorno al catalogo dei moduli.
Fonti
- IBM e Ponemon Institute. Cost of a Data Breach Report 2025 — dati sul Brasile, IBM Newsroom, 30/07/2025.
- Brasile. Legge n. 13.709/2018 (LGPD), art. 48.
- ANPD. Risoluzione CD/ANPD n. 15, del 24 aprile 2024 — Regolamento sulla comunicazione degli incidenti di sicurezza. Si veda anche la pagina ufficiale sulla comunicazione degli incidenti.
- CMN. Risoluzione n. 4.893, del 26 febbraio 2021.
- BIANCO, David J. The Pyramid of Pain, 2013.
- MITRE ATT&CK.
- U.S. Department of Defense. Joint Publication 2-0, Joint Intelligence — processo di intelligence in sei tappe.
