Eine Sigma-Regel für eine CVE oder Technik schreiben: vom Verhalten zur Erkennung, die das SOC nicht ertränkt

Ein Bericht beschreibt eine neue Technik: die Ausnutzung einer CVE, den Missbrauch einer legitimen System-Binärdatei, ein Post-Exploitation-Verhalten. Sie wollen wissen, ob es in Ihrer Umgebung geschieht. Sigma ist das Pivot-Format dafür: ein lesbares YAML, SIEM-unabhängig, das Sie einmal schreiben und nach Splunk, Elastic oder Sentinel konvertieren. Doch die Regel zu schreiben ist eine Sache; eine Regel zu schreiben, die auf das echte Verhalten auslöst, ohne das SOC unter Fehlalarmen zu begraben, eine andere.

Ein wichtiger Punkt vorweg: Sigma erkennt ein Verhalten in Logs, keine Schwachstelle auf der Leitung. Für eine CVE heißt das, die Ausnutzung zu erkennen (was der Angriff auf dem Host tut (ein gestarteter Prozess, ein geänderter Registry-Schlüssel, ein charakteristisches Kommando)) nicht die Schwachstelle selbst. Dieser Artikel zeigt, wie man von einem beschriebenen Verhalten zu einer Regel kommt, die in der Produktion hält, und wie man es beweist.

Der Aufbau einer Sigma-Regel

Eine Sigma-Regel besteht aus wenigen Blöcken:

title: Verdächtige MSHTA-Ausführung aus einem temporären Verzeichnis
id: 7c9d2e10-4a3b-4f8e-9c1a-000000000000
status: experimental
description: Erkennt mshta.exe, das ein Skript aus einem temporären Pfad startet, eine nach der Ausnutzung beobachtete Ausführungstechnik.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\mshta.exe'
        CommandLine|contains:
            - '\Temp\'
            - '\AppData\Local\Temp\'
    filter_legit:
        ParentImage|endswith: '\msiexec.exe'
    condition: selection and not filter_legit
falsepositives:
    - Legitime Software-Bereitstellungen über MSI
level: high
tags:
    - attack.execution
    - attack.t1218.005

Der logsource sagt, wo zu suchen ist (hier Windows-Prozesserstellungs-Ereignisse). Der detection-Block kombiniert eine selection (die Kriterien, die die Technik charakterisieren) und oft einen filter (was auszuschließen ist). Die condition fügt alles zusammen. Die Felder falsepositives, level und tags sind keine Dekoration: Sie machen die Regel triagierbar und für das SOC nutzbar.

Der Logsource ist die halbe Arbeit

Eine Sigma-Regel ist nur etwas wert, wenn die Daten, die sie abfragt, existieren. Zwei Fallen, noch bevor Sie die detection schreiben:

• Die richtige Kategorie. process_creation, registry_event, network_connection… die falsche zu wählen heißt, eine Regel zu schreiben, die nie auf die richtigen Ereignisse zutrifft.
• Ihre tatsächliche Telemetrie. Protokolliert Ihre Sysmon-Konfiguration keine Kommandozeilen, löst keine auf CommandLine basierende Regel aus, so korrekt sie auch ist. Erkennung beginnt bei der Erfassung: Stellen Sie sicher, dass Ihre Logs das Feld enthalten, von dem Sie abhängen.

Vom Verhalten ausgehen, nicht von einer kopierten Regel

Wie bei jeder Erkennung ist der Ausgangspunkt die Tatsache, nicht der Ausdruck eines anderen. Ein Analysebericht beschreibt das Beobachtbare: den gestarteten Prozess, seinen Elternprozess, das charakteristische Argument, den geschriebenen Schlüssel. Diese Tatsache gehört niemandem, die daraus abgeleitete Regel ist Ihr Werk. Eine unter Copyleft-Lizenz oder ohne Lizenz veröffentlichte Regel in ein geschlossenes oder weiterverkauftes Set zu kopieren, würde hingegen dessen Rechte kontaminieren.

Konkret: Lesen Sie den Bericht, isolieren Sie die minimale, zuverlässige Aktion, die die Technik beweist, und bauen Sie die selection darum herum, nicht um alles, was der Angreifer tat, nur um das unterscheidungsstärkste Zeichen.

Die Fehlalarm-Disziplin

Hier scheitern die meisten Regeln in der Produktion. Eine zu breite selection (CommandLine|contains: 'powershell') löst tausendfach am Tag bei legitimer Aktivität aus. Drei Reflexe:

• Verengen Sie die Selektion. Kombinieren Sie mehrere Felder (Image und CommandLine und ParentImage) statt eines einzigen vagen Musters.
• Filtern Sie das bekannt Legitime. Der filter-Block entfernt saubere Verwendungen, die sonst trotzdem passen würden (ein Admin-Tool, eine MSI-Bereitstellung). Das Feld falsepositives dokumentiert den Rest.
• Hüten Sie sich vor häufigen Tokens. Ein einzelnes Wort, das in Authentifizierungsereignissen oder banalen Dienstnamen vorkommt, erzeugt einen Alarmsturm. Bevorzugen Sie stets eine spezifische Kombination gegenüber einem einzelnen Token.

ATT&CK zuordnen

Füllen Sie die tags mit der MITRE-ATT&CK-Taktik und -Technik (attack.execution, attack.t1218.005). Das ist nicht kosmetisch: Es erlaubt dem SOC, zu triagieren, seine Abdeckung zu messen und die Regel mit dem Rest seiner Erkennung zu korrelieren. Eine Regel ohne ATT&CK-Tag ist eine verwaiste Regel.

Validieren genügt nicht: man muss beweisen

Die pySigma-Werkzeuge prüfen Syntax und Konsistenz:

sigma check regel.yml

Aber „gültig" bedeutet nicht „löst im richtigen Moment aus". Der Beweis ist empirisch, in zwei Schritten:

1. Löst die Regel bei der echten Technik aus? Konvertieren Sie sie in Ihr SIEM (über das pySigma-Backend), lösen Sie die Technik in einer Testumgebung aus (ein Projekt wie Atomic Red Team spielt Hunderte ATT&CK-Techniken kontrolliert nach) und bestätigen Sie dann, dass der Alarm erscheint. Löst nichts aus, ist die Regel nutzlos.
2. Wie viel Rauschen bei normalem Verkehr? Lassen Sie die konvertierte Regel über einen Tag echter, gutartiger Logs laufen. Die Zahl der Treffer sagt Ihnen, ob sie einsetzbar ist oder den Analysten ertränkt.

Eine Regel, die bei der Technik auslöst und im Alltag ruhig bleibt, ist unendlich viel mehr wert als eine bloß „gültige". Das ist der Unterschied zwischen „kompiliert" und „erkennt, bewiesen".

Die Fallen, die teuer werden

• Das einzelne Token bei einem häufigen Ereignis. Die häufigste Ursache für Fehlalarm-Stürme. Kombinieren Sie; verlassen Sie sich nie auf ein einzelnes Wort.
• Der falsche Logsource. Eine unter der falschen Kategorie abgelegte Regel trifft auf nichts zu, ein stiller Fehlalarm im Umkehrschluss.
• Die Feldnamen. Nach der Konvertierung wird Image in ECS zu process.executable, anderswo zu etwas anderem. Prüfen Sie, dass das Mapping zu Ihrem Schema passt, sonst trifft die Abfrage auf nichts.
• Die zu breite Selektion. Ein einziges vages contains in der Produktion, und das SOC ruft Sie binnen einer Stunde zurück.

Zusammenfassung

Eine gute Sigma-Regel für eine CVE oder Technik zu schreiben ist eine Methode: die Ausnutzung erkennen (das Verhalten in Logs, nicht die Schwachstelle), von der Tatsache im Bericht ausgehen, die Selektion verengen und das Legitime filtern, ATT&CK zuordnen und empirisch beweisen, dass die Regel bei der Technik auslöst, ohne den Alltag zu ertränken. Der Rest (Syntaxvalidierung, Tags, Level) ist Hygiene.

Genau diese Disziplin wenden wir in großem Maßstab im Sigma-Feed von ThreatClaw an: jede Regel wird auf ihr echtes Auslösen getestet, ATT&CK zugeordnet und bereit zur Konvertierung in Ihr SIEM ausgeliefert. Sie erhalten die Erkennung, kein YAML, das Sie erst noch erproben müssen.