Già in passato, discutendo della necessità di una piattaforma di condivisione delle informazioni sulla cybersecurity con il governo (o qualsiasi altro organismo di coordinamento), è emerso il motivo per cui una soluzione aperta è il miglior approccio possibile per garantire il massimo grado di sicurezza informatica e la conformità agli standard, consentendo al contempo alla comunità di avere la libertà di decidere quale piattaforma di monitoraggio della sicurezza informatica adottare.
Cosa è necessario e qual è stato dell’arte
La condivisione delle informazioni è un argomento complesso, in cui è possibile identificare chiaramente due aree distinte:
1. La condivisione di pacchetti già “definiti” di Indicatori di attacco (IoA) e Indicatori di compromissione (IoC), che isolano una particolare minaccia e forniscono agli investigatori il “dove cosa come” di un attacco.
2. La possibilità di condividere i dettagli di attacchi nuovi, zero day ed emergenti, essendo in grado di vedere decine o centinaia di fonti di informazioni di ricognizione da tutto il mondo, che può rapidamente mettere fuori gioco la proliferazione del malware.
La prima area di condivisione delle informazioni comporta la distribuzione di un elenco di IoC (semplici hash o condizioni più complesse), 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. La condivisione delle informazioni può essere utile per arricchire la lista IoC, o per aggiungere commenti e informazioni aggiuntive sull’origine del malware stesso, nuovi comportamenti, tattiche di mitigazione, ecc.
La seconda area, che punta a rilevare le minacce emergenti, 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. Ora possiamo chiederci: che aspetto ha un’architettura di condivisione aperta e inter-tecnologica?
Un modello ben noto e ampiamente accettato per integrare i dati condivisi da più fonti, compresi gli strumenti di cybersecurity, è il modello SIEM. Due o più tecnologie, potenzialmente di diversi fornitori e che coprono diverse aree dello spettro della cybersecurity, inviano i loro log e avvisi a un SIEM, in batch o in tempo reale. In alcune situazioni, questi vengono normalizzati all’origine con un Information Model, ma in altre situazioni i dati vengono normalizzati nel SIEM stesso. La normalizzazione dei dati in un Information Model comune è importante per permettere una correlazione generica e trasversale degli eventi – che è resa possibile dal fatto che la semantica di ogni campo è ben definita. Per esempio, il ben noto e distribuito Common Event Format (CEF) definisce che il campo “src” deve essere l’indirizzo IPv4 della fonte dell’attacco o dell’evento – una semantica così semplice semplifica il modo di analizzare i dati (un IP src, non un indirizzo MAC, non un hostname o altro) e di identificare le correlazioni e porre rimedio come opportuno.
Immaginiamo ora come questo si applica alla condivisione delle informazioni con un ente governativo che agisce come un centro di coordinamento centrale, come un “SIEM governativo”. Questo non è realistico oggi, perché questo modello richiede la condivisione di ogni possibile dettaglio, scoperto da ogni tecnologia, ai più alti livelli in modo che ogni tipo di correlazione possa avvenire lì. Quindi, anche se il modello SIEM può essere utilizzato all’interno delle singole aziende, o anche con enti esterni come il governo, non può essere utilizzato “così com’è” per implementare uno schema di condivisione dei dati che preservi la privacy per dare la caccia in modo sicuro e collettivo alle minacce emergenti.
Formati ben noti per la condivisione dei dati di intelligence sulle minacce e API sono Structured Threat Information Expressions (STIX) e Trusted Automated Exchange of Intelligence Information (TAXII). Sono stati progettati per condividere l’intelligence sotto forma di Indicatori di Compromissione utilizzati per un particolare attacco. Come tali, sono ideali quando una minaccia è già stata identificata da un team di ricerca sulla sicurezza. Tuttavia, non sono stati progettati per preservare la privacy e per essere utilizzati per individuare le minacce emergenti osservando i dati da più siti. Sì, possono essere potenzialmente estesi per farlo – per esempio aggiungendo gli spazi dei nomi STIX e le relative regole/procedure – ma la possibilità di rompere la compatibilità con gli strumenti esistenti e creare effettivamente un nuovo standard è reale.
Ci sono molti altri progetti e formati che si occupano di condivisione delle informazioni, come OpenDXL (che si piega principalmente verso l’orchestrazione), CIF (che fornisce un framework e un’implementazione per l’arricchimento, la condivisione e la gestione delle informazioni sulle minacce), MISP (che mira a costruire una comunità collaborativa per rilevare e classificare le minacce note) e OpenIOC (che, simile a STIX, mira a standardizzare il formato delle IOC). Tutti questi progetti sono applicabili e testati per la prima area di condivisione delle informazioni, ma non si adattano realmente al requisito di cacciare in modo collaborativo le minacce emergenti preservando la privacy.
Oltre a questi standard di condivisione delle informazioni, c’è anche una buona quantità di progetti di condivisione a guida governativa che li sfruttano, tra cui CyberSentry (che include una buona spiegazione sui dati raccolti), e il Cybersecurity Risk information Sharing Program (CRISP), tra molti altri in pratica.
Anatomia di una soluzione
Considerando il successo diffuso di STIX/TAXII, così come di tutti i formati e le API stabiliti sopra, è chiaro che un approccio standardizzato, trasparente, ben documentato e ben governato per rilevare collettivamente le minacce è fondamentale per incoraggiare l’adozione e i continui sforzi di sviluppo.
Una soluzione per la condivisione delle informazioni dovrebbe essere in grado di colmare le lacune del rilevamento delle minacce emergenti, integrandosi bene con il suddetto ecosistema di condivisione delle minacce, in modo da evitare di reinventare la ruota. Inoltre, consentire alla comunità degli utenti e ai vendor di sfruttare i loro investimenti esistenti nella cybersecurity piuttosto che ricostruire o adottare nuovi investimenti, e poi crescere da lì, fornisce il massimo supporto possibile agli obiettivi generali.
Una soluzione eccellente per garantire apertura e trasparenza è avere un’implementazione open source, che può essere un punto focale per un approccio pragmatico con uno strumento pratico utilizzato per testare la compatibilità e la conformità con i vari standard e implementazioni. Uno che non sia un giocattolo, ma che sia pronto per la produzione. Uno dove ogni parte coinvolta (vendor, clienti) può studiare ogni dettaglio e linea di codice.
Nello spirito di sostenere la trasparenza dell’open source, 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. Inoltre, potrebbero essere forniti dei client “campione” che dimostrino come consumare le API con i linguaggi di programmazione più comuni, al fine di accelerare l’adozione e abbassare i costi di sviluppo.
Deve essere fornito un meccanismo per condividere eventi o indicatori senza violare la privacy o la segretezza dei dati. Potenzialmente, è possibile considerare una Privacy Differenziale per permettere 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.
Conclusioni
Come abbiamo visto, l’intelligence e la condivisione della conoscenza rappresentano un argomento complesso con standard interessanti che le soluzioni sono pronte a utilizzare, oggi, per consentire a un ente centrale di ricevere intelligence da un insieme diversificato di collaboratori. Le soluzioni di successo in questo settore utilizzano standard aperti, con un sacco di codice ed esempi che sono liberamente disponibili per i fornitori da implementare.
D’altra parte, il complesso coordinamento automatico o semi-automatico tra pari per rilevare le minacce emergenti, preservando la privacy, è un’area ancora meno esplorata, senza veri standard, formati di scambio o API. Si tratta di lacune che è possibile colmare attraverso un approccio metodico e soprattutto olistico, che consenta un’interoperabilità di fondo, in vista di una reale integrazione.
Di Emanuele Temi, Technical Sales Engineer di Nozomi Networks
