I Threat Intelligence Feeds sono sempre più determinanti per tutte le realtà che si occupano di sicurezza, vendor e partner IT, con o senza SOC (Security Operation Center). Questi servizi applicativi – uno dei più diffusi è di Recorded Future - si rivolgono in sottoscrizione alla singola azienda, o rappresentano il cuore di piattaforme di monitoraggio degli attacchi a cui attingere e con cui stabilire una connessione continua.
Ormai è ben chiaro che la cybersecurity deve operare attraverso modelli proattivi, l’approccio difensivo non è più efficace di fronte ad attacchi sempre più frequenti, dannosi e sofisticati. Da qualche anno ormai, tutti i vendor di sicurezza hanno convertito la propria offerta proponendo piattaforme di protezione modulari che puntano a individuare il pericolo se non prima che si manifesti il danno, almeno poco tempo dopo. Piattaforme complete che coprono i diversi aspetti della security, in cui la fase di monitoraggio in tempo reale è predominante.
La cybersecurity, inoltre, oggi è un servizio, che i system integrator e i managed service provider erogano in outsourcing, attraverso il loro centri operativi e garantendo un supporto 24x7. E, se la proattività è il nuovo paradigma della sicurezza, i partner specializzati devono strutturarsi per garantirla. Per intercettare il pericolo imminente o la propagazione di un attacco si fa ricorso a reti e hub collaborativi, in cui i partecipanti condividono in tempo reale le informazioni raccolte dai feedback automatici delle piattaforme e dei servizi presenti presso i loro clienti e da altre fonti informative. L’analisi dei contenuti pubblicati nel Deep Web e delle conversazioni dei forum, diventano sorgenti preziose per avere in ogni momento il polso della situazione.

I modelli teorici su cui si basa la condivisione delle informazioni
Così, le piattaforme di monitoraggio e interscambio delle informazioni sono i luoghi in cui vendor e partner concorrenti collaborano in nome della sicurezza di tutti. La condivisione delle informazioni avviene secondo alcuni modelli teorici, l’Hub & Spoke o il Source & Subscriber, centralizzati, oppure il Peer to Peer, decentrato per definizione. La differenza tra i primi due non è nella topologia della rete, ma nel modo in cui vengono distribuite le informazioni.
L’Hub & Spoke presenta un hub che accentra le informazioni e le distribuisce, il Source & Subscriber, invece, richiede che chi è interessato scelga di consultare interpellando la Source. Nel Peer to Peer, infine, le informazioni circolano senza criteri gerarchici. Il criterio di distribuzione, inoltre, segue generalmente il TLP (Traffic Light Protocol) per garantire lo scambio di informazioni in maniera controllata. A completamento dei modelli teorici, nell’ambito dei Threat Intelligence Feeds o degli hub informativi si parla di strutture come il STIX (Structured Threat Information eXpression) o il TAXII (Trusted Automated eXchange of Indicator Information). Alle iniziative dei vari gruppi di vendor di security che partecipano tutti alle community che costruiscono questi hub, inoltre, si affiancano quelle delle Istituzioni internazionali, come la Comunità Europea o gli USA con la sua CISA, o nazionali come l’Italia.

Vantaggi e limiti della Threat Intelligence
Parlando di strutture di condivisione e collaborazione in ambito tecnologico è facile immaginare che si basino su principi tipicamente open source, in cui l’openess può riguardare il codice delle piattaforme, ma anche il modello e la filosofia collaborativa. Ma, insieme agli indubbi vantaggi della condivisione in tempo reale delle informazioni sugli attacchi (e di molto altro), l’approccio delle soluzioni e delle piattaforme di Threat Intelligence comporta qualche piccola criticità. In primo luogo, c’è da considerare la tipologia di informazioni che si condividono, è fondamentale trovare il giusto equilibrio tra ciò che è necessario per eseguire un’analisi completa di un attacco e ciò che di sensibile non può essere condiviso. Le grandi aziende che partecipano alla raccolta dati, inoltre, non hanno ancora accettato che segnalare un attacco o una vulnerabilità ha un valore per la comunità maggiore dell’eventuale danno d’immagine.

A proposito di quale sia l’equilibrio giusto tra cosa comunicare e cosa non comunicare, è interessante riportare la riflessione di Emanuele Temi, Technical Sales Engineer di Nozomi Networks, azienda specializzata nella protezione e nel monitoraggio di architetture OT (Operational Technology) e IoT. “La condivisione di pacchetti definiti di indicatori d’attacco (IoA) comporta la distribuzione di un elenco di IoC (indicatori di compromissione), una descrizione di ciò che fa il malware e altre informazioni rilevanti. In linea di principio, tali pacchetti non hanno informazioni identificative e contengono poca o nessuna correlazione con il sito originale (o i siti) dove gli indicatori sono stati individuati. Quindi, possono e devono essere condivisi tra pari o con un ente centrale”. “Rilevare le minacce emergenti – prosegue Temi -, richiede un grado superiore di dettaglio da condividere, perché in definitiva capire che una nuova minaccia sta colpendo più siti richiede che i dati vengano confrontati per identificare i modelli emergenti. D'altra parte, la segretezza dei dati è importante per impedire agli attaccanti di sfruttare l'intelligence e per proteggere l'identità dei partecipanti alla condivisione. Questi due sembrano requisiti contrastanti, ma con un adeguato set di regole e API, è possibile condividere solo una quantità minima di informazioni ed essere ancora in grado di osservare modelli comuni tra i pari”.
Per raggiungere l’obiettivo ipotizzato - condividere solo una quantità minima di informazioni ed essere ancora in grado di osservare modelli comuni - Temi spinge su una maggiore “openess” dei sistemi di rilevamento esistenti.
“Il complesso coordinamento automatico o semi-automatico tra pari per rilevare le minacce emergenti, preservando la privacy, è un'area ancora poco esplorata, senza veri standard, formati di scambio o API”. Dunque, in definitiva: “Una soluzione eccellente per garantire apertura e trasparenza è avere un'implementazione open source, uno strumento pratico utilizzato per testare la compatibilità e la conformità con i vari standard e implementazioni, dove ogni parte coinvolta (vendor, clienti) può studiare ogni dettaglio e linea di codice”.
“Con questo approccio, le API possono essere documentate in modo standard, per esempio usando il formato OpenAPI, permettendo una più rapida evoluzione e validazione delle suite di test automatici”. “Deve essere fornito un meccanismo per condividere eventi o indicatori senza violare la privacy o la segretezza dei dati – conclude Temi -. Per esempio, considerando un modello che permetta ai contributori di condividere più dettagli, come l'aspetto di specifiche vittime interne, ma senza rivelare le loro vere identità. Le API e il sistema dovrebbero consentire alle macchine di interagire automaticamente l'una con l'altra, senza timore di fuga di informazioni, e quando vengono rilevate delle corrispondenze, consentire l'avvio di ulteriori indagini su conferma dell'operatore”.