Was sind SIGMA-Regeln: Ein Leitfaden für Anfänger
Inhaltsverzeichnis:
Dieser Blog-Beitrag argumentiert für SIGMA als Detektionssprache, behandelt die wichtigsten Komponenten von SIGMA-Regeln (Logsource & Erkennung), die SIGMA-Taxonomie, das Testen von SIGMA-Regeln und bereitet allgemein Analysten, die neu bei SIGMA sind, darauf vor, ihre ersten Regeln zu schreiben. Eine kurze Diskussion über Detection Engineering mit SIGMA wird ebenfalls bereitgestellt, in Bezug auf Lärm, Ideen, Datenquellen usw.
Der Fall für SIGMA-Regeln
In der Vergangenheit existierten SIEM-Erkennungen in hersteller- oder plattformspezifischen Silos. Partner, die Erkennungsinhalte teilen wollten, mussten häufig eine Abfrage von einem Hersteller in einen anderen übersetzen. Das ist nicht nachhaltig, die defensive Cyber-Sicherheit-Community muss verbessern, wie wir Erkennungen teilen, um mit unseren sich ständig weiterentwickelnden Gegnern Schritt zu halten.
Ähnlich wie YARA oder Snort-Regeln ist SIGMA ein weiteres Werkzeug für das offene Teilen von Erkennungen, das jedoch auf SIEMs statt auf Dateien oder Netzwerkverkehr fokussiert ist. SIGMA ermöglicht es Verteidigern, Erkennungen (Alarme, Anwendungsfälle) in einer gemeinsamen Sprache zu teilen.
Erstmals 2017 von Florian Roth und Thomas Patzke veröffentlicht, ebnet SIGMA den Weg für plattformunabhängige Suchen. Mit SIGMA sind Verteidiger von hersteller- und plattformspezifischer Detektionssprache und -repositorien befreit und können die Kraft der Community nutzen, um rechtzeitig auf kritische Bedrohungen und neue Opponententaktiken zu reagieren.
Es gibt viele Gründe, SIGMA zu nutzen:
- Forscher und Geheimdienstteams, die neue Gegnertaktiken identifizieren und eine agnostische Methode zum Teilen von Erkennungen wünschen
- MSSP / MDR verantwortlich für mehrere SIEM / EDR / Log-Analytics-Lösungen und Daten-Taxonomien/Schemata (ECS, CEF, CIM, etc.)
- Vermeiden Sie Herstellerabhängigkeit, indem Sie Regeln in einem SIGMA definieren, können wir einfacher zwischen Plattformen wechseln.
- Forscher im offensiven Sicherheitsbereich, die Erkennungen basierend auf ihrer Forschung erstellen möchten
Hinweis: In diesem Blog wird SIEM verwendet, um jede Plattform zu beschreiben, die zum Sammeln und Durchsuchen von Logs verwendet wird. Ich akzeptiere, dass viele der aufgeführten Plattformen möglicherweise nicht Ihrer Definition von „SIEM“ entsprechen. Die Begriffe „Plattform“ oder „Log-Plattform“ zu verwenden, ist jedoch zu vage.
SIGMA-Regeln erstellen
Das Schreiben von SIGMA-Regeln erfordert grundlegende Kenntnisse über das SIGMA-Schema und die Taxonomie, eine Idee, das Anpassen dieser Idee an SIGMA, das Testen, Teilen und möglicherweise Warten der Regel.
Empfohlener Hintergrund & Kontext
Trotz der Länge dieses Blogs ist SIGMA dank YAML und vorausschauendem Denken der Entwickler leicht verständlich und zu schreiben. Bei SOC Prime sagen wir gerne: „Jeder kann SIGMA lernen“. Die Kunst der Detektionsentwicklung ist der Punkt, an dem es komplizierter werden kann.
Es gibt viele andere Ressourcen wie das offizielle Wiki und einige von SIGMA-Experten geschriebene Leitfäden (unten aufgeführt). Es gibt bestimmte Fallen wie die korrekte Handhabung von Wildcards or falsche Feldnamen die fehlerhafte Regeln verursachen können, und viele dieser Dinge werden in diesen Ressourcen behandelt.
Wenn Sie ein Forscher sind, der in SIGMA einsteigen möchte, ist das Threat Bounty Program von SOC Prime eine großartige Gelegenheit, um anzufangen und ein wenig Geld zu verdienen. Eingereichte Regeln durchlaufen einen gründlichen Überprüfungsprozess, bei dem wir Sie anleiten und Ihnen helfen können, Fehler zu verstehen und als Analyst zu wachsen.
Empfohlene Lektüre:
- Wie man SIGMA-Regeln schreibt, Florian Roth 2018
- Ein Leitfaden zu generischen Logquellen, Thomas Patzke 2019
Empfohlene Ansichten:
Arten von Erkennungen, die SIGMA-Regeln ausdrücken können
Heutzutage existieren aktuell zwei grundlegende Arten von Regeln:
- SIGMA-Regeln basierend auf Matching, weit unterstützt, am einfachsten zu schreiben
- SIGMA-Regeln basierend auf Matching und einfachen Korrelationen, begrenzte Unterstützung, weniger leicht zu schreiben
Hinweis: Es gibt auch Multi-YAML-SIGMA-Regeln, die jedoch im Allgemeinen zugunsten spezifscher Regeln für Logquellen außer Mode geraten sind. Das SOC-Prime-Team erstellt in der Regel keine Multi-YAML-Regeln, da sie unnötige Komplexität in die Regelverwaltung und -bereitstellung einbringen. Jemand kann eine Multi-YAML-SIGMA-Regel erstellen, wenn er zwei SIGMA-Regeln erstellen kann.
Lassen Sie uns eine einfache SIGMA-Regel erstellen!
Eine Idee (und einige Gedanken zur Detektionsentwicklung mit SIGMA)
Benutzer und Administratoren bewahren oft sensible Passwörter in Klartextdokumenten wie Textdateien, Excel, Word, etc. auf. Ich befürchte, dass Gegner diese Dateien in einer Umgebung möglicherweise vor mir identifizieren könnten. Wir möchten unsere Benutzer anleiten, wie sie Passwörter richtig speichern, bevor sie von einem kriminellen Hacker entdeckt werden.
Bei vielen SIGMA-Regeln liegt es im Interesse des Autors, die Idee zu abstrahieren und das Ziel „angemessen“ zu erweitern. Für Ideen wie diese können wir gebildete Vermutungen über das Verhalten anstellen may aussehen, nicht nur was wir beobachtet haben. Zum Beispiel können wir gebildete Vermutungen über zusätzliche Begriffe und Erweiterungen anstellen, die Benutzer möglicherweise verwenden, um Passwörter im Klartext zu speichern.
Die Idee, eine Regel zu „erweitern“, steht oft im Widerspruch zu den Instinkten vieler Analysten. Alle „falschen Positiven“ zu eliminieren, ist nicht unbedingt das Ziel des ursprünglichen Autors, wenn eine Regel in unbekannten und unvertrauten Umgebungen verwendet werden soll. Wir können EDR- und Anti-Virus-Herstellern überlassen, Erkennungen zu erstellen, die keine falschen Positiven haben können. Mit SIGMA können Regeln in Umgebungen getestet und leicht angepasst werden.
SIGMA ist leicht verständlich, testbar und anpassbar. Wenn ein Begriff wie ‚Details‘ in einer Umgebung zu laut ist, sollte sich die Person, die die Regel implementiert, ermutigt fühlen, die Regel anzupassen. Alle Regeln auf einmal ohne Testen bereitzustellen, ist ein Rezept für eine Katastrophe. Regeln auszuschalten, anstatt ihre Absichten für eine Umgebung zu verstehen und anzupassen, wird dazu führen, dass ein Shop solide Erkennungsinhalte verpasst.
Ich gebe gerne das Beispiel von psexec. In einigen Umgebungen ist psexec völlig normal und der Status quo, damit Administratoren Hosts remote verwalten. In anderen Umgebungen ist psexec (wahrscheinlich zu Recht) unzulässig, blockiert und ein justiziabler Verstoß für Administratoren, dies zu verwenden. Ist also eine SIGMA-Regel, die jede Verwendung von psexec erkennt ‚laut‘ oder einfach besser für einige Umgebungen als andere? Wenn Sie Inhalte bereitstellen, ohne zu testen, wird das Rauschen immer ein Problem sein. Nur Regeln, die als „kritisch“ identifiziert sind, sollen sicher sein, ohne Tests verwendet zu werden.
Zurück zur Erstellung unserer Passwort-Expositionsregel.. wir können die Idee erweitern, um zusätzliche Dateinamen hinzuzufügen wie:
- pw
- psw
- Passwort
- Passwort
- Passwörter
- Konten
- Konto
- Info
Erstellt mit Software wie:
- Notepad
- Notepad++
- Wordpad
- Office-Anwendungen
Eine Datenquelle / Eine Logquelle
Sobald wir eine Idee haben, brauchen wir eine Logquelle. SIGMA unterstützt theoretisch any Logquellen, wir sollten jedoch eine Logquelle identifizieren, die die meisten Leute haben. Zum Beispiel könnten wir eine Regel für eine Data-Loss-Prevention-Logquelle schreiben, aber Data-Loss-Prevention wird selten geparst und in SIEMs integriert, und die Branche hat keinen klaren Favoriten. Wir können also eine gültige Regel erstellen, aber sie wird nicht so leicht übernommen.
Für Windows-Endpunktregeln ist Sysmon ein großartiger Ausgangspunkt. Sysmon wird häufig in Umgebungen bereitgestellt, und viele Logquellen bieten synonyme Daten (EDRs, etc.). Mit Sysmon gibt es zwei Hauptoptionen: Prozesserstellung (process_creation in SIGMA) und Datei-Erstellung (file_event in SIGMA).
Wir werden unsere Erkennung auf der Prozesserstellung aufbauen, da sie breiter übernommen wird, was sicherstellt, dass unsere Regel so nützlich wie möglich ist. Die Prozesserstellung ist eine großartige Logquelle zum Lernen und eine der nützlichsten / beliebtesten Logquellen, die in Endpoint-Erkennungen verwendet werden.
Hinweis: Oft kommen Ideen direkt aus den Datenquellen selbst. Durch die Überprüfung der Arten von Daten, die Ihnen in Ihrem SIEM / Labor zur Verfügung stehen, kann man leicht SIGMA-Regeln identifizieren, die es wert sind, geschrieben zu werden. Wir können auch andere Quellen wie Herstellerdokumentation nutzen.
Mit Sysmon-Prozesserstellungsereignissen (Ereignis-ID 1) kann ein Benutzer, der auf eine Datei mit Passwörtern zugreift, diese interessanten Felder enthalten:
Bild: C:WindowsSystem32notepad.exe
Befehlszeile: „C:WindowsSystem32NOTEPAD.EXE“ C:UsersJohnDesktoppassword.txt
Anpassung der Erkennungsidee an SIGMA
Jetzt, da wir eine Idee und eine Datenquelle haben, können wir beginnen, unsere Regel zu erstellen.
Dies ist nicht dokumentiert, aber die wahren minimalen Komponenten die erforderlich sind, um eine Regel zu übersetzen, bestehen nur aus Logsource & Erkennung (für einige Backends wie Splunk reicht nur Erkennung aus). Alles andere ist ‚nur‘ Metadaten, um dem SIGMA-Regelkonsumenten zu helfen. Wenn Sie anfangen, ist es in Ihrem Interesse, mit diesen minimalen Feldern zu beginnen, zu bestätigen, dass Ihre Logik funktioniert, und dann zusätzliche SIGMA-Felder & Daten hinzuzufügen. Wenn Sie Ihre Regel im öffentlichen SIGMA-Repo veröffentlichen möchten, lohnt es sich, frühere Einsendungen zu überprüfen und deren Formatierung nachzuahmen.
Eine einfache SIGMA-Regel mit minimalen Komponenten zur potenziellen Passwort-Exposition:
Titel: Potenzielle Passwort-Exposition (über cmdline)
Autor: Adam Swan
Tags:
- attack.t1552.001
- attack.credential_access
Logsource:
Produkt: Windows
Kategorie: Prozess-Erstellung
Erkennung:
Auswahl:
Bild|endswith:
- 'notepad.exe'
- 'word.exe'
- 'excel.exe'
- 'wordpad.exe'
- 'notepad++.exe'
Befehlszeile|contains:
- 'pass' #pass wird bei Passwort übereinstimmen, inkl. Passwort ist redundant
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'Konto' #Konten,
- 'geheim'
- 'Details' #Ich habe den Plural 'Details' basierend auf Erfahrung eingeschlossen
Bedingung: Auswahl
Logsource-Komponente
The Logsource Die Komponente hilft dem SIGMA-Backend-Übersetzer (SIGMAC) zu wissen, gegen welche Art von Daten die Regel angewendet werden soll. Es ermöglicht dem Regelersteller, allgemeinere Regeln zu erstellen. Zum Beispiel benötigen wir mit Logsource Die Angabe von EventIDs (Sysmon 1, Windows 4688, ProcessRollup, etc.) nicht anzugeben. Der Konsument der Regel kann festlegen, welche EventIDs, Indizes, etc. er mit Logquellen in der SIGMA-Config verknüpfen möchte. Ohne die Angabe von Indizes, EventIDs, etc. werden Regeln wahrscheinlich unnötig teuer (Leistung) für den Konsumenten sein.
Zusätzlich kann die Telemetrie oft ähnliche Felder enthalten, aber völlig unterschiedliche Verhaltensweisen implizieren. Zum Beispiel teilen Sysmon-Netzwerkverbindungsevents (Ereignis-ID 3) und Prozesserstellung (Ereignis-ID 1) das Bild Feld. Die Existenz von explorer.exe im Bild Feld eines Sysmon-Netzwerkverbindungsevents völlig anders als das Vorhandensein von explorer.exe in einem Prozesserstellungsereignis. Durch die Bereitstellung der richtigen Logsource-Komponente bieten wir unverzichtbaren Kontext für die Erkennung.
Erkennungskomponente
Die Erkennungskomponente ist der Ort, an dem der Autor die Erkennungskriterien definiert. Dies umfasst mindestens eine Auswahl-Komponente und eine Bedingungskomponente. Es gibt eine optionale Zeitrahmen-Komponente die für regelbasierte Regeln erforderlich ist.
Auswahl Unterkomponente(n):
Im Allgemeinen nimmt dies die Form an Feld A enthält/anfängt mit/endet mit/gleicht Wert B. Natürlich können, wie im obigen Regelbeispiel beobachtet, falls ein Autor benötigt, Logiken wie Feld A enthält/anfängt mit/endet mit/gleicht Werte X, Y oder Z. Diese Logik ist immer groß-/kleinschreibungsempfindlich.
Es gibt fortgeschrittenere ‚Modifiers‘, die die Komplexität der Regel erhöhen oder Autoren ermöglichen, präziser zu sein. Beispielsweise werden reguläre Ausdrücke über den Operator behandelt re und ermöglichen es Autoren, Dinge wie Groß-/Kleinschreibung-sensible Abfragen zu schreiben. Aus Kompatibilität ist es am besten, nur die grundlegenden regulären Ausdrucksoperatoren zu verwenden . ? + * | { } [ ] () “ .
Auswahlen sind benannt (z.B. Auswahl, Auswahl2, Auswahl3, Filter). Sie können (fast) beliebig benannt werden. Oft wird eine Variation von Auswahl verwendet, aber man kann genauso gut seine Auswahl Banane nennen und die Regel würde trotzdem funktionieren. Im Allgemeinen wird der Begriff Filter für Auswahlen verwendet, die ausgeschlossen werden (z.B. Auswahl UND NICHT Filter).
Bedingungskomponente
Die Bedingungskomponente enthält Boolesche Logik (UND, ODER, NICHT), die definiert, wie jede Auswahl in die endgültige Abfrage einbezogen werden soll.
Bsp.: (Auswahl_a ODER Auswahl_b) UND NICHT Filter
Bedingungskomponente mit Korrelation:
Heute unterstützen Backends zwei Arten von Korrelationen. Es gibt andere Korrelationen, die vom SIGMA-Schema unterstützt werden, aber noch nicht von den verfügbaren Backends.
Zähle() nach Y:
Zähle die einzigartigen Instanzen des Y-Feldwertes und vergleiche (größer als, kleiner als) mit einer statischen Zahl.
Beispiel: Zähle() nach src_ip > 2
Zähle(X) nach Y:
Zähle die einzigartigen Instanzen des X-Feldwertes pro Y-Wert und vergleiche (größer als, kleiner als) die Anzahl von X mit einer statischen Zahl.
Beispiel: Zähle(EventID) nach src_ip > 2
Häufige Korrelations-Anwendungsfälle:
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. |
Zeitrahmen-Unterkomponente:
The Zeitrahmen Die Komponente wird im Zusammenhang mit Bedingungen verwendet, die eine Korrelation beinhalten. Viele Backends ignorieren den Zeitrahmen, jedoch wird er im Allgemeinen immer aufgenommen und in den meisten Repositories einschließlich SOC Prime als erforderlich betrachtet.
Komplette Beispiele mit Splunk:
Hier sind einige Beispiele für SIGMA und deren Übersetzungen für Splunk. Wenn Sie mit Splunk nicht vertraut sind, sind Asterisken ein Platzhalter, sodass ein Begriff, der von Asterisken umgeben ist (z.B. *term*), ‚enthält‘ bedeutet, ein Begriff mit einem führenden Asterisk (z.B. *term) bedeutet endend mit, ein Begriff mit einem nachfolgenden Asterisk ist ‚endend mit‘ (z.B. 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 |
Taxonomie-Fragen (z.B. welche Feldnamen zu verwenden sind)
Theoretisch können Sie beliebige Feldnamen verwenden, solange jemand bereit ist, die Zeit zu investieren, um eine SIGMA-Konfiguration zu erstellen, die von Ihren Feldern auf ihre übersetzt.
Hinweis: Feldnamen sind groß-/klein-schreibungsempfindlich! Befehlszeile and befehlszeile sind zwei unterschiedliche Werte. Befehlszeile ist Teil der bestehenden Taxonomie, befehlszeile nicht.
Das gesagt, ist es am besten, die in SIGMA dokumentierten Feldnamen zu verwenden. Es gibt drei Orte, an denen das öffentliche SIGMA-Repository die Taxonomie dokumentiert.
- Als Faustregel verwenden wir die in der Wiki für Kategorien angegebenen SIGMA-Feldnamen
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- Das Wiki wird den Lesern offenbaren, dass SIGMA
- SYSMON-Felder für Endpoint-Regeln verwendet
- W3C Erweitertes Logdateiformat für Webserver- & Proxyregeln
- Die Felder für Firewall, Antivirus
- Gefolgt von SIGMA-Feldnamen, die in bestehenden Regeln & SIGMA-Konfigurationsdateien angegeben sind
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Wirklich die offizielle Dokumentation für Felder. Benutzer können diese erstellen / modifizieren, wenn erforderlich, beim Übersetzen von Regeln.
- https://github.com/SigmaHQ/sigma/tree/master/rules
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
Und wenn keine Konfiguration oder Regeln existieren, verwenden wir die ursprünglichen Feldnamen von der ursprünglichen Logquelle. Wenn Feldnamen aus verschachtelten Werten stammen (z.B. userIdentity verschachtelt unter accountId in aws cloudtrail) verwenden wir einen Punkt, um anzugeben, dass das Feld verschachtelt ist, da dies relativ konsistent über verschiedene SIEMS ist (z.B. userIdentity -> accountId wird userIdentity.accountId).
SIGMA-Regeln testen
Das Testen von SIGMA-Regeln ist einfach. Oftmals können Leute sogar Inhalte einreichen, ohne sie selbst direkt zu testen. Die meisten öffentlichen Forscher haben keinen Zugriff auf diverse Umgebungen, um Regeln gegen ‚die Gesamtheit aller SIEMs‘ zu testen. Stattdessen kann man sich auf öffentliches Feedback, Feedback von vertrauenswürdigen Parteien, etc. verlassen. Auch Florian Roth, ein Mitentwickler von SIGMA, veröffentlicht regelmäßig Regeln zur öffentlichen Rückmeldung über seinen Twitter. Ich habe auch Leute gesehen, die direkt auf ihren persönlichen Blogs und LinkedIn veröffentlichen. Wenn Sie denken, dass Sie eine gute Regel zum Teilen haben, setzen Sie sie da draußen, vertrauen Sie mir, wenn sie falsch ist (oder nicht), die lieben Leute im Internet werden es Ihnen wissen lassen! Nehmen Sie sich nicht zu ernst und seien Sie bereit, Änderungen vorzunehmen und etwas zu lernen.
Es gibt einige grundlegende Schritte, die Sie unternehmen können:
- Stellen Sie sicher, dass die Regel übersetzt wird (uncoder oder durch Verwendung von SIGMAC)
- Vernunftüberprüfung (z.B. sicherstellen, dass die Regel Ihren ursprünglichen Erwartungen entspricht, der korrekten Taxonomie folgt, etc.) – siehe Fallstricke: https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- Die Regel in einer Laborumgebung überprüfen
- Die Regel breit zum Testen teilen / die Regel über das Treat Bounty Program mit dem SOC-Prime-Team teilen
Hinweis: Aus der Perspektive eines Regelautors sollten Sie sich allgemein keine Sorgen um die Backend-Implementierungen der Regeln machen. Es liegt an den SIGMA-Backend-Autoren und Leuten wie SOC Prime, sicherzustellen, dass die Übersetzungen der ursprünglichen Absicht einer gültigen Regel entsprechen. Wenn ein Fehler identifiziert wird, lohnt es sich immer, ein Problem auf GitHub zu melden.
Aufruf zum Handeln & Zukünftige Arbeiten
Wenn Sie es bis hierher geschafft haben, sind Sie mehr als bereit, Ihre erste Regel zu schreiben und zu teilen! Wenn Ihnen dieser Blog gefallen hat, könnte Ihnen ein weiterer, demnächst kommender Blog über die Verwendung von SIGMAC zur Anpassung von Inhalten gefallen.
