Mit Sigma-Regeln können Sie Anomalien in Protokollereignissen erkennen und auf verdächtige Aktivitäten reagieren. [...]
Ein typisches Unternehmensnetzwerk besteht aus Hunderten oder Tausenden von Geräten, die jede Minute Millionen von Protokollzeilen erzeugen. Wie können SOC- und Threat-Intelligence-Analysten diese Informationsflut effizient durchforsten und gefährliche Aktivitäten automatisch vom täglichen Routinebetrieb trennen?
Genau hier kommen Sigma-Regeln zum Einsatz.
Was sind Sigma-Regeln?
Sigma-Regeln sind in YAML geschriebene Textsignaturen, die es ermöglichen, Anomalien in Ihrer Umgebung zu erkennen, indem sie Log-Events überwachen, die Anzeichen für verdächtige Aktivitäten und Cyber-Bedrohungen sein können. Sigma wurde von den Threat-Intelligence-Analysten Florian Roth und Thomas Patzke entwickelt und ist ein generisches Signaturformat für den Einsatz in SIEM-Systemen.
Ein Hauptvorteil der Verwendung eines standardisierten Formats wie Sigma ist, dass die Regeln plattformübergreifend sind und in verschiedenen SIEM-Produkten (Security Information and Event Management) funktionieren. So können Verteidiger eine „gemeinsame Sprache“ verwenden, um Erkennungsregeln unabhängig von ihrem Sicherheitsarsenal untereinander auszutauschen. Diese Sigma-Regeln können dann von SIEM-Produkten in ihre eigene, SIEM-spezifische Sprache umgewandelt werden, wobei die von der Sigma-Regel vermittelte Logik erhalten bleibt.
Während Analysten YARA-Regeln eher mit der Identifizierung und Klassifizierung von Malware-Samples (Dateien) anhand von Kompromittierungsindikatoren (Indicators of Compromise, IOCs) in Verbindung bringen, konzentrieren sich Sigma-Regeln auf die Erkennung von Protokollereignissen, die den vom Regelwerk umrissenen Kriterien entsprechen.
Incident Response-Experten können beispielsweise Sigma-Regeln verwenden, um bestimmte Erkennungskriterien festzulegen. Alle Protokolleinträge, die diese Regel erfüllen, werden dann einen Alarm auslösen.
Die Sigma Spezifikation
Die Möglichkeiten, die Sigma bietet, sind umfangreich, und es ist daher hilfreich, sich mit der Sigma Spezifikation vertraut zu machen. Sie bietet eine lange Liste von Elementen und definiert, was jedes einzelne bedeutet:
Von grundlegenden Metadatenfeldern wie dem Namen und dem Autor der Regel bis hin zu funktionalen Feldern wie Zeitrahmen, String-Identifikator und Protokollquelle ermöglichen Sigma-Regeln eine erweiterte Überwachung von Protokollereignissen und -einträgen.
Wie man eine Sigma-Regel schreibt
Jede Sigma-Regel muss einen Titel und einen Bezeichner haben. Das Titelfeld beschreibt in maximal 256 Zeichen kurz, was die Regel tun soll. Das Feld id soll einen globalen eindeutigen Bezeichner für die Regel enthalten. In der Regel wird das id-Feld als zufällig erzeugter UUID-Wert (Universal Unique Identifier) angegeben.
Das Feld status gibt an, ob die Regel als stabil für den Einsatz in der Produktion, für Tests, experimentell, nicht unterstützt oder veraltet angesehen wird. Das kritische Feld logsource gibt die Quelle der Protokolldaten an, anhand derer die Regeln ausgeführt werden sollen. Informative Felder wie Status, Autor, Lizenz und Beschreibung sind optional, werden aber empfohlen.
Bevor Sie eine Sigma-Regel schreiben, sollten Sie sich überlegen, was Sie erreichen wollen. Ist es beispielsweise Ihr Ziel, Instanzen einer gemeinsamen Zeichenfolge ( Payload) zu erkennen, die mit einem bestimmten Schwachstellen-Exploit verbunden ist, oder das Auftreten eines bestimmten Log-Ereignisses zu überwachen?
Dieses Beispiel ist eine sehr einfache, skelettierte, Sigma-Regel:
title: Test Sigma rule
id: 4d28fc3b-2ed7-4cd0-97c7-7a90b463c881status: test
Eine Regel für ein reales Szenario würde eher so aussehen wie die unten gezeigte. Die Regel mit dem Titel „Remove Immutable File Attribute“ (Unveränderliche Dateiattribute entfernen) bewirkt, dass jedes Mal, wenn unveränderliche Dateiattribute aus einer Datei entfernt werden, ein von The Linux Audit Demon („auditd„) erzeugtes Protokollereignis angezeigt wird. Die im Abschnitt „detection“ angegebenen Auswahlkriterien sind eine Reihe von Schlüssel-Wert-Paaren. Die Regel wird in diesem Beispiel nur ausgelöst, wenn der Feldtyp EXECVE ist und die übermittelten Argumente (a0, a1) „chattr -i“ enthalten:
Das False-Positives-Feld wird nicht von der SIEM-Anwendung verarbeitet, sondern dient dem SOC-Analysten als Indikator für Situationen, die False-Positives auslösen können und keine sofortige Abhilfe erfordern. Das Condition-feld legt fest, welche Bedingungen erfüllt sein müssen, damit das Ereignis ausgelöst wird. In diesem Fall folgt es einfach den Auswahlkriterien, aber das Condition-feld kann eine komplexere und detailliertere Regel ermöglichen, da die Verteidiger logische Operatoren wie AND/OR/NOT verwenden können, um verschiedene Bedingungen zu kombinieren.
Die nachstehende Regel würde beispielsweise nur dann ausgelöst, wenn die “ Selection“-Kriterien erfüllt sind, aber nicht, was der „Filter“ angibt. Der Sigma-Ausdruck sucht in den Windows-Protokollen nach dem Ereignis 4738: „Ein Benutzerkonto wurde geändert“, schlägt aber nur Alarm, wenn das Feld PasswordLastSet nicht Null ist.
In ähnlicher Weise können die Auswahlkriterien selbst detailliert und komplex werden und Wertmodifikatoren verwenden. Ein Beispiel für ein Auswahlkriterium, das den Modifikator „endswith“ verwendet, wird im folgenden Beispiel von Intezer [engl.] gezeigt:
Die Regel sucht nach den beiden Feldern „ParentImage“ und „Image“ und wird nur ausgelöst, wenn sowohl die Werte in den Feldern „ParentImage“ als auch in „Image“ mit den in den Kriterien angegebenen Zeichenfolgen enden. Die Werte für jedes dieser Felder werden jedoch im „Listenformat“ angegeben – und jeder dieser Werte für „ParentImage“ löst die Regel aus. Das heißt, die Regel wird ausgelöst, wenn Image auf \mshta.exe endet UND ParentImage auf \svchost.exe ODER cmd.exe ODER powershell.exe endet.
Beachten Sie, dass die unter den Objekten „List“ oder „Map“ angegebenen Elemente mit dem Operator „OR“ verknüpft werden, so dass die Erkennung einer der in einer List oder Map angegebenen Selektionen einen Alarm auslösen wird.
Bei Zeichenketten in Sigma wird die Groß- und Kleinschreibung standardmäßig nicht beachtet, jedoch wird die Groß- und Kleinschreibung beachtet, wenn sie reguläre Ausdrücke (regex) enthalten. Darüber hinaus sind Platzhalter wie „*“ und „?“ in den Erkennungskriterien zulässig und können bei Bedarf durch ein „\“ ersetzt werden.
Häufige Fehler bei Sigma-Regeln
Nicht wissen, wann Regeln zwischen Groß- und Kleinschreibung unterscheiden
Da bei Zeichenketten in Sigma-Regeln die Groß- und Kleinschreibung keine Rolle spielt, es sei denn, sie enthalten ein Regex-Muster, können Verteidiger, die mit dem Schreiben dieser Regeln nicht vertraut sind, versehentlich Fehler einfügen. Eine fehlerhafte Regel kann sich somit als verschwendete Arbeit und als Sicherheitslücke erweisen, da sie möglicherweise nicht wie erwartet ausgelöst wird.
Falsche Verwendung des Backslash
Eine weitere Fehlerquelle ist die inkorrekte Verwendung des Backslash beim Escapen von Zeichenketten, insbesondere die Verwendung einer falschen Anzahl von Backslashes. Dies ist besonders bei regulären Ausdrücken ein Problem.
In der Anleitung zur Erstellung von Regeln [engl.] wird eine Lösung zur Vermeidung dieses Problems erläutert. Fälle, in denen nur einzelne Backslashes verwendet werden, müssen nicht escaped werden.
Beispielsweise muss die Zeichenfolge C:\Windows\System32\cmd.exe nicht mit einem Schrägstrich versehen werden, und der einzelne Backslash wird als „einfacher“ Zeichenwert behandelt. Das heißt, dass Verteidiger einzelne Backslashes nicht durch das Schreiben von „C:\\Windows\\System32\\cmd.exe“ ersetzen sollten.
Ein praktisches Beispiel hierfür ist eine Sigma-Regel, die von Florian Roth selbst zur Verfügung gestellt wurde.
Die Regel warnt Sysadmins, wenn Instanzen des Kommandos „ping“ mit einer hexkodierten IP-Adresse versehen werden, möglicherweise um eine Entdeckung zu vermeiden. Beachten Sie die Verwendung von Platzhaltern (*) und die Tatsache, dass das „\“ nicht escaped wird.
Backslashes können jedoch verwendet werden, um Wildcards und eine Gruppe von Backslashes zu escapen. So werden beispielsweise „*„, „und“ und „?“ als Platzhalterzeichen behandelt, so dass es für Regelschreiber besser ist, „\*“ zu schreiben, wenn sie wortwörtlich einen Stern und nicht einen Platzhalteroperator einschließen wollen.
Außerdem heißt es im Leitfaden: „Wenn Sie zwei einfache Backslashes ausdrücken wollen, verwenden Sie vier davon: \\\\foo\\bar ergibt den Wert \\foo\bar…“, was bedeutet, dass Sie mit \\\\ zwei Backslashes in einer Zeichenkette erhalten. „Schreiben Sie \*, wenn Sie einen einfachen Platzhalter * als Ergebniswert haben wollen. Schreiben Sie \\*, wenn Sie einen einfachen Backslash gefolgt von einem Platzhalter * als Ergebnis haben wollen. Schreiben Sie \\\*, wenn Sie einen einfachen Schrägstrich gefolgt von einem einfachen * als Ergebniswert haben wollen“, heißt es in der Anleitung weiter.
Logikfehler durch unsachgemäße Bedienung
Achten Sie bei der Erstellung der Auswahlkriterien und der Condition, die zum Auslösen der Regel erforderlich ist, darauf, wie Ihr Ausdruck ausgewertet wird.
Die Erstellung eines Ausdrucks mit mehreren Ausdrücken unter Verwendung des OR-Operators, obwohl Ihre Logik eigentlich AND beinhalten sollte, kann eine Fülle von Fehlalarmen auslösen. Dies kann besonders schadhaft werden, wenn mehrere Auswahlkriterien (die eine Liste von Elementen enthalten) mit dem Condition-feld kombiniert werden, das diese Kriterien mit AND/OR/NOT kombiniert.
Schreiben und Validieren Ihrer Sigma Regeln
Syed Hasan, Spezialist für Bedrohungssuche und Analyst für Cyber-Bedrohungen, hat eine Schritt-für-Schritt-Anleitung [engl.] veröffentlicht, in der er erklärt, wie Sie Ihre Sigma-Regeln von Grund auf schreiben und kompilieren. Noch besser wäre es, wie Hasan vorschlägt, ein webbasiertes Tool wie Uncoder zu verwenden, insbesondere als Anfänger.
Der von SOC Prime herausgegebene Uncoder ermöglicht es Ihnen, Sigma-Regeln bequem von Ihrem Webbrowser aus zu schreiben, mit ihnen zu experimentieren, sie zu testen und zu kompilieren und Ihre Regeln sogar in SIEM-native Sprachen zu konvertieren.
Was die Validierung und das Testen betrifft, so bietet das offizielle Repository von Sigma eine Testsuite, mit der Sie Ihre Regeln validieren können. Wie der Cybersecurity-Ingenieur Ryan Plas jedoch zu Recht anmerkt, könnte die Suite für manche unvollständig sein. Die bereitgestellten Tests dienen als hilfreiche Ressource, sind aber keineswegs ein umfassendes Mittel zur Überprüfung der Einhaltung des Sigma-Schemas. Um die Testsuite auszuführen, müssen die Verteidiger diese manuell herunterladen und in ihrem Regelordner ablegen.
Tools wie sigmalint, entwickelt von Stage 2 Security, können dabei helfen. Sigmalint ist ein Open Source Kommandozeilen-Tool zur Validierung Ihrer Sigma-Regeln anhand des Sigma-Schemas. „Die Verwendung von sigmalint ist einfach. Sie können zwei Parameter übergeben: inputdir und method. inputdir ist das Verzeichnis, in dem sich Ihre Regeln befinden, und method ist das Validierungssystem, das Sie verwenden möchten (rx, jsonschema, s2)“, erklärt Plas. „Das Skript gibt dann einen Bericht darüber aus, wie viele Regeln gültig und ungültig sind und wie viele es nicht parsen konnte.“
Seit April dieses Jahres werden die von Sigma beigesteuerten Regeln anhand von Ereignisprotokolldaten, die von nicht kompromittierten Windows-Systemen gesammelt wurden, automatisch auf ihre Korrektheit hin überprüft.
Der Einstieg in die Arbeit mit Sigma-Regeln ist recht einfach, aber wie bei allem braucht man etwas Übung beim Schreiben, um sich mit anspruchsvolleren Syntaxen vertraut zu machen und seine Erkennungsmöglichkeiten zu verbessern.
*Ax Sharma ist ein erfahrener Cybersicherheitsexperte und Technologe, der es liebt, zu hacken, Ethik zu vermitteln und über Technologie zu schreiben, um ein breites Publikum aufzuklären.
Be the first to comment