Segui 
In sintesi
- SIGMA è un formato di regole di rilevamento indipendente dalla piattaforma che consente ai team di condividere rilevamenti SIEM tra diversi fornitori.
- Per scrivere una regola, inizia con un’idea di rilevamento, scegli una fonte di log comune e mappala in SIGMA (min:
logsource+detection). logsourcespecifica a quali log si applica la regola in modo che i traduttori possano indirizzare il corretto backend/tipo di dati.detectionè selezioni (corrispondenza campo/valore + modificatori) più una condizione (logica booleana), opzionalmente con correlazione/intervallo di tempo.- Usa le convenzioni dei campi SIGMA (rispettando le maiuscole), traduci/testa la regola, poi condividi e migliora basandoti sui feedback.
Questo post discute SIGMA come linguaggio di rilevamento, tratta i componenti più critici delle regole SIGMA (logsource e rilevamento), la tassonomia SIGMA, il test delle regole SIGMA, e prepara generalmente gli analisti che sono nuovi a SIGMA a scrivere le loro prime regole. Fornisce anche una breve discussione sull’ingegneria del rilevamento con SIGMA in merito al rumore, idee, fonti di log, ecc.
Il caso per le regole SIGMA
In passato, i rilevamenti SIEM esistevano in silos specifici di fornitori/piattaforme. I partner che desideravano condividere contenuti di rilevamento dovevano spesso tradurre una query da un fornitore a un altro. Questo non è sostenibile, la comunità di sicurezza informatica difensiva deve migliorare come condividiamo i rilevamenti per tenere il passo con i nostri avversari sempre in evoluzione.
Molto simile a YARA o Snort Rules, SIGMA è un altro strumento per la condivisione aperta del rilevamento, ad eccezione che è focalizzato su SIEM invece che su file o traffico di rete. SIGMA permette ai difensori di condividere rilevamenti (alert, casi d’uso) in un linguaggio comune.
Rilasciato per la prima volta nel 2017 da Florian Roth e Thomas Patzke, SIGMA sta aprendo la strada per una ricerca indipendente dalla piattaforma. Con SIGMA, i difensori sono liberati dal linguaggio di rilevamento specifico del fornitore e della piattaforma e possono sfruttare la potenza della comunità per rispondere tempestivamente a minacce critiche e nuove tattiche avversarie.
Ci sono molte ragioni per usare SIGMA:
- Ricercatori e team di intelligence che identificano nuovi comportamenti avversari e vogliono un modo agnostico di condividere i rilevamenti
- MSSP / MDR responsabili di più soluzioni SIEM / EDR / Log Analytics e tassonomie/schemi di dati (ECS, CEF, CIM, ecc.)
- Evita il lock-in del fornitore, definendo le regole in un SIGMA possiamo spostarci più facilmente tra le piattaforme.
- Ricercatori nel campo della sicurezza offensiva che desiderano creare rilevamenti basati sulla loro ricerca
Nota: In questo blog SIEM è usato per descrivere qualsiasi piattaforma usata per raccogliere e cercare log. Accetto che molte delle piattaforme elencate potrebbero non rispecchiare la tua definizione di “SIEM”. Tuttavia, usare i termini “piattaforma” o “piattaforma di log” è troppo ambiguo.
SeguiCreazione di Regole SIGMA
Scrivere regole SIGMA richiede una conoscenza di base dello schema e della tassonomia SIGMA, avere un’idea, adattare quell’idea a SIGMA, testare, condividere e possibilmente mantenere la regola.
Contesto e Background Raccomandati
Nonostante la lunghezza di questo blog, grazie a YAML e alla lungimiranza dei creatori, SIGMA è facile da comprendere e scrivere. Alla SOC Prime ci piace dire “chiunque può imparare SIGMA”. L’arte dell’ingegneria del rilevamento è dove le cose possono diventare più complicate.
Ci sono molte altre risorse come il wiki ufficiale e alcune guide scritte da esperti di SIGMA (elencate di seguito). Ci sono alcune trappole come corretto utilizzo dei caratteri jolly or nomi di campi errati che possono causare regole interrotte e molte di queste sono affrontate in queste risorse.
Se sei un ricercatore che cerca di entrare in SIGMA, il Programma Threat Bounty di SOC Prime è una grande opportunità per iniziare e guadagnare un po’ di denaro. Le regole inviate passano attraverso un processo di revisione accurato dove possiamo guidarti e aiutarti a capire gli errori e crescere come analista.
Letture Consigliate:
- Come Scrivere Regole SIGMA, Florian Roth 2018
- Una Guida alle Fonti di Log Generiche, Thomas Patzke 2019
Visioni Consigliate:
Tipi di Rilevamenti che le Regole SIGMA Possono Espressare
Oggi esistono attualmente due tipi base di regole:
- Regole SIGMA basate su corrispondenze, ampiamente supportate, più facili da scrivere
- Regole SIGMA basate su corrispondenze e semplici correlazioni, supporto limitato, meno facili da scrivere
Nota: Esistono anche regole SIGMA multi-yaml, tuttavia queste sono generalmente cadute in disuso per regole specifiche per fonti di log. Il Team SOC Prime generalmente non crea regole multi-yaml perché aggiungono complessità non necessaria alla manutenzione e al dispiegamento delle regole. Qualcuno può creare una regola SIGMA multi-yaml se riesce a creare due regole SIGMA.
Creiamo una Semplice Regola SIGMA!
Un’idea (e alcuni pensieri sull’ingegneria del rilevamento con SIGMA)
Gli utenti e gli amministratori spesso conservano password sensibili in documenti in chiaro come file di testo, excel, word, ecc. Temo che gli avversari possano identificare questi file prima di me in un ambiente. Vogliamo istruire i nostri utenti su come archiviare correttamente le password prima che vengano scoperte da un hacker criminale.
Per molte regole SIGMA è a beneficio dell’autore astrarre l’idea e ampliare il target ‘ragionevolmente’. Per idee come questa possiamo fare ipotesi educate su quale comportamento may sembra, non solo quello che abbiamo osservato. Ad esempio, possiamo fare ipotesi educate su termini e estensioni aggiuntivi che gli utenti potrebbero utilizzare per archiviare le password in chiaro.
L’idea di ‘ampliare’ una regola è controintuitiva per molti istinti degli analisti. Eliminare tutti i ‘falsi positivi’ non è necessariamente l’obiettivo dell’autore originale quando una regola verrà consumata in ambienti sconosciuti e non familiari. Possiamo lasciare che i fornitori di EDR e Anti-Virus si preoccupino di creare rilevamenti che non possono avere falsi positivi. Con le regole SIGMA possono essere testate in ambienti e facilmente regolate.
SIGMA è facilmente comprensibile, testabile e adattabile. Se un termine come ‘dettagli’ è troppo rumoroso per un ambiente, la persona che implementa la regola dovrebbe sentirsi autorizzata a adattare la regola. Distribuire tutte le regole in una volta senza testarle è una ricetta per il disastro. Spegnere le regole invece di digerirle e adattarne le intenzioni per un ambiente porterà una struttura a perdere contenuti di rilevamento solidi.
Mi piace fare l’esempio di psexec. In alcuni ambienti, psexec è completamente normale e lo status-quo per gli amministratori che amministrano da remoto gli host. In altri ambienti, psexec è (probabilmente giustamente) non approvato, bloccato e un reato sanzionabile per gli amministratori che lo usano. Quindi, è una regola SIGMA per rilevare l’uso di psexec ‘rumorosa’ o semplicemente migliore per alcuni ambienti rispetto ad altri. Se distribuisci contenuti senza testarli, regolare il rumore sarà sempre un problema. Solo quelle regole identificate come “critiche” sono pensate per essere sicure da usare senza test.
Tornando a creare la nostra regola SIGMA per l’esposizione delle password… possiamo espandere l’idea includendo ulteriori nomi di file come:
- pw
- psw
- pass
- password
- passwords
- accounts
- account
- info
Creato con software come:
- Notepad
- Notepad++
- Wordpad
- Applicazioni Office
Una fonte di dati / Una fonte di log
Una volta che abbiamo un’idea, avremo bisogno di una fonte di log. SIGMA supporta any teoricamente la fonte di log, tuttavia dovremmo identificare una fonte di log che la maggior parte delle persone ha. Ad esempio, potremmo essere in grado di scrivere una regola per una fonte di log di Data Loss Prevention ma la Data Loss Prevention è raramente analizzata e inserita nei SIEM, e l’industria non ha un preferito chiaro. Quindi, possiamo creare una regola valida, ma non sarà facilmente adottata.
Per le regole dei punti endpoint di Windows, Sysmon è un ottimo punto di inizio. Sysmon è comunemente distribuito in ambienti, e molte fonti di log forniscono dati sinonimi (EDR, ecc.). Con Sysmon ci sono due opzioni principali, creazione del processo (process_creation in SIGMA) e creazione del file (file_event in SIGMA).
Costruiremo il nostro rilevamento sulla creazione del processo poiché è più ampiamente adottato, assicurando così che la nostra regola sia il più utile possibile. La creazione del processo è una grande fonte di log da cui apprendere ed è una delle più utili/fonti di log più popolari utilizzate nei rilevamenti degli endpoint.
Nota: Spesso le idee provengono direttamente dalle fonti di dati stesse. Esaminando i tipi di dati disponibili nel tuo SIEM / Lab una persona può facilmente identificare regole SIGMA degne di essere scritte. Possiamo anche usare altre fonti come la documentazione del fornitore.
Con gli eventi di creazione del processo di sysmon (ID evento 1), un utente che accede a un file contenente password può contenere questi campi interessanti:
Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt
Adattare l’idea di rilevamento a SIGMA
Ora che abbiamo un’idea e una fonte di dati con cui lavorare possiamo iniziare a costruire la nostra regola.
Questo non è documentato ma i veri componenti minimi componenti richiesti per tradurre una regola sono solo sorgentelog & rilevamento (per alcuni backend come Splunk, solo il rilevamento è sufficiente). Tutto il resto è ‘solo’ metadata per aiutare il consumatore della regola SIGMA. Quando inizi è nel tuo interesse iniziare con questi campi minimi, confermare che la tua logica funzioni e poi aggiungere ulteriori campi e dati SIGMA. Se vuoi pubblicare la tua regola nel repository SIGMA pubblico vale la pena controllare le precedenti sottomissioni e emulare il loro formato.
Una regola SIGMA di base con componenti minimi per un potenziale esposto di password:
title: Potential Password Exposure (via cmdline)
author: Adam Swan
tags:
- attack.t1552.001
- attack.credential_access
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith:
- '\notepad.exe'
- '\word.exe'
- '\excel.exe'
- '\wordpad.exe'
- '\notepad++.exe'
CommandLine|contains:
- 'pass' #pass will match on password, including password is redundant
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'account' #accounts,
- 'secret'
- 'details' #I included plural details based on experience
condition: selection
Componente di logsource
The sorgentelog componente aiuta il traduttore di backend SIGMA (SIGMAC) a sapere su che tipo di dati dovrebbe essere attivata la regola. Consente al creatore della regola di creare regole più generiche. Ad esempio, con sorgentelog essendo “prodotto: windows, categoria: process_creation” non abbiamo bisogno di specificare ID eventi (Sysmon 1, Windows 4688, ProcessRollup, ecc). Il consumatore della regola può specificare quali ID eventi, indici, ecc. vogliono essere associati alle fonti di log nella Configurazione SIGMA. Senza specificare indici, ID eventi, ecc. le regole saranno probabilmente inutilmente costose (per le prestazioni) per il consumatore.
Inoltre, spesso la telemetria può contenere campi simili ma implicare comportamenti completamente diversi. Ad esempio, gli eventi di connessione di rete Sysmon (Evento Id 3) e creazione del processo (Evento ID 1) condividono il campo Immagine campo. L’esistenza di explorer.exe nel campo di un evento di connessione di rete Sysmon è completamente diversa dall’esistenza di explorer.exe in un evento di creazione del processo. Fornendo il corretto componente logsource forniamo un contesto inestimabile al rilevamento. Immagine field of a Sysmon network connection event is completely different from the existence of explorer.exe in a process creation event. By providing the proper logsource component we provide invaluable context to the detection.
Componente rilevamento
Il componente rilevamento è dove l’autore definisce i suoi criteri di rilevamento. Questo include almeno un componente di selezione sezione e un componente di condizione condizione. C’è una componente opzionale di intervallo di tempo intervallo di tempo il quale è richiesto per regole basate su correlazione.
Sotto componente di selezione:
- Generalmente, questo prenderà la forma di Campo A contiene/comincia con/finisce con/uguale a Valore B. Ovviamente, come osservato nella regola di esempio sopra, se un autore necessita può espandere e includere logica come Campo A contiene/comincia con/finisce con/uguale a Valori X, Y, o Z. Questa logica è sempre sensibile alla maiuscola e minuscola.
- Ci sono ‘modificatori’ più avanzati che incrementano la complessità della regola o permettono agli autori di essere più precisi. Ad esempio, le espressioni regolari sono gestite attraverso l’operatore re e permettono agli autori di fare cose come scrivere query sensibili alla maiuscola e minuscola. Per scopi di compatibilità è meglio attenersi solo agli operatori di espressioni regolari di base . ? + * | { } [ ] () “ .
- Le selezioni sono chiamate con un nome (es. selezione, selezione2, selezione3, filtro). Le selezioni possono essere chiamate (quasi) come vuoi tu. Spesso una variazione di selezione è usata, ma si può altrettanto facilmente chiamare la propria selezione banana e la regola funzionerebbe comunque. Generalmente, il termine filtro è usato per selezioni che verranno escluse (ad es. selezione E NON filtro).
Sotto componente di condizione:
- Il componente condizione contiene logica booleana (AND, OR, NOT) definendo come ciascuna selezione dovrebbe essere inclusa nella query finale.
- E.G. (selezione_a O selezione_b) E NON filtro
Componenti di condizione con correlazione:
Ci sono due tipi di correlazioni supportate dai backends attualmente. Ci sono altre correlazioni supportate dallo schema SIGMA.. ma ancora non da backends disponibili.
Count() per Y:
Conta le istanze uniche del valore del campo Y e confrontale (maggiore di, minore di) con un numero statico.
Esempio: Count() per src_ip > 2
Count(X) per Y:
Conta le istanze uniche del valore del campo X per valore di Y e confronta (maggiore di, minore di) il conteggio di X con un numero statico.
Esempio: Count(EventID) per src_ip > 2
Casi d’Uso Comuni di Correlazione:
Count() by src_ip > 10 | Count unique matching events by the source IP. |
Count() by dst_ip > 10 | Count unique matching events by the destination IP |
Count(EventID) by ComputerName | This will let you search for unique instances of eventid. For instance, if you want to chain sysmon event ids 1 (process creation) AND event id 5. e.g. a process is created and terminated in less than 1 min. |
Sotto Componente Intervallo di Tempo:
- The intervallo di tempo componente è usato in congiunzione con condizioni che includono una correlazione. Molti backends ignorano l’intervallo di tempo, tuttavia, è generalmente sempre incluso e richiesto nella maggior parte dei repository incluso quello di SOC Prime.
Esempi Completi Usando Splunk:
- Ecco alcuni esempi di SIGMA e delle loro traduzioni per Splunk. Se non sei familiare con Splunk, gli asterischi sono un carattere jolly quindi un termine circondato da asterischi (es. *termine*) è ‘contiene’, un termine con un asterisco principale (es. *termine) è ‘finisce con’, un termine con un asterisco finale è ‘finisce con’ (es. termine*).
SIGMA detection component | Splunk Translation (Asterisk is a wildcard) |
detection: selection: fieldX: 'suspicious' condition: selection | fieldX="suspicious" |
detection: selection: fieldY|contains: - 'suspicious' - 'malicious' - 'pernicious' condition: selection | (fieldY="*suspicious*" OR fieldY="*malicious*" OR fieldY="*pernicious*") |
detection: selection: - fieldX: 'icious' - fieldX: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern")) |
detection: selection: - FieldX|endswith: 'icious' - FieldX|startswith: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="*icious" AND (FieldX="susp*" OR FieldX="mal*" OR FieldX="pern*")) |
detection: selection: FieldX|endswith: 'icious' filter: FieldX|startswith: - 'del' - 'ausp' condition: selection AND NOT filter | (FieldX="*icious" AND NOT ((FieldX="del*" OR FieldX="ausp*"))) |
detection: selection: FieldX: 'suspicious' timeframe: 1m condition: selection | count by src_ip > 3 | FieldX="suspicious" | eventstats count as val by src_ip| search val > 3 #notice splunk ignores the timeframe value, the value must be set at search by the user |
detection: selection: FieldX: 'suspicious' condition: selection | count(ComputerName) by src_ip > 3 | FieldX="suspicious" | eventstats dc(ComputerName) as val by src_ip | search val > 3 |
Domande di Tassonomia (es. quali nomi di campo usare)
Teoricamente puoi usare qualsiasi nome di campo desideri, purché qualcuno sia disposto a dedicare il tempo per scrivere una Configurazione SIGMA per tradurre dai tuoi campi.. ai loro.
Nota: I nomi dei campi sono sensibili alle maiuscole! CommandLine and commandline sono due valori diversi. CommandLine fa parte della tassonomia esistente, commandline non lo è.
Detto ciò, è meglio usare i nomi dei campi documentati da SIGMA. Ci sono tre posti in cui il repository pubblico SIGMA documenta la tassonomia.
Come regola generale usiamo i nomi dei campi SIGMA specificati nel wiki per le categorie
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- Il wiki rivelerà ai lettori che SIGMA usa
— Campi SYSMON per regole endpoint
— Formato file log esteso W3C per regole server web e proxy
— I campi per firewall, antivirus
Seguiti dai nomi dei campi SIGMA specificati nelle regole esistenti e nei file di configurazione SIGMA
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Davvero la documentazione ufficiale per i campi. Gli utenti possono creare/modificare questi come richiesto quando traducono le regole.
- https://github.com/SigmaHQ/sigma/tree/master/rules
Infine, se non esiste alcun config o regole, utilizziamo i nomi dei campi originali dalla fonte di log originale. Se i nomi dei campi provengono da valori annidati (es. userIdentity annidato sotto accountId in aws cloudtrail) utilizziamo un punto per indicare che il campo è annidato poiché questo è relativamente coerente tra diversi SIEM (es. userIdentity -> accountId diventa userIdentity.accountId).
Testare le Regole SIGMA
Testare le regole SIGMA è semplice. Spesso le persone sono in grado anche di sottoporre contenuti senza testarli direttamente. La maggior parte dei ricercatori pubblici non ha accesso a ambienti diversi per testare le regole contro “l’insieme di tutti i SIEM”. Invece, si può fare affidamento su feedback pubblici, feedback da parti fidati, ecc. Anche Florian Roth, un co-creatore di SIGMA invia regolarmente regole al pubblico per ricevere feedback tramite il suo Twitter. Ho anche visto persone pubblicare direttamente sui loro blog personali e LinkedIn, ecc. Se pensi di avere una buona regola da condividere, mettila là fuori, fidati di me se è sbagliata (o no) le persone su internet te lo faranno sapere! Non prenderti troppo sul serio e sii pronto a fare cambiamenti e imparare qualcosa.
Ci sono alcuni passaggi base che puoi eseguire:
- Assicurati che la regola si traduca (uncoder o utilizzando SIGMAC)
- Controllo della sanità mentale (ad es. assicurandoti che la regola soddisfi la tua aspettativa originale, segua la tassonomia corretta, ecc) – vedi insidie: https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- Controllare la regola in un ambiente di laboratorio
- Condividere la regola ampiamente per i test / condividere la regola con il Team SOC Prime tramite il Programma Threat Bounty
Nota: Da una prospettiva dell’autore della regola, generalmente non dovresti preoccuparti delle implementazioni dei backend delle regole. Spetta agli autori del backend SIGMA, e persone come SOC Prime assicurare che le traduzioni soddisfino l’intenzione originale di una regola valida. Se viene identificato un bug, vale sempre la pena di presentare un problema a GitHub.
Informazioni su SOC Prime
- Fondò l’industria del Detection-as-Code nel 2015
- Partner con Fortune 100 + MDR globali
- Copertura dell’intera pipeline dal rilevamento alla simulazione
- Ricerca magica della minaccia invece di filtri
- 650.000+ regole di rilevamento
- Nuove minacce giornaliere
- ETL Line-Speed Detection
- Shift-Left Detection, Fatto Correttamente
FAQ
Cos’è una regola SIGMA?
Una regola SIGMA è un rilevamento neutrale rispetto al fornitore scritto in YAML che descrive attività sospette nei log. Puoi tradurla in query per molti SIEM e strumenti di log.
Quali sono le due parti indispensabili di una regola SIGMA?
Includi logsource e rilevamento. logsource definisce il tipo di log (come la creazione di processi di Windows), e il rilevamento contiene la logica di corrispondenza e la condizione.
Come scrivi una condizione di rilevamento SIGMA?
Crea una o più “selezioni” che corrispondono a campi e valori, quindi combinaci in condizione usando AND/OR/NOT. Questo ti permette di esprimere corrispondenze semplici e logica più complessa.
Come scegli una buona fonte di log per la tua prima regola SIGMA?
Scegli qualcosa di ampiamente distribuito in modo che altri possano usarla. Per rilevamenti su endpoint Windows, Sysmon è una scelta comune, e la creazione di processi (process_creation) è un punto di partenza pratico.
Come testare una regola SIGMA prima di utilizzarla in produzione?
Traduce su una piattaforma target (ad esempio con un converter SIGMA), eseguila su dati reali o di laboratorio, e adattala per ridurre i falsi positivi prima di distribuirla ampiamente.
