Folgen 
Zusammenfassung
- SIGMA ist ein plattformunabhängiges Format für Erkennungsregeln, das es Teams ermöglicht, SIEM-Erkennungen zwischen Anbietern zu teilen.
- Um eine Regel zu schreiben, beginnt man mit einer Erkennungsidee, wählt eine gemeinsame Protokollquelle und mappt sie in SIGMA (min:
logsource+detection). logsourcegibt an, auf welche Protokolle die Regel zutrifft, damit Übersetzer das richtige Backend/Datenformat ansprechen können.detectionbesteht aus Selektionen (Feld-/Wertzuordnungen + Modifikatoren) plus einer Bedingung (boolesche Logik), optional mit Korrelation/Zeitfenster.- Verwenden Sie SIGMA-Feldkonventionen (groß-/klein-schreibung beachten), übersetzen/testen Sie die Regel und teilen/bearbeiten Sie diese basierend auf Feedback.
Dieser Blogbeitrag argumentiert für SIGMA als Erkennungssprache, behandelt die wichtigsten SIGMA-Regelkomponenten (logsource & detection), SIGMA-Taxonomie, das Testen von SIGMA-Regeln und bereitet Analysten, die neu bei SIGMA sind, allgemein darauf vor, ihre ersten Regeln zu schreiben. Eine kurze Diskussion über Detection Engineering mit SIGMA wird ebenfalls hinsichtlich Geräuschentwicklung, Ideen, Protokollquellen etc. bereitgestellt.
Das Argument für SIGMA-Regeln
In der Vergangenheit existierten SIEM-Erkennungen in anbieter-/plattformspezifischen Silos. Partner, die Inhalte zur Erkennung teilen wollten, mussten oft eine Abfrage von einem Anbieter in eine andere übersetzen. Dies ist nicht nachhaltig, die Verteidigungsgemeinschaft gegen Cyber-Security 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 den offenen Austausch von Erkennungen, jedoch mit dem Fokus auf SIEM anstelle von Dateien oder Netzwerkverkehr. SIGMA ermöglicht es Verteidigern, Erkennungen (Alarmmeldungen, 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 Suche. Mit SIGMA sind Verteidiger von anbieter- und plattformspezifischen Erkennungssprachen und Repositories befreit und können die Macht der Community nutzen, um rechtzeitig auf kritische Bedrohungen und neue Gegnerstrategien zu reagieren.
Es gibt viele Gründe, SIGMA zu verwenden:
- Forscher- und Intelligence-Teams, die neue Gegnerverhaltensweisen identifizieren und eine neutrale Möglichkeit zum Teilen von Erkennungen wünschen
- MSSP / MDR, verantwortlich für mehrere SIEM / EDR / Log-Analytics-Lösungen & Datentaxonomien/-schemata (ECS, CEF, CIM, etc)
- Vermeiden Sie Anbieterbindung, indem Sie Regeln in einem SIGMA definieren. So können Sie leichter 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 Protokolle sammelt und durchsucht. Ich akzeptiere, dass viele der aufgeführten Plattformen möglicherweise nicht Ihrer Definition von „SIEM“ entsprechen. Die Begriffe „Plattform“ oder „Protokollplattform“ sind jedoch zu unscharf.
FolgenSIGMA-Regeln erstellen
Das Schreiben von SIGMA-Regeln erfordert grundlegende Kenntnisse über das SIGMA-Schema und die Taxonomie, eine Idee, die Anpassung dieser Idee an SIGMA, Tests, das Teilen und potenziell die Wartung der Regel.
Empfohlener Hintergrund & Kontext
Trotz der Länge dieses Blogs ist SIGMA dank YAML und dem Weitblick der Ersteller leicht zu verstehen und zu schreiben. Bei SOC Prime sagen wir gerne: „Jeder kann SIGMA lernen.“ Die Kunst des Detection Engineering ist, wo es komplizierter wird.
Es gibt viele weitere Ressourcen wie das offizielle Wiki und einige von SIGMA-Experten geschriebene Anleitungen (unten aufgeführt). Es gibt bestimmte Fallen wie richtiger Umgang mit Platzhaltern or falsche Feldnamen die fehlerhafte Regeln verursachen können, und viele davon werden in diesen Ressourcen behandelt.
Wenn Sie ein Forscher sind, der sich in SIGMA vertiefen möchte, ist das Threat Bounty Program von SOC Prime eine großartige Gelegenheit, um zu beginnen und ein wenig Geld zu verdienen. Eingereichte Regeln durchlaufen einen gründlichen Prüfprozess, 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 Protokollquellen, Thomas Patzke 2019
Empfohlene Lektüre:
Arten von Erkennungen, die SIGMA-Regeln ausdrücken können
Heute existieren derzeit zwei grundlegende Arten von Regeln:
- SIGMA-Regeln basierend auf Matching, weit verbreitet, 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, jedoch sind diese im Allgemeinen für spezifische Protokollquellenregeln in Ungnade gefallen. Das SOC Prime-Team erstellt im Allgemeinen keine Multi-YAML-Regeln, da sie unnötige Komplexität für die Regelwartung und -bereitstellung hinzufügen. 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 zum Detection Engineering mit SIGMA)
Benutzer und Administratoren speichern oft sensible Passwörter in Klartextdokumenten wie Textdateien, Excel, Word usw. Ich mache mir Sorgen, dass Gegner diese Dateien in einer Umgebung identifizieren könnten, bevor ich es tue. Wir möchten unsere Benutzer anweisen, wie sie Passwörter ordnungsgemäß speichern, bevor sie von einem kriminellen Hacker entdeckt werden.
Für viele SIGMA-Regeln liegt es im Nutzen des Autors, die Idee zu abstrahieren und das Ziel ‚angemessen‘ zu erweitern. Bei Ideen wie dieser können wir fundierte Vermutungen darüber anstellen, wie das Verhalten may aussehen könnte, nicht nur, was wir beobachtet haben. Zum Beispiel können wir fundierte 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“, ist kontraintuitiv 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 unbekannten Umgebungen konsumiert wird. Wir können den EDR- und Antivirus-Anbietern überlassen, Erkennungen zu erstellen, die keine falschen Positiven aufweisen können. Mit SIGMA können Regeln in Umgebungen getestet und einfach abgestimmt werden.
SIGMA ist leicht verständlich, testbar und abstimmbar. Wenn ein Begriff wie ‚details‘ für eine Umgebung zu laut ist, sollte sich die Person, die die Regel implementiert, ermächtigt fühlen, die Regel zu optimieren. Das gleichzeitige Bereitstellen aller Regeln ohne Tests ist ein Rezept für eine Katastrophe. Regeln abzuschalten, anstatt ihre Absichten für eine Umgebung zu verstehen und abzustimmen, wird dazu führen, dass ein Unternehmen wertvolle Erkennungsinhalte verpasst.
Ich gebe gerne das Beispiel von psexec. In manchen Umgebungen ist psexec völlig normal und der Status quo für Administratoren, die Hosts remote verwalten. In anderen Umgebungen ist psexec (wahrscheinlich zu Recht) nicht zulässig, blockiert und eine strafbare Handlung für Administratoren. Ist eine SIGMA-Regel, um jede Verwendung von psexec zu erkennen, also ‚laut‘ oder einfach besser für einige Umgebungen als für andere? Wenn Sie Inhalte ohne Tests bereitstellen, wird die Lärmminderung immer ein Problem sein. Nur die als „kritisch“ identifizierten Regeln sollen sicher sein, ohne Tests verwendet zu werden.
Zurück zur Erstellung unserer Passwort-Expositions-SIGMA-Regel… wir können die Idee erweitern, um zusätzliche Dateinamen wie:
- pw
- psw
- pass
- password
- passwords
- accounts
- account
- info
Erstellt mit Software wie:
- Notepad
- Notepad++
- Wordpad
- Office-Anwendungen
Eine Datenquelle / Eine Protokollquelle
Sobald wir eine Idee haben, brauchen wir eine Protokollquelle. SIGMA unterstützt any Protokollquelle theoretisch, wir sollten jedoch eine Protokollquelle identifizieren, die die meisten Leute haben. Zum Beispiel könnten wir eine Regel für eine Datenverlustprävention-Protokollquelle schreiben, aber Datenverlustprävention wird selten in SIEMs geparst und aufgenommen, und die Branche hat keinen klaren Favoriten. Also können wir eine gültige Regel erstellen, aber sie wird nicht so leicht angenommen werden.
Für Windows-Endpunktsregeln ist Sysmon ein guter Ausgangspunkt. Sysmon wird häufig in Umgebungen eingesetzt und viele Protokollquellen bieten synonyme Daten (EDRs usw.). Bei Sysmon gibt es zwei Hauptoptionen: Prozesserstellung (process_creation in SIGMA) und Dateierstellung (file_event in SIGMA).
Wir werden unsere Erkennung auf der Prozesserstellung aufbauen, da sie weit verbreitet ist und somit sicherstellt, dass unsere Regel so nützlich wie möglich ist. Die Prozesserstellung ist eine großartige Protokollquelle, von der man lernen kann, und sie ist eine der nützlichsten / beliebtesten Protokollquellen, die in Endpunkterkennungen verwendet werden.
Hinweis: Oft kommen Ideen direkt aus den Datenquellen selbst. Durch das Überprüfen der in Ihrem SIEM / Labor verfügbaren Datentypen kann man leicht SIGMA-Regeln identifizieren, die es sich zu schreiben lohnt. Wir können auch andere Quellen wie die Dokumentation von Anbietern nutzen.
Mit Sysmon-Prozesserstellungsereignissen (Ereignis-ID 1) kann ein Benutzer, der auf eine Datei mit Passwörtern zugreift, diese interessanten Felder enthalten:
Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt
Anpassung der Erkennungsidee an SIGMA
Jetzt, da wir eine Idee und eine Datenquelle zum Arbeiten haben, können wir beginnen, unsere Regel aufzubauen.
Dies ist nicht dokumentiert, aber die wirklichen minimalen Komponenten die erforderlich sind, um eine Regel zu übersetzen, sind nur logsource & detection (für einige Backends wie Splunk reicht nur Detection aus). Alles andere ist ‚nur‘ Metadaten, die dem Verbraucher der SIGMA-Regel helfen sollen. Wenn Sie beginnen, ist es in Ihrem Interesse, mit diesen minimalen Feldern zu beginnen, Ihre Logik zu bestätigen 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 Einreichungen zu prüfen und deren Formatierung zu emulieren.
Eine einfache SIGMA-Regel mit minimalen Komponenten für potenzielle Passwörter freizulegen:
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
Logsource-Komponente
The logsource Die Komponente hilft dem SIGMA-Backend-Übersetzer (SIGMAC) zu wissen, welche Art von Daten die Regel ansprechen soll. Sie befähigt den Regel-Ersteller, allgemeinere Regeln zu erstellen. Zum Beispiel, mit logsource als „product: windows, category: process_creation“ müssen wir keine EventIDs (Sysmon 1, Windows 4688, ProcessRollup, etc.) angeben. Der Verbraucher der Regel kann spezifizieren, welche Event-Ids, Indexe usw. er mit Protokollquellen im SIGMA-Konfigurationsdatei relacionado haben möchte. Ohne die Angabe von Indexen, Event-Ids usw. werden die Regeln für den Verbraucher wahrscheinlich unnötig teuer sein (Leistung).
Zusätzlich kann Telemetrie oft ähnliche Felder enthalten, aber völlig unterschiedliche Verhaltensweisen implizieren. Zum Beispiel teilen sich Sysmon-Netzwerkereignisse (Ereignis-Id 3) und Prozesserstellung (Ereignis-ID 1) das Image Feld. Die Existenz von explorer.exe im Image Feld eines Sysmon Netzwerkereignisses unterscheidet sich völlig von der Existenz von explorer.exe in einem Prozesserstellungsereignis. Durch die Bereitstellung der richtigen Logsource-Komponente geben wir wertvollen Kontext für die Erkennung.
Erkennungskomponente
Die Erkennungskomponente ist, wo der Autor ihre Erkennungskriterien definiert. Dazu gehört mindestens eine Selektionskomponente und eine Bedingungskomponente. Es gibt eine optionale Zeitfensterkomponente die für auf Korrelation basierende Regeln erforderlich ist.
Selektions-Unterkomponente(n):
- In der Regel wird dies in der Form Feld A enthält/startswith/endswith/equals Wert Bausgedrückt. Natürlich, wie im obigen Regelbeispiel gezeigt, kann ein Autor bei Bedarf Logik wie Feld A enthält/startswith/endswith/equals Werte X, Y, oder Z. hinzufügen. Diese Logik ist immer case-insensitive.
- Es gibt weiterführende ‘Modifikatoren’, die die Komplexität der Regel erhöhen oder Autoren präziser machen können. Zum Beispiel werden reguläre Ausdrücke über den Operator re behandelt und ermöglichen es den Autoren, Sachen wie case-sensitive Anfragen zu schreiben. Aus Kompatibilitätsgründen ist es am besten, nur die grundlegenden regulären Ausdrucksoperatoren zu verwenden . ? + * | { } [ ] () “ .
- Auswahlen haben Namen (z. B. selection, selection2, selection3, filter). Auswahlen können (fast) beliebig benannt werden. Oft wird eine Variation von selection verwendet, aber man kann seine Auswahl genauso gut banana benennen, und die Regel funktioniert immer noch. Im Allgemeinen wird der Begriff filter für Auswahlen verwendet, die ausgeschlossen werden sollen (z. B. selection AND NOT filter).
Bedingung Unterkomponente:
- Die Bedingungskomponente enthält boolesche Logik (AND, OR, NOT), die definiert, wie jede Auswahl in der finalen Abfrage enthalten sein soll.
- Z. B. (selection_a OR selection_b) UND NICHT filter
Bedingungskomponente mit Korrelation:
Es gibt zwei Arten von Korrelationen, die heute von Backends unterstützt werden. Es gibt andere Korrelationen, die vom SIGMA-Schema unterstützt werden, aber noch nicht von den verfügbaren Backends.
Count() by Y:
Zählen Sie die einzigartigen Instanzen des Y-Feldwerts und vergleichen Sie sie (größer als, kleiner als) mit einer statischen Zahl.
Beispiel: Count() by src_ip > 2
Count(X) by Y:
Zählen Sie die einzigartigen Instanzen des X-Feldwerts pro Y-Wert und vergleichen Sie die Anzahl von X (größer als, kleiner als) mit einer statischen Zahl.
Beispiel: Count(EventID) by src_ip > 2
Häufige Verwendungsfälle für Korrelationen:
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. |
Zeitfenster Unterkomponente:
- The Zeitfenster Komponente wird in Verbindung mit Bedingungen verwendet, die eine Korrelation enthalten. Viele Backends ignorieren das Zeitfenster; jedoch wird es in den meisten Repositories regelmäßig einbezogen und muss inbegriffen sein, einschließlich desjenigen von SOC Prime.
Vollständige Beispiele mit Splunk:
- Hier sind einige Beispiele für SIGMA und deren Übersetzungen für Splunk. Wenn Sie mit Splunk nicht vertraut sind, sind Sternchen Platzhalter, sodass ein Begriff, umgeben von Sternchen (z. B. *Term*) ‚beinhaltet‘ ist, ein Begriff mit einem führenden Sternchen (z. B. *term) „endet mit“, ein Begriff mit einem nachgestellten Sternchen ist ‚endet 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 |
Taxonomiefragen (z. B. welche Feldnamen sollten verwendet werden)
Theoretisch können Sie beliebige Feldnamen verwenden, solange jemand bereit ist, Zeit in das Schreiben einer SIGMA-Konfiguration zu investieren, um von Ihren Feldern… zu ihren zu übersetzen.
Hinweis: Feldnamen sind case-sensitive! CommandLine and commandline sind zwei verschiedene Werte. CommandLine ist Teil der bestehenden Taxonomie, commandline ist es nicht.
Das gesagt, ist es am besten, die von SIGMA dokumentierten Feldnamen zu verwenden. Es gibt drei Stellen, an denen das öffentliche SIGMA-Repository die Taxonomie dokumentiert.
Als allgemeine Regel verwenden wir die in dem Wiki spezifizierten SIGMA-Feldnamen für Kategorien
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- Das Wiki wird den Lesern zeigen, dass SIGMA verwendet
— SYSMON-Felder für Endpunktsregeln
— W3C-Erweitertes Protokolldateiformat für Webserver- & Proxieregeln
— Die Felder für Firewall, Antivirus
Gefolgt von SIGMA-Feldnamen, die in bestehenden Regeln & SIGMA-Konfigurationsdateien spezifiziert sind
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Wirklich die offizielle Dokumentation für Felder. Benutzer können diese bei Bedarf erstellen/verändern, wenn sie Regeln übersetzen.
- https://github.com/SigmaHQ/sigma/tree/master/rules
Und schließlich, wenn keine Konfiguration oder Regeln existieren, verwenden wir die ursprünglichen Feldnamen aus der Herkunftsprotokollquelle. Wenn Feldnamen von verschachtelten Werten stammen (z. B. userIdentity verschachtelt unter accountId in aws cloudtrail) verwenden wir einen Punkt, um anzuzeigen, dass das Feld verschachtelt ist, da dies relativ konsistent in verschiedenen SIEMS ist (z. B. userIdentity -> accountId wird userIdentity.accountId).
SIGMA-Regeln testen
SIGMA-Regeln zu testen ist einfach. Oft sind Leute sogar in der Lage, Inhalte einzureichen, ohne sie direkt selbst zu testen. Die meisten öffentlichen Forscher haben keinen Zugang zu vielfältigen Umgebungen, um Regeln gegen ‚die Menge aller SIEMs‘ zu testen. Stattdessen kann man sich auf öffentliches Feedback, Feedback von Vertrauenspersonen etc. verlassen. Selbst Florian Roth, ein Mitbegründer von SIGMA, stellt regelmäßig Regeln zur öffentlichen Bewertung über seinen Twitter ein. Ich habe auch gesehen, wie Leute direkt in ihren persönlichen Blogs und auf LinkedIn usw. veröffentlichen. Wenn Sie denken, dass Sie eine gute Regel zum Teilen haben, veröffentlichen Sie sie, vertrauen Sie mir: Wenn sie falsch ist (oder nicht), werden die netten Leute im Internet 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 (uncoder oder mit SIGMAC) ist
- Sanity-Check (z. B. sicherstellen, dass die Regel Ihrer ursprünglichen Erwartung entspricht, die richtige Taxonomie befolgt usw.) – sehen Sie sich die Fallstricke an: https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- Überprüfen Sie die Regel in einer Laborumgebung
- Teilen Sie die Regel umfassend zum Testen / Teilen der Regel mit dem SOC Prime-Team über das Treat Bounty Program
Hinweis: Aus der Perspektive eines Regelerstellers sollten Sie sich im Allgemeinen keine Gedanken über die Backend-Implementierungen von 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 bei GitHub einzureichen.
Über SOC Prime
- Gründeten die Detection-as-Code-Branche im Jahr 2015
- Partnerschaft mit Fortune 100 + globalen MDRs
- Bedeckung der gesamten Pipeline von Erkennung bis Simulation
- Magische Bedrohungssuche anstelle von Filtern
- 650.000+ Erkennungsregeln
- Tägliche neue Bedrohungen
- Line-Speed ETL Detection
- Shift-Left-Erkennung, richtig gemacht
FAQ
Was ist eine SIGMA-Regel?
Eine SIGMA-Regel ist eine herstellerunabhängige Erkennung, die in YAML geschrieben ist und verdächtige Aktivitäten in Protokollen beschreibt. Sie können sie in Abfragen für viele SIEMs und Protokollwerkzeuge übersetzen.
Was sind die beiden unverzichtbaren Teile einer SIGMA-Regel?
Logsource und detection einbeziehen. logsource definiert die Art der Protokolle (wie Windows-Prozesserstellung) und detection hält die Matching-Logik und -Bedingung.
Wie schreibt man eine SIGMA-Erkennungsbedingung?
Erstellen Sie eine oder mehrere „Selektionen“, die Felder und Werte abgleichen, und kombinieren Sie sie dann in Bedingung mit AND/OR/NOT. Damit können Sie einfache Übereinstimmungen und komplexere Logik ausdrücken.
Wie wählt man eine gute Protokollquelle für seine erste SIGMA-Regel?
Wählen Sie etwas, das weit verbreitet ist, damit andere es nutzen können. Für Windows-Endpunkt-Erkennungen ist Sysmon eine häufige Wahl und die Prozesserstellung (process_creation) ein praktischer Ausgangspunkt.
Wie testet man eine SIGMA-Regel, bevor sie in der Produktion eingesetzt wird?
Übersetzen Sie sie in Ihre Zielplattform (zum Beispiel mit einem SIGMA-Konverter), führen Sie sie gegen reale oder Labordaten aus und optimieren Sie sie, um Fehlalarme zu reduzieren, bevor Sie sie umfangreich einführen.
