OCSF è la chiave per la democratizzazione dei data lake di sicurezza?
Rilevare e bloccare gli attacchi informatici di oggi richiede il coordinamento di molti strumenti di sicurezza diversi. Purtroppo, il tempo e le risorse che i team impiegano per unificare questi dati dei registri di sicurezza rappresentano un costo accettato per l'esecuzione delle analisi necessarie a individuare potenziali attacchi. Il progetto Open Cybersecurity Schema Framework (OSCF) si pone l'obiettivo di cambiare questa situazione, per permettere ai team di dedicare meno tempo all'analisi e più tempo alla protezione degli ambienti. Ma vediamo cosa rende questo nuovo approccio così importante e prezioso.
Affinché i dati degli eventi dei registri di sicurezza siano utili, ogni registro deve disporre di uno schema che definisca i campi disponibili per la ricerca, l'aggregazione o il rilevamento prima del registro. Ad esempio, un registro delle connessioni di rete potrebbe avere un IP di origine che ha avviato la connessione e un IP di destinazione che ha ricevuto e servito una risposta alla richiesta. Lo schema dovrebbe avere campi come src e dest, per permettere agli analisti della sicurezza di effettuare query su questi campi.
Tuttavia, c'è poco accordo tra i tipi di registro o gli strumenti da utilizzare per questi schemi. Usando lo stesso esempio, CrowdStrike estrae l'origine IP dei registri di rete come ip e la destinazione come RemoteAddressIP4. I firewall PAN chiamano l'IP di origine src e quello di destinazione dst. Alcuni registri sono completamente destrutturati e gli IP di origine e di destinazione possono essere determinati solo grazie alla comprensione del formato del registro e alla posizione dell'IP all'interno dell'evento di registro.
Spesso gli analisti desiderano eseguire query su ampi sottoinsiemi di registri. Ad esempio, potrebbero voler sapere se, tra tutti i registri di rete, un host si è mai collegato a un determinato indirizzo IP. A tal fine, non solo è necessario uno schema per ogni tipo di registro, ma serve anche che questi schemi concordino. Sarebbe utile se esistesse un modo migliore per inserire e analizzare i dati con meno lavoro manuale!
Le sfide della normalizzazione dei registri
Finora, Salesforce ha affrontato questo problema con una complessa soluzione interna chiamata “Events Data Dictionary” (DDI), un dizionario dei dati degli eventi che elenca ogni singolo campo in ogni singolo registro. E abbiamo definito regole di estrazione dei campi dati (DFE, Data Field Extraction) che analizzano i registri e applicano il dizionario come schema. Nell'architettura di rilevamento e risposta, questo processo avviene in un sistema definito "normalizzatore".
Dopo la normalizzazione, tutti i registri, compresi quelli precedentemente non strutturati, presentano schemi corrispondenti tra di loro e un insieme di campi che è possibile interrogare. Estraiamo RemoteAddressIP4 dai registri di CrowdStrike e lo rinominiamo IPDestination; allo stesso modo, dst dei registri di PAN diventa IPDestination, e gli analisti scrivono semplicemente delle query se vogliono vedere se ci si è connessi a un particolare IP interrogando tutti i registri e chiedendo dove IPDestination == [...].
Teoricamente, è fantastico. Gli analisti possono effettuare ricerche. Tuttavia, la normalizzazione dei registra genera anche delle sfide:
- Nel dizionario dei dati ci sono centinaia di campi, molti dei quali sono NULL e sprecano molto spazio.
- Quando si ottiene un nuovo tipo di registro, i campi possono essere in disaccordo con quelli definiti in precedenza e quindi generare strani casi limite (ad esempio, user, username, useremail a seconda del tipo di registro hanno significati diversi).
- Dobbiamo analizzare manualmente ogni nuovo tipo o sottotipo di registro come parte dell'onboarding di una nuova sorgente di registro, scrivendo regole regex o di parsing.
- Qualsiasi modifica, aggiunta o sostituzione alla struttura del registro può portare le regole esistenti a non analizzare i campi rilevanti. Si tratta di un grave problema per quanto riguarda la qualità dei dati.
- Inoltre, non esiste un modo valido per convalidare o tenere traccia delle regole su scala. È molto probabile che le regole siano duplicate; è difficile mantenere o aggiornare il set di regole, perché la deprecazione delle regole comporta un rischio sostanziale. Ciò può comportare delle regressioni, in cui le nuove regole sovrascrivono la funzionalità di quelle vecchie.
Tutto questo lavoro ha un costo crescente. Invece di concentrarsi principalmente sul rilevamento e sulla risposta agli eventi, i team dedicano il proprio tempo a normalizzare manualmente questi dati come prerequisito.
Adozione di OCSF
Open Cybersecurity Schema Framework (OCSF), annunciato al pubblico come standard di schema aperto durante il BlackHat dell'agosto 2022, è un progetto unico nel suo genere, uno sforzo importante per generalizzare i dati tra più fonti di cybersecurity. Questo framework mira a fornire una tassonomia semplificata e indipendente dai fornitori, per aiutare tutti i team per la sicurezza a realizzare un livello migliore e più rapido di inserimento e analisi dei dati, senza dover ricorrere a una normalizzazione iniziale, che di solito richiede molto tempo.
L'obiettivo è quello di disporre di uno standard aperto che possa essere adottato in qualsiasi ambiente e da qualsiasi applicazione e provider di soluzioni e che si adatti agli standard e ai processi di sicurezza esistenti. OCSF è un framework open source simile al nostro approccio Data Dictionary, poiché mira a risolvere sia il problema iniziale descritto sopra sia i punti dolenti derivanti dal nostro approccio, definendo un sottoinsieme di campi da schematizzare in base all'uso degli analisti.
Il nostro Chief Trust Officer, Vikram Rao, ha dichiarato: "Ogni azienda si trova di fronte all'imperativo di diventare digitale, e in fretta. Ma la creazione di una struttura di sicurezza in grado di soddisfare i livelli di fiducia digitale su scala Internet può rappresentare una sfida importante. I nuovi standard come OCSF riducono la complessità per i team per la sicurezza, consentendo loro di concentrarsi su lavori di maggiore impatto quali l'analisi delle minacce e la prevenzione degli attacchi."
Il test di esecuzione
Il team Salesforce Detection and Response Engineering ha valutato OCSF, sia considerando di applicare questo schema ai registri generati da Salesforce sia adattando il nostro attuale approccio alla normalizzazione per produrre dei registri con gli schemi definiti da OCSF, anziché con i nostri schemi personalizzati definiti nell'Events Data Dictionary.
Per comprendere meglio OCSF, abbiamo prima eseguito un esercizio per trasformare in formato OCSF e valutare un ipotetico evento di rilevamento della sicurezza di Salesforce. Di seguito sono riportate le schermate dell'evento nel nostro attuale formato DDI e nel formato OCSF.
Mentre lavoravamo a questo esercizio ed esploravamo lo schema OCSF, abbiamo identificato dei campi interessanti che potremmo potenzialmente utilizzare; ad esempio l'oggetto remediation. Questo campo aiuta a collegare gli articoli della knowledge base alle descrizioni, un'opportunità utile per gli analisti a valle durante la valutazione degli incidenti e per intraprendere ulteriori azioni.
Abbiamo iniziato a lavorare con i team interni e a creare prototipi, valutando la trasformazione dei registri delle nostre applicazioni interne, sfdc_applog, in produttori di registri conformi a OCSF. Ci auguriamo di continuare a collaborare anche in futuro. Se volete partecipare e usare questo schema per standardizzare i vostri registri, potete iniziare a utilizzare GitHub di OCSF [qui].
Un grande applauso
Il progetto Open Cybersecurity Schema Framework, volto a semplificare la classificazione dei dati in un quadro neutrale rispetto ai fornitori, così da aiutare i team per la sicurezza a dedicare meno tempo alla normalizzazione dei dati e più tempo alla difesa, merita un applauso. OCSF include i contributi di Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro e Zscaler.
Noi di Salesforce siamo entusiasti e siamo stati i primi ad adottare OCSF. Questi primi esercizi che abbiamo svolto per trasformare i nostri eventi di tipo registro in OCSF hanno rappresentato un ottimo primo passo e hanno contribuito a coinvolgere diversi team interni, affinché conoscessero il framework e la sua posizione. Dato che OCSF è uno standard aperto e uno sforzo collaborativo in tutto il settore della sicurezza, con più parti interessate che adottano lo standard e lo aiutano a evolversi, ha il potenziale per democratizzare i data lake della sicurezza in tutte le organizzazioni.
Infine, affinché OCSF abbia il massimo impatto, è necessario che i provider di servizi cloud e di sicurezza si allineino e forniscano i registri nello schema OCSF. Se fate parte di questo settore, contribuite ad abbattere i confini e a renderlo lo standard nella community dedicata alla sicurezza!