Perché la tua threat intelligence è quasi tutta rumore

Chiunque può aggregare feed di threat intelligence. NVD, GitHub Security Advisories, CISA KEV, Abuse.ch, AlienVault OTX, una manciata di feed RSS: in un pomeriggio hai un sistema che ingoia decine di migliaia di minacce. Il problema è che a quel punto hai costruito una macchina per generare rumore, non intelligence. La metrica che conta non è quante minacce traccia il tuo sistema - è quante un essere umano decide davvero di affrontare. È la verità più controintuitiva di questo mestiere: il valore sta nella soppressione, non nell'aggregazione. Quando ho costruito il motore di rilevanza di Valta, è questa la domanda che mi ha guidato: come passo da migliaia di minacce alla manciata che conta, per questa organizzazione, oggi?

Cos'è (davvero) la threat intelligence

Prima di tagliare il rumore, serve sapere cosa si sta tagliando. La CTI ha tre livelli: strategico (chi prende di mira il tuo settore, le tendenze), operativo (le campagne, le tecniche degli attaccanti) e tattico (gli IOC, gli indicatori di compromissione: hash, IP, domini). La maggior parte dei "prodotti di threat intelligence" vende il livello tattico - feed di IOC - che è anche il meno durevole: come ricorda la "Pyramid of Pain" di David Bianco, un hash o un IP l'attaccante li cambia in un minuto. E intorno a tutto c'è una disciplina, il ciclo dell'intelligence (direzione, raccolta, processazione, analisi, disseminazione, feedback): l'intelligence non è un feed, è un processo che parte da una domanda e finisce in una decisione.

Severità non è priorità: il limite del CVSS

Qui sta l'errore concettuale più diffuso. Il CVSS, il punteggio con cui si misurano le vulnerabilità, dice quanto è grave una falla se sfruttata - in astratto, nel vuoto. Non dice nulla su quanto è probabile che venga sfruttata, né se riguarda te. Ed è un divario enorme: studi su larga scala - tra cui i dati dietro l'EPSS e le ricerche del Cyentia Institute - mostrano che solo una piccola frazione delle CVE, dell'ordine di pochi punti percentuali, viene mai sfruttata davvero nel mondo reale. Trattare ogni 9.8 come un'emergenza significa annegare nel rumore e ignorare il 6.5 che ti riguarda sul serio.

La risposta del settore è uno stack di prioritizzazione a più segnali: il CVSS (quanto è grave) si combina con l'EPSS (Exploit Prediction Scoring System, mantenuto dal FIRST, che stima la probabilità di sfruttamento), con la CISA KEV (il catalogo di ciò che è attivamente sfruttato - la verità sul campo) e, sopra tutto, con il tuo contesto: quel software lo usi? È esposto su Internet? Solo l'incrocio di questi segnali trasforma una lista di gravità in una lista di priorità.

Le fonti mentono per omissione

C'è poi un problema a monte, nei dati grezzi. Se ti affidi solo a NVD, la tua distribuzione di severity è strutturalmente sbilanciata: nei miei dati NVD produce circa il 2% di vulnerabilità LOW. Non perché le LOW non esistano, ma perché il suo processo di scoring tende a concentrarsi sull'alto impatto. Se costruisci la tua intelligence su una sola fonte, ne erediti i punti ciechi.

La soluzione è il multi-source con intenzione, non per accumulo. GitHub Security Advisories porta severity native, incluse le LOW e MEDIUM che NVD spesso non assegna. La CISA KEV ha una semantica precisa: ogni voce è una vulnerabilità attivamente sfruttata, quindi per definizione la tratto come CRITICAL, con un flag se è legata a ransomware. Ogni fonte non è una copia delle altre - è una prospettiva diversa sullo stesso panorama.

La rilevanza è contesto, non gravità

Qui sta il cuore del problema, ed è quello che Valta è stato costruito per risolvere. Una CVE Critical su un software che non usi è meno urgente di una Medium su un componente che esponi su Internet. La gravità assoluta è solo metà della storia; l'altra metà è il contesto. Il motore di Valta valuta ogni minaccia rispetto al profilo reale dell'organizzazione - lo stack tecnologico, il settore, la superficie d'attacco nota. Un large language model fa il lavoro di giudizio contestuale che non puoi codificare in una regola statica, ma sopra ci ho messo un gate non negoziabile: una vulnerabilità diventa rilevante solo se c'è un match esplicito con un prodotto in uso o con una minaccia diretta al settore. Quel gate, da solo, ha trasformato un flusso pieno di falsi positivi in una lista che un analista si fida di leggere.

Il rumore è il vero bug

La war story più istruttiva non è tecnica, è di design. La prima versione del sistema di alerting faceva la cosa ovvia e sbagliata: ogni minaccia generava un alert, e ogni alert veniva mandato a tutti gli utenti via email, senza filtrare per rilevanza all'organizzazione. Il risultato era una valanga di centinaia di email al giorno, di cui la stragrande maggioranza irrilevante per chi le riceveva. In poche settimane le persone smettono di leggere. Un sistema di alert che nessuno legge è peggio di nessun sistema, perché dà una falsa sensazione di copertura - è la alert fatigue, una delle cause più documentate dei breach che "i log avevano visto ma nessuno aveva guardato".

La riscrittura ha introdotto due principi. Primo, il gating per rilevanza: un alert parte solo se la minaccia è davvero rilevante per quell'organizzazione. Secondo, tre livelli invece di uno.

Non ho aggiunto intelligenza generando più alert - l'ho aggiunta decidendo cosa non far arrivare. È la differenza tra un sistema che ti informa e uno che ti aiuta.

I dettagli che non trovi nella documentazione

L'ingegneria vera vive negli angoli, e una pipeline di CTI ne è piena. Due esempi reali dall'integrazione con le GitHub Advisories. Primo: l'API non accetta un timestamp ISO 8601 per filtrare per data di pubblicazione - vuole un range nel formato YYYY-MM-DD..YYYY-MM-DD. Passargli un timestamp con T e Z fallisce in silenzio, e te ne accorgi solo quando i conteggi non tornano. Secondo: la paginazione. La tentazione è estrarre il cursore dalla risposta e ricostruire l'URL. Errore: il cursore è già URL-encoded, e il client HTTP lo encoda una seconda volta, rompendo la query. La soluzione corretta è usare l'URL completa fornita nell'header Link, senza toccarla. Sono dettagli da niente - finché non ti costano mezza giornata, e finché non ti accorgi che è proprio in questi dettagli che una pipeline silenziosamente perde dati.

Come valutare una piattaforma di threat intelligence

• Rilevanza: filtra per il tuo profilo, o trasmette tutto a tutti?
• Fonti: è multi-source, o eredita i punti ciechi di una sola (il problema NVD-only)?
• Prioritizzazione: usa EPSS e KEV, o si ferma al CVSS?
• Contesto: incrocia le minacce con il tuo inventario di asset?
• Soppressione: ha dei livelli (immediato / digest / silenzioso) o inonda?
• Spiegabilità: ti dice perché una cosa è rilevante, o è una scatola nera?

La conclusione

Il mestiere della threat intelligence non è dirti tutto ciò che è successo - quello lo sa fare chiunque, basta un aggregatore. È dirti le tre cose su cui devi agire adesso. Il valore non è nell'aggregare, è nel sopprimere con criterio: scegliere, per ogni organizzazione e ogni giorno, cosa non far arrivare. Costruisci la soppressione, non l'accumulo.