Compliance Continua come Codice P1: Sigma

La conformità è sempre stata una sorta di processo reattivo poiché gli standard sono lunghi, richiedono un grande sforzo e un po’ di tempo per essere aggiornati, ancora più tempo per essere implementati e il processo di audit avviene una volta all’anno. Provenendo dal mondo dei SIEM, mi occupavo di conformità attraverso un prisma di rapporti preconfezionati che solitamente restituivano risultati vuoti o qualcosa di molto lontano dall’essere spiegabile a un revisore esterno. D’altra parte, la logica sottostante dei rapporti e delle query è oscura e richiede un grande sforzo per essere mantenuta, per non dire altro. Per farlo funzionare bisogna padroneggiare il motore delle regole di correlazione o il linguaggio di query della tecnologia SIEM specifica e il motore di reporting che lo accompagna, configurare un sacco di elenchi ed eccezioni in modo statico, mentre l’ambiente reale è dinamico e il solo raccogliere tutti i dati in un unico posto può richiedere molti mesi. E quando abbiamo terminato questi compiti la tecnologia SIEM cambia o io inizio a lavorare con un altro cliente che utilizza un sistema di analisi della sicurezza basato su ricerca invece del vecchio stile di “correlazione in tempo reale”. Diventa più facile se abbiamo strumenti di audit della sicurezza come scanner VM che hanno funzionalità di audit della conformità ad esempio Qualys Policy Compliance, Tripwire e simili. Tuttavia, questi ultimi strumenti non costruiscono un quadro olistico né in tempo reale a meno che non siano connessi con una piattaforma SIEM o di analisi della sicurezza di qualche sorta. Poi arriva il treno GRC con prodotti massicci e anni/uomo di consulenza. Noioso. Inefficiente dal punto di vista dei costi. Garanzia di lacune nella visibilità. Troppo lento per l’era digitale in cui viviamo. E quanto sono buoni tutti questi nell’affrontare NIST CSF o GDPR? IMHO la conformità è un riflesso della sicurezza, quindi se fai sicurezza informatica nel modo giusto la conformità seguirà. Tuttavia, questo non funziona al contrario. È tempo di un cambiamento? Sì. E oggi inizieremo la serie di articoli per rendere la tua conformità un processo agile, trasparente ed efficiente in termini di costi, adatto al business digitale moderno.

Evoluzione delle regole Sigma e collegamento alla conformità

Considero l’adozione accelerata delle regole Sigma per i compiti SIEM, SOC e Threat Hunting uno dei cambiamenti più positivi nell’industria della sicurezza. E mentre Sigma è già diventato uno standard de-facto per le query di caccia alle minacce, abbiamo avuto questa folle idea di applicarlo per stabilire pratiche di conformità continua. Nel caso in cui non abbiate mai sentito parlare di Sigma, è un linguaggio facile da comprendere, curva di apprendimento rapida, agnostico della piattaforma e open source. Esempi di regole e codice sorgente https://github.com/Neo23x0/sigma e tutorial per iniziare https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Se avete Elastic stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog: potete già ottenere valore dalle regole Sigma per la sicurezza e la caccia. Queste piattaforme sono probabilmente parte della vostra infosec / SOC e hanno tonnellate di dati utilizzabili per la conformità. Ed è ancora più probabile che abbiate uno stack Elastic, versione premium o community utilizzata in varie unità aziendali della vostra organizzazione che può avere dati per controlli di conformità automatizzati. Uno dei motivi importanti per l’evoluzione di Sigma e l’adozione globale è il suo supporto nativo di MITRE ATT&CK https://attack.mitre.org. Nel caso stiate leggendo questo articolo e non proveniate dall’infosec: MITRE ATT&CK è la blockchain della sicurezza informatica o la tavola periodica degli elementi della chimica. Quindi abbiamo uno standard open source, ampiamente adottato, più facile da imparare rispetto a qualsiasi linguaggio di query di qualsiasi SIEM e supporta il tagging con la metodologia ATT&CK per eseguire l’attribuzione TTP al volo. E se aggiungessimo tag pertinenti agli standard di conformità? Avere una query per il controllo automatico secondo CSC 8.2 o trovare sistemi che elaborano dati personali per il GDPR? Per Sigma questo è solo un altro tag, quindi tecnicamente questo è un passo logico successivo dell’evoluzione.

Come scrivere regole Sigma per la conformità

Non è un segreto che, sebbene personalmente sia un grande sostenitore di Sigma, io non scriva molte regole in questo momento. Per una guida dettagliata su COME FARE, ho colto Alex Yamposlkyi per una breve chiacchierata. Alex, essendo uno degli sviluppatori molto attivi delle regole Sigma, in termini di quantità di regole sviluppate secondo solo a Florian Roth, ha fornito alcuni approfondimenti molto pratici.

AB: “Alex, hai già sviluppato delle regole Sigma per la conformità?”
AY: “Sì, sono stati alcuni mesi impegnativi. Puoi trovare alcuni esempi nel repository ufficiale GitHub di Sigma: https://github.com/Neo23x0/sigma/tree/master/rules/compliance e nel SOC Prime Threat Detection Marketplace: https://tdm.socprime.com/?sigmaTypes[]=Compliance”

AB: “Ottimo. Segui un particolare algoritmo quando crei regole Sigma per la conformità?”
AY: “Suppongo di poter descrivere questo come un processo in 5 fasi:

1. Imparare il controllo CIS iniziale su https://www.cisecurity.org/controls/cis-controls-list/
2. Capire quale delle fonti di log nella vostra organizzazione può essere utilizzata per coprire i requisiti specifici del controllo.
3. Cercare nella vostra piattaforma SIEM gli eventi necessari.
4. Una volta scoperti gli eventi appropriati, decidere sulla logica della regola: avere una voce di log corrisponde a un evento che è positivo o negativo per la conformità. Chiediti: questo controllo della voce di log passa o fallisce?
5. Codificare l’evento risultante in una regola Sigma, rimuovendo qualsiasi parametro di ricerca specifico di una piattaforma per mantenerla agnostica al SIEM. Aggiungere tag dall’elemento #1 e programmare la ricerca automatizzata.”

AB: “Sembra una vittoria facile. Possiamo provare a estenderlo a una istruzione passo passo?”
AY: “Sì. Ecco una breve nota.

1. Seleziona il dominio specifico per il controllo che stai costruendo, per esempio, “Difese Malware” che corrisponde al dominio CSC #8.
2. Scava più a fondo nella descrizione di questo controllo, nel nostro caso 8.2 dice “Assicurarsi che il software anti-malware dell’organizzazione aggiorni il suo motore di scansione e database delle firme su base regolare.”
3. Pensa a cosa deve succedere nel sistema per passare o fallire questo controllo. Per l’8.2 significa che se il servizio AV è fermo o c’è un errore con il suo aggiornamento, falliamo il controllo. Pertanto, dobbiamo tracciare il registro eventi AV, specificamente per eventi di arresto del servizio ed errore di aggiornamento.
4. È abbastanza facile tracciare questo controllo particolare, dobbiamo installare un prodotto AV. Nel mio caso, questo era un prodotto Symantec integrato allo stack Elastic usando Logstash. Dopo aver ordinato i log per un po’, ho trovato l’evento che stavo cercando, responsabile per il download e il deployment degli aggiornamenti, che contiene le seguenti stringhe “Scaricato nuovo contenuto”, “Un aggiornamento per”.
5. Controllando quali campi contengono queste parole chiave, posso fare una semplice query Elastic: (event.name:(“Downloaded new content”)) OR (event.name:(“An update for”))
6. Ora prendiamo una decisione sulla logica della regola: avere l’evento è positivo o negativo. Nel nostro caso avere la voce di log è positivo e significa che il controllo è passato. Per automatizzare il processo, coderemo la regola Sigma e la applicheremo al meccanismo di ricerca salvata specifico della piattaforma. Nel mio caso, programmo un Watcher per eseguire su stack Elastic con intervallo di tempo specifico per il mio ambiente.
7. Scriviamo una regola Sigma
8. In questo esempio, potrei decidere di programmare un avviso quando gli eventi sono mancati per un certo periodo di tempo. Con altri esempi, la situazione può essere opposta e potremmo aver bisogno di un avviso quando scopriamo un evento.
9. Ora la nostra regola necessita di tutti i tag pertinenti, quindi andrò avanti e li aggiungerò in questo formatoTag:
   – CSC8.2
   – attack.impact
   – attack.t1489

Possiamo effettivamente mescolare tag per ATT&CK e conformità. Nell’esempio sopra “CSC8.2” è il numero di controllo corrispondente per il dominio CSC; “attack.persistence” è la tattica MITRE ATT&CK e “attack.t1053” è una tecnica specifica su cui si focalizza il controllo.

Un codice Sigma aggiornato avrà questo aspettoUna volta che pubblico le regole su Threat Detection Marketplace, ottengo anche meta-dati generati per le regole premendo il pulsante “Parse Sigma Content tags”.Nella lista “Tag” posso collegare le regole con qualsiasi standard di conformità come ISO, PCI, NIST CSF, ecc.

La nostra conversazione è andata avanti per un’altra ora con abbastanza materiale per un’intervista sul programma SOC Prime Threat Bounty. Fino ad allora, qualsiasi feedback su Sigma per la conformità è molto apprezzato.
E se desiderate uno sguardo in anteprima su come appare il risultato finale su stack Elastic, guardate il video su https://my.socprime.com/en/continuous-compliance

/Rimanete al sicuro