Cosa Sono le Regole SIGMA: Guida per Principianti
Indice:
Questo post del blog sostiene l’uso di SIGMA come linguaggio di rilevamento, copre i componenti più critici delle regole SIGMA (logsource e rilevazione), la tassonomia SIGMA, il test delle Regole SIGMA e prepara generalmente gli analisti che sono nuovi a SIGMA a scrivere le loro prime regole. Viene inoltre fornita una breve discussione sull’ingegneria del rilevamento con SIGMA riguardo il rumore, le idee, le fonti di log, ecc.
Il Caso delle Regole SIGMA
In passato, i rilevamenti SIEM esistevano in silos specifici per fornitore/piattaforma. I partner che desideravano condividere contenuti di rilevamento spesso dovevano tradurre una query da un fornitore a un altro. Questo non è sostenibile, la comunità di cybersicurezza difensiva deve migliorare il modo in cui condividiamo i rilevamenti per tenere il passo con i nostri avversari in continua evoluzione.
Proprio come YARA o le regole Snort, SIGMA è un altro strumento per la condivisione aperta del rilevamento, solo che è focalizzato su SIEM anziché su file o traffico di rete. SIGMA consente ai difensori di condividere rilevamenti (avvisi, casi d’uso) in un linguaggio comune.
Pubblicato per la prima volta nel 2017 da Florian Roth e Thomas Patzke, SIGMA sta aprendo la strada a una ricerca agnostica alla piattaforma. Con SIGMA, i difensori sono liberati dal linguaggio di rilevamento specifico per fornitore e dalla piattaforma e possono sfruttare la potenza della comunità per rispondere tempestivamente a minacce critiche e nuove tecniche 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 / Analitica Log e tassonomie/schemi di dati (ECS, CEF, CIM, ecc.)
- Evitare il vendor-lock, definendo regole in SIGMA possiamo muoverci più facilmente tra piattaforme.
- Ricercatori nel settore della sicurezza offensiva che desiderano creare rilevamenti basati sulle loro ricerche
Nota: In questo blog SIEM è usato per descrivere qualsiasi piattaforma utilizzata per raccogliere e cercare sui log. Accetto che molte delle piattaforme elencate potrebbero non rientrare nella tua definizione di “SIEM”. Tuttavia, usare i termini “piattaforma” o “piattaforma log” è troppo ambiguo.
Creazione di Regole SIGMA
Scrivere regole SIGMA richiede una conoscenza di base sullo schema e la tassonomia di SIGMA, avere un’idea, adattare quella idea a SIGMA, testarla, condividerla e potenzialmente mantenere la regola.
Sfondo e contesto consigliati
Nonostante la lunghezza di questo blog, grazie a YAML e alla lungimiranza dei creatori, SIGMA è facile da comprendere e scrivere. A 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 SIGMA (elencate di seguito). Ci sono certe trappole come gestione corretta dei caratteri jolly or nomi di campi errati che possono causare regole rotte e molte di queste sono affrontate in queste risorse.
Se sei un ricercatore che vuole 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 approfondito in cui possiamo guidarti e aiutarti a capire gli errori e crescere come analista.
Letture Consigliate:
- Come Scrivere Regole SIGMA, Florian Roth 2018
- Una Guida a Fonti Log Generiche, Thomas Patzke 2019
Visioni Consigliate:
Tipi di Rilevamenti Che le Regole SIGMA Possono Esprimere
Oggi ci sono attualmente due tipi base di regole:
- Regole SIGMA basate sul matching, ampiamente supportate, più facili da scrivere
- Regole SIGMA basate sul matching e semplici correlazioni, supporto limitato, meno facili da scrivere
Nota: Ci sono anche regole SIGMA multi-yaml, tuttavia queste sono generalmente cadute in disuso per le regole specifiche per fonte di log. Il team di SOC Prime generalmente non crea regole multi-yaml perché aggiungono complessità inutile alla manutenzione e distribuzione 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 alcune riflessioni sull’ingegneria del rilevamento con SIGMA)
Gli utenti e gli amministratori spesso conservano password sensibili in documenti di testo chiaro come file di testo, excel, word, ecc. Sono preoccupato che gli avversari possano identificare questi file prima di me in un ambiente. Vogliamo istruire i nostri utenti su come memorizzare correttamente le password prima che vengano scoperte da un hacker criminale.
Per molte regole SIGMA è vantaggioso per l’autore astrarre l’idea e ampliare il target ‘ragionevolmente’. Per idee come questa possiamo fare ipotesi istruite su quale potrebbe essere il comportamento may apparire, non solo quello che abbiamo osservato. Ad esempio, potremmo fare ipotesi istruite su termini ed estensioni aggiuntivi che gli utenti potrebbero usare per memorizzare 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 possano avere falsi positivi. Con le regole SIGMA si può testare negli ambienti e regolarle facilmente.
SIGMA è facilmente comprensibile, testabile e regolabile. Se un termine come ‘dettagli’ è troppo rumoroso per un ambiente, la persona che implementa la regola dovrebbe sentirsi autorizzata a regolare la regola. Distribuire tutte le regole contemporaneamente senza testare è una ricetta per il disastro. Disattivare le regole invece di comprendere e regolare le loro intenzioni per un ambiente farà sì che il negozio manchi contenuti di rilevamento solidi.
Mi piace fare l’esempio di psexec. In alcuni ambienti, psexec è completamente normale e lo status quo per gli amministratori per gestire a distanza gli host. In altri ambienti, psexec è (probabilmente giustamente) non approvato, bloccato e un’offesa perseguibile per gli amministratori da usare. Quindi, è una regola SIGMA per rilevare qualsiasi utilizzo di psexec ‘rumorosa’ o semplicemente migliore per alcuni ambienti rispetto ad altri. Se distribuisci contenuti senza testare, il rumore di messa a punto sarà sempre un problema. Solo quelle regole identificate come “critiche” sono pensate per essere sicure da usare senza test.
Tornando alla creazione della nostra regola SIGMA di esposizione delle password… possiamo espandere l’idea per includere nomi di file aggiuntivi come:
- pw
- psw
- pass
- password
- passwords
- accounts
- account
- info
Creato con software come:
- Notepad
- Notepad++
- Wordpad
- Applicazioni Office
Una fonte dati / Una fonte di log
Una volta che abbiamo un’idea, avremo bisogno di una fonte log. SIGMA supporta any la fonte log teoricamente, tuttavia dovremmo identificare una fonte log che la maggior parte delle persone ha. Ad esempio, potremmo essere in grado di scrivere una regola per una fonte log di prevenzione perdita dati ma la prevenzione perdita dati è raramente analizzata e ingerita nei SIEM, e l’industria non ha un chiaro favorito. Quindi, possiamo creare una regola valida, ma non sarà facilmente adottata.
Per le regole sugli endpoint Windows, Sysmon è un ottimo punto di partenza. Sysmon è comunemente distribuito negli ambienti e molte fonti log forniscono dati sinonimi (EDR, ecc.). Con Sysmon ci sono due opzioni principali, creazione processo (process_creation in SIGMA) e creazione file (file_event in SIGMA).
Costruiremo il nostro rilevamento sulla base della creazione di processi in quanto è più ampiamente adottata, garantendo così che la nostra regola sia il più utile possibile. La creazione di processi è una grande fonte di log da cui imparare ed è una delle fonti log più utili / popolari utilizzate nei rilevamenti sugli endpoint.
Nota: Spesso le idee provengono direttamente dalle fonti dati stesse. Esaminando i tipi di dati disponibili nel tuo SIEM / Lab si possono facilmente identificare regole SIGMA degne di essere scritte. Possiamo anche usare altre fonti come la documentazione del fornitore.
Con eventi di creazione processo di sysmon (Event ID 1), un utente che accede a un file contenente password può contenere questi campi interessanti:
Immagine: C:WindowsSystem32notepad.exe
CommandLine: "C:WindowsSystem32NOTEPAD.EXE" C:UsersJohnDesktoppassword.txt
Adattare l’idea di rilevamento a SIGMA
Ora che abbiamo un’idea e una fonte dati con cui lavorare, possiamo iniziare a costruire la nostra regola.
Questo non è documentato ma i veri componenti minimali richiesti per tradurre una regola sono solo logsource e rilevazione (per alcuni backend come Splunk, solo la rilevazione è sufficiente). Tutto il resto è ‘solo’ metadati 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 desideri pubblicare la tua regola nel repository pubblico di SIGMA vale la pena controllare le precedenti sottomissioni ed emulare il loro formato.
Una regola SIGMA di base con componenti minimi per un’esposizione potenziale di password:
titolo: Esposizione Potenziale di Password (via cmdline)
autore: Adam Swan
tag:
- attack.t1552.001
- attack.credential_access
logsource:
prodotto: windows
categoria: process_creation
rilevazione:
selezione:
Immagine|endswith:
- 'notepad.exe'
- 'word.exe'
- 'excel.exe'
- 'wordpad.exe'
- 'notepad++.exe'
CommandLine|contains:
- 'pass' #pass si abbinerà a password, incluso password è ridondante
- 'pwd'
- 'pw.' #pw.txt, ecc.
- 'account' #accounts,
- 'secret'
- 'details' #Ho incluso i dettagli plurali in base all'esperienza
condizione: selezione
Componente logsource
The logsource aiuta il traduttore backend di SIGMA (SIGMAC) a sapere su che tipo di dati la regola dovrebbe essere applicata. Consente al creatore della regola di creare regole più generiche. Ad esempio, con logsource essendo “prodotto: windows, categoria: process_creation” non abbiamo bisogno di specificare gli EventIDs (Sysmon 1, Windows 4688, ProcessRollup, ecc). Il consumatore della regola può specificare quali id eventi, indici, ecc. vogliono essere associati alle sorgenti log nel Config SIGMA. Senza specificare indici, id eventi, ecc. le regole saranno probabilmente inutilmente costose (prestazione) per il consumatore.
Inoltre, spesso la telemetria può contenere campi simili ma implicare comportamenti completamente diversi. Ad esempio, gli eventi di connessione di rete di Sysmon (Event Id 3) e la creazione di processi (Event ID 1) condividono il campo Image . L’esistenza di explorer.exe nel campo Image di un evento di connessione di rete Sysmon è completamente diversa dall’esistenza di explorer.exe in un evento di creazione processo. Fornendo il corretto componente logsource forniamo un contesto inestimabile al rilevamento.
Componente di rilevazione
Il componente di rilevazione è dove l’autore definisce i suoi criteri di rilevazione. Questo include almeno un componente di selezione e un componente di condizione. C’è un componente opzionale di componente timeframe è usato in congiunzione con condizioni che includono una correlazione. Molti backend ignorano il timeframe, tuttavia, è generalmente sempre incluso e richiesto di essere incluso nella maggior parte dei repository inclusi quelli di SOC Prime. che è necessario per regole basate su correlazione.
Sotto componente di selezione:
Generalmente, questo prenderà la forma Campo A contiene/inizia con/termina con/uguale Valore B. Ovviamente, come osservato nella regola di esempio sopra, se un autore ha bisogno può espandere e includere logiche come Campo A contiene/inizia con/termina con/uguale Valori X, Y o Z. Questa logica è sempre insensibile al maiuscolo/minuscolo.
Ci sono ‘modificatori’ più avanzati che aumentano la complessità della regola, o consentono agli autori di essere più precisi. Ad esempio, le espressioni regolari sono gestite attraverso l’operatore e consentono agli autori di fare cose come scrivere query sensibili al maiuscolo/minuscolo. Per scopi di compatibilità è meglio attenersi solo agli operatori di espressioni regolari di base. re . ? + * | { } [ ] () ” . Le selezioni sono denominate (ad es. selezione, selezione2, selezione3, filtro). Le selezioni possono essere nominate (quasi) come vuoi. Spesso si usa una variazione di
Selections are named (e.g. selection, selection2, selection3, filter). Selections can be named (almost) anything you want. Often a variation of selezione , ma si può altrettanto facilmente nominare la selezione banana e la regola funzionerebbe comunque. Generalmente, il termine filtro è usato per selezioni che saranno escluse (es. selezione E NON filtro).
Sotto componente della condizione:
Il componente della condizione contiene logica booleana (AND, OR, NOT) che definisce come ogni selezione dovrebbe essere inclusa nella query finale.
E.G. (selezione_a O selezione_b) E NON filtro
Componente di condizione con correlazione:
Ci sono due tipi di correlazioni supportate dai backend oggi. Ci sono altre correlazioni supportate dallo schema SIGMA… ma non ancora dai backend disponibili.
Count() per Y:
Conta le istanze uniche del valore del campo Y e confronta (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 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 Timeframe:
The componente timeframe è usato in congiunzione con condizioni che includono una correlazione. Molti backend ignorano il timeframe, tuttavia, è generalmente sempre incluso e richiesto di essere incluso nella maggior parte dei repository inclusi quelli di SOC Prime. component is used in conjunction with conditions that include a correlation. Many backends ignore the timeframe, however, it is generally always included and required to be included in most repositories including SOC Prime’s.
Esempi Completi Usando Splunk:
Ecco alcuni esempi di SIGMA e le loro traduzioni per Splunk. Se non hai familiarità con Splunk, gli asterischi sono un carattere jolly quindi un termine circondato da asterischi (ad es. *term*) è ‘contiene’, un termine con un asterisco iniziale (ad es. *term) è endswith, un termine con un asterisco finale è ‘startwith’ (ad es. term*).
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 sulla Tassonomia (ad es. quali nomi di campi usare)
Teoricamente puoi usare qualsiasi nome di campo desideri, purché qualcuno sia disposto a dedicare tempo a scrivere un Config SIGMA per tradurre dai tuoi campi… ai loro.
Nota: I nomi dei campi sono sensibili al maiuscolo/minuscolo! CommandLine and commandline sono due valori differenti. CommandLine è parte della tassonomia esistente, commandline non lo è.
Detto ciò, è meglio usare i nomi di campo documentati da SIGMA. Ci sono tre posti dove il repository pubblico di SIGMA documenta la tassonomia.
- Come regola generale usiamo i nomi di campo SIGMA specificati nel wiki per categorie
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- Il wiki rivelerà ai lettori che SIGMA usa i campi SYSMON per le regole sugli endpoint
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- Formato Log File Esteso W3C per le regole di server web e proxy
- I campi per firewall, antivirus
- Seguiti dai nomi di campo SIGMA specificati nelle regole esistenti e nei file di configurazione SIGMA
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Veramente la documentazione ufficiale per i campi. Gli utenti possono creare/modificare questi come necessario quando traducono le regole.
- https://github.com/SigmaHQ/sigma/tree/master/rules
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
Infine, se non esistono config o regole, usiamo i nomi di campo originali dalla fonte di log originaria. Se i nomi dei campi provengono da valori annidati (ad es. userIdentity annidato sotto accountId in aws cloudtrail) usiamo un punto per indicare che il campo è annidato, poiché questo è relativamente coerente tra i diversi SIEMS (ad es. userIdentity -> accountId diventa userIdentity.accountId).
Testare le Regole SIGMA
Testare le regole SIGMA è semplice. Spesso le persone sono persino in grado di inviare contenuti senza testarli direttamente. La maggior parte dei ricercatori pubblici non ha accesso a ambienti diversificati per testare le regole contro ‘tutti i SIEM’. Invece, si può fare affidamento su feedback pubblico, feedback da parti fidate, ecc. Incluso Florian Roth, un co-creatore di SIGMA, regolarmente mette delle regole nel pubblico per feedback tramite il suo Twitter. Ho visto anche persone pubblicare direttamente sui loro blog personali e LinkedIn, ecc. Se pensi di avere una buona regola da condividere, mettila in campo, fidati di me se è sbagliata (o no) le persone adorabili su Internet te lo faranno sapere! Non prenderti troppo sul serio e preparati a fare modifiche e imparare qualcosa.
Ci sono alcuni passaggi di base che puoi prendere:
- Assicurati che la regola sia tradotta (uncoder o usando SIGMAC)
- Controllo della sanità mentale (ad es. assicurarsi che la regola soddisfi la tua aspettativa originale, segua la tassonomia corretta, ecc.) – guarda le insidie:Controllare la regola in un ambiente di laboratorio Controllare la regola in un ambiente di laboratorio
- Condivisione ampia della regola per test/condivisione della regola con il Team di SOC Prime tramite il Threat Bounty Program
- Da una prospettiva di autore di regole, generalmente non dovresti preoccuparti delle implementazioni backend delle regole. È compito degli autori dei backend SIGMA, e di persone come SOC Prime, garantire che le traduzioni soddisfino l’intento originale di una regola valida. Se viene identificato un bug, vale sempre la pena presentare un problema su GitHub.
Nota: From a rule author perspective, generally you should not worry about the backend implementations of rules. It is up to the SIGMA backend authors, and folks like SOC Prime to ensure that the translations meet the original intention of a valid rule. If a bug is identified, it is always worth submitting an issue to GitHub.
Chiamata all’Azione e Lavoro Futura
Se sei arrivato fino a qui, sei più che preparato a scrivere e condividere la tua prima regola! Se ti è piaciuto questo blog, potresti apprezzare un altro in arrivo presto sull’uso di SIGMAC per personalizzare i contenuti.
