Folgen Die Portabilität von Erkennungsregeln ist die Praxis, Bedrohungserkennungslogik so zu schreiben und zu verwalten, dass sie ohne komplette Neuschreibung über SIEM-, EDR- und XDR-Plattformen hinweg übertragen wird.
Was passiert mit meinen Erkennungsregeln, wenn ich zu einer neuen SIEM-Plattform migriere?
Regeln, die in der nativen Abfragesprache einer Plattform geschrieben sind, lassen sich nicht übertragen. SPL bleibt in Splunk. KQL bleibt in Microsoft Sentinel. YARA-L bleibt in Google SecOps. Bei einer Migration müssen diese Regeln neu geschrieben oder für die Zielplattform übersetzt werden.
Die Treue der Übersetzung hängt vom Konstrukt ab, nicht vom Sprachpaar. Zwei Verschlechterungsachsen entscheiden, was erhalten bleibt.
Achse 1: Feldzuordnung. Quellfeld-Taxonomien (CIM, ASIM, ECS, OCSF, Sysmon-native, herstellerspezifisch) werden unvollständig zugeordnet. Ein nicht zugeordnetes oder umbenanntes Feld verengt oder bricht die Regel stillschweigend.
Achse 2: Konstruktsemantik. Aggregation und Zeitfenstersemantik, Sequenz- oder Transaktionslogik, Regex-Dialekt und eval/lookup/join-ähnliche Funktionen haben oft nur partielle Entsprechungen auf der Zielplattform. Diese Achse trägt den Anteil des Neuschreibens.
Sigma Regeln sind für die Übersetzung ausgelegt. Sie werden einmal erstellt und pro Backend über pySigma, sigma-clioder Uncoderübersetzt.
Übersetzung ist keine Erhaltung. Jede übersetzte Regel erfordert noch eine backendspezifische Validierung gegen die geparsten Felder der Zielplattform, bevor sie vertrauenswürdig ist. Eine syntaktisch korrekte Übersetzung kann auf Felder verweisen, die die neue Plattform nie füllt.
Die Weiterleitung der Telemetrie-Pipeline ist ein separates Verfahren. Die Weiterleitung eines Protokollstroms an ein neues Ziel überträgt nicht die Erkennungslogik, die darauf lief. SPL bleibt SPL, unabhängig davon, wohin die Protokolle gelangen.
Was ist der Unterschied zwischen herstellerspezifischen und herstellerneutralen Erkennungsregeln?
Eine herstellerspezifische Regel ist ein Asset der Plattform. Eine herstellerneutrale Regel ist ein Asset des Teams.
| Dimension | SPL (Splunk) | KQL (Microsoft Sentinel) | YARA-L (Google SecOps) | Sigma |
|---|---|---|---|---|
| Läuft nativ auf | Splunk | Microsoft Sentinel | Google SecOps | Keine direkt. Wird in alle drei sowie IBM QRadar, Elastic, CrowdStrike und andere übersetzt. |
| Die Verschiebung erfordert | Neuschreiben in der Zielsprache | Neuschreiben in der Zielsprache | Neuschreiben in der Zielsprache | Übersetzung über pySigma/sigma-cli oder Uncoder, dann Feldzuordnungsvalidierung |
| Wem gehört es | Die Splunk-Bereitstellung | Der Sentinel-Arbeitsbereich | Der SecOps-Mandant | Ihr Team, unter Versionskontrolle |
| Mehrplattform-Kosten | N Kopien schreiben | N Kopien schreiben | N Kopien schreiben | Einmal pro Backend übersetzen, einmal pro Backend validieren |
Der Kostenunterschied zeigt sich bei der Migration und beim Mehrplattformbetrieb. Herstellerneutrale Erkennungslogik bleibt über Ihre gesamte Infrastruktur hinweg portabel.
Wie migriere ich Erkennungsinhalte von Splunk zu Microsoft Sentinel?
Sechs Schritte. Dies ist eines der schwierigeren Sprachpaare, da sich SPL und KQL hinsichtlich Datenmodell, Feldbenennung und Funktionssemantik unterscheiden.
- SPL-Regeln inventarisieren. Exportieren Sie jede gespeicherte Suche, jeden Alarm und jede Korrelationssuche. Notieren Sie die Datenmodellabhängigkeiten jeder Regel (Sourcetype, Index, Feldnamen).
- Nach Konstrukttyp klassifizieren. Sortieren Sie Regeln in drei Kategorien: einfache Auswahllogik (wird sauber portiert), feldzuordnungsabhängig (wird mit Mapping-Arbeit portiert) und Korrelations-/zustandsabhängige Logik (erwarten Sie eine manuelle Neuschreibung).
- Über Sigma übersetzen. Konvertieren Sie SPL-Regeln in Sigma, dann übersetzen Sie Sigma in KQL mit pySigma über das Microsoft Sentinel-Backend, sigma-cli oder Uncoder. Dies behandelt die Syntax. Es behandelt nicht die Feldzuordnung.
- Felder gegen das Sentinel-Schema abbilden. Richten Sie CIM-Feldnamen auf ASIM-Äquivalente aus. Microsoft dokumentiert ihr Schema unter learn.microsoft.com. Jedes Feld in der übersetzten Regel muss in einer Spalte in der Zieltabelle aufgelöst werden.
- Auf Sentinel-Tabellen testen. Führen Sie jede übersetzte Regel gegen wirklich ingestierte Daten aus. Behalten Sie ein Testereignis pro Regel, um die Übereinstimmung nach jeder Schemaänderung zu überprüfen.
- Übergang mit einem Parallelbetrieb-Fenster. Führen Sie beide Plattformen auf denselben Protokollquellen aus. Vergleichen Sie die Alarmausgabe. Setzen Sie die SPL-Version erst außer Betrieb, wenn die KQL-Version bei denselben Ereignissen auslöst.
Vor dem Übergang, kartieren Sie die eingesetzten Regeln auf beiden Plattformen auf MITRE ATT&CK Techniken und vergleichen Sie die beiden Karten, sodass eine Technik, die bei der Migration ausfällt, vor dem Übergang bemerkt wird, nicht danach; SOC Prime’s MITRE ATT&CK Audit kartiert eingesetzte Erkennungen und Datenquellen auf ATT&CK als Dienstleistung.
Migrieren Sie eine Regelsammlung? Erforschen Sie SOC Prime’s Prime Architect zur plattformübergreifenden Regelübersetzung, Bedrohungsforschung und Erkennungs-Engineering-Workflows.
Was sind die besten Praktiken zur Übersetzung von Abfragesprachen wie SPL zu KQL?
Übersetzen Sie Logik, nicht Syntax. Ein Zeichen-für-Zeichen-Port erzeugt fragile Regeln, die auf Felder verweisen, die das Ziel möglicherweise nicht füllt.
- Felder gegen das Zielschema abbilden. Gehen Sie nicht davon aus, dass sich Feldnamen übertragen. Splunk CIM und Sentinel ASIM sind unterschiedliche Vereinbarungen. Der Aufwand bei der Migration liegt im Mapping zwischen ihnen.
- Behalten Sie ein Testereignis pro Regel. Ein bekannt schlechtes Ereignis gepaart mit einem bekannten harmlosen Ereignis. Wenn die übersetzte Regel nicht das Schlechte übereinstimmt und das Harmlos ablehnt, ist während der Übersetzung etwas schiefgelaufen.
- Überprüfen Sie alles, was der Übersetzer kennzeichnet. Automatisierte Übersetzer handhaben einfache Auswahllogik gut. Korrelationsregeln, proprietäre Funktionen und komplexe Aggregationen benötigen menschliche Überprüfung.
- Benennen Sie Ihre Werkzeuge. Prime Architect übersetzt Sigma in 65 Erkennungssprachen, migriert zwischen nativen Abfragesprachen wie SPL und KQL, wendet Feldzuordnungsvoreinstellungen für die verbundene Umgebung an und stellt aus einem verwalteten Regelrepository in eine unterstützte Zielplattform bereit. Die Open-Source-Version Uncoder IO deckt den Übersetzungsschritt ab und kann selbst gehostet werden (Quelle auf GitHub). Keine der drei eliminiert die Feldzuordnungsvalidierung.
Beispiel: eine einfache Prozess-Erstellungsregel, die EventCode=4688 und New_Process_Name (Splunk CIM) in EventID == 4688 und NewProcessName (Sentinel SecurityEvent-Table) übersetzt. Gleiche Tatsache, unterschiedliche Feldnamen pro Plattformvertrag.
Das SPL nachlaufende verankerte Wildcard wird zu einem KQL endswith-Operator. Dieses Paar funktioniert, weil es ein Einzelfeldausdrück ist. Korrelationsregeln lassen sich nicht so sauber übersetzen.
Wie lange dauert es, eine Regelsammlung zu migrieren und was treibt das?
Drei Faktoren bestimmen den Aufwand.
Regelanzahl. Mehr Regeln, mehr Validierungszyklen. Jede übersetzte Regel benötigt einen Testrun gegen die ingesetzten Daten des Ziels.
Benutzerdefinierte Felder und Datenmodellabhängigkeiten. Regeln, die herstellerspezifische Felder, benutzerdefinierte Extraktionen oder Lookuptabellen referenzieren, erfordern Mapping-Arbeit pro Feld. Je mehr Anpassungen in der Quelle, desto mehr Handarbeit bei der Migration.
Validierungsaufwand. Jede übersetzte Regel muss gegen die geparsten Felder der Zielplattform validiert werden. Eine syntaktisch korrekte Übersetzung kann stillschweigend fehlschlagen, wenn das Zielschema das referenzierte Feld nicht füllt.
Das ehrliche Ergebnis einer Migrationsbewertung ist eine pro Regel Klassifizierung: portiert sauber, portiert mit Mapping-Arbeit, oder erfordert eine manuelle Neuschreibung. Eine einzige Zeitabschätzung für die gesamte Bibliothek stellt den Verteilungsaufwand falsch dar.
Wie vermeidet man beim nächsten Mal Lock-in?
Drei Praktiken.
- Autor in Sigma. Schreiben Sie von Anfang an herstellerneutrale Erkennungslogik. Sigma-Regeln werden zu jeder großen SIEM-, EDR- und XDR-Plattform übersetzt. Erkennungsinhalte, die bereits in Sigma vorliegen, wie die Sigma-Regeln in SOC Prime’s Core, halten die Bibliothek vom ersten Regel an portabel.
- Halten Sie die Logik unter Versionskontrolle. Speichern Sie Ihre Erkennungsregeln in Git zusammen mit den Feldzuordnungen und Testereignissen für jedes Ziel-Backend. Die Regeln reisen mit dem Team, nicht mit der Plattform.
- Bei Bereitstellung übersetzen. Verwenden Sie pySigma, sigma-cli oder Uncoder, um plattformnative Abfragen zur Bereitstellungszeit zu erzeugen. Die Quelle bleibt portabel. Das kompilierte Ergebnis ist entbehrlich.
Diese Trennung bedeutet, dass eine Plattformmigration das Übersetzungsziel ändert, nicht die Erkennungslogik.
Ist die Weiterleitung von Telemetrie durch eine Pipeline dasselbe wie das Portieren Ihrer Erkennungen?
Nein. Eine Telemetrie-Pipeline (Cribl und ähnliche Tools) verschiebt Daten. Sie verschiebt nicht die darauf laufende Erkennungslogik.
Das Weiterleiten eines Protokollstroms von Splunk zu Microsoft Sentinel durch eine Pipeline liefert die Ereignisse an ein neues Ziel. Die SPL-Regeln, die auf diesen Ereignissen in Splunk ausgeführt wurden, folgen nicht. SPL bleibt SPL. Die Erkennungslogik muss noch für die Zielplattform übersetzt oder neu geschrieben werden.
Pipeline-Routing löst das Datenübermittlungsproblem. Die Portabilität von Erkennungen löst das Logikübersetzungsproblem. Sie sind unabhängig. Ein Team, das Telemetrie zu einem neuen SIEM leitet, ohne seine Erkennungen zu portieren, hat Daten an einem neuen Ort und keine Regeln, um sie abzugleichen.
Die Ausnahme ist eine Pipeline, die die Erkennungen selbst ausführt: SOC Prime’s Prime Detect wendet Regeln in Sigma auf der Pipelineschicht vor dem SIEM an, und seine Open-Source-Ausgabe ist auf GitHub.
Wo dies nicht zutrifft
Nicht alles übersetzt, selbst mit Sigma. Vier Konstruktklassen erfordern Handneuschreibungen auf der Zielplattform.
- Korrelation und zustandsabhängige Logik. Anzahl- und Wertaggregation, temporale Sequenz, Multi-Event-Korrelation. Sigma hat in seiner v2-Spezifikation Korrelationsregeltypen hinzugefügt, aber die Backends-Unterstützung variiert je nach pySigma-Backend. Geplante versus Streaming-Ausführung verändert auch, was eine Regel ausdrücken kann.
- Proprietäre Funktionen. Splunk-Transaktion, eval-Ausdrücke, lookups basierte Anreicherung, Makros. KQL-Entsprechungen sind teilweise.
- Einige Aggregationsmuster. Schwellenwert-über-Fenster-Konstrukte und stats … by … span= Muster übersetzen sich ungleichmäßig über Plattformen hinweg.
- Schemaabhängige Feldreferenzen. Die gleiche Sigma-Prozess-Erstellungsregel bezieht sich auf ein unterschiedliches Feld abhängig von der Pipeline. Bei Sysmon ist es Image. Bei Splunk Windows Security ist es New_Process_Name. Die Übersetzung ist nur gegen das tatsächlich bereitgestellte Schema korrekt.
Diese Konstrukte sind dort am relevantesten, wo die pro Regel-Klassifizierung am meisten zählt. Erwarten Sie, dass sie manuelle Validierung und in vielen Fällen eine von Grund auf neue Neuschreibung erfordern.
Checkliste für Migrationsbereitschaft
[ ] Volles Regel-Inventory exportiert (gespeicherte Suchen, Alarme, Korrelationssuchen)
[ ] Jede Regel klassifiziert: portiert sauber / portiert mit Mapping / Neuschreibung erforderlich
[ ] Feldzuordnungstabelle erstellt: Quellschema zu Zielschema
[ ] Sigma-Versionen tragbarer Regeln erstellt und unter Versionskontrolle gespeichert
[ ] Übersetzungstools ausgewählt (pySigma/sigma-cli, Uncoder oder beide)
[ ] Testereignispaare pro Regel erstellt (eins bekannt-schlecht, eins bekannt-harmlos)
[ ] Übersetzte Regeln mit real injizierten Daten gegen Zieltabellen validiert
[ ] Korrelations- und Zustandsregeln zur manuellen Neuschreibung identifiziert
[ ] Proprietäre Funktionen katalogisiert (Transaktion, eval, Lookups, Makros)
[ ] Parallel-Betriebsfenster definiert: Beide Plattformen injizieren die gleichen Quellen
[ ] Alarmausgabe-Vergleichskriterien dokumentiert
[ ] Rückrollplan definiert: Bedingungen für die Rückkehr zur Quellplattform
FAQ
Was passiert mit meinen Erkennungsregeln, wenn ich zu einer neuen SIEM-Plattform migriere?
Plattformnative Regeln reisen nicht. SPL, KQL und YARA-L müssen für die Zielplattform neu geschrieben oder übersetzt werden. Eine Regel in Sigma erstellt wird einmal pro Backend übersetzt und jede übersetzte Regel muss noch gegen die geparsten Felder der Zielplattform validiert werden. Korrelation, zustandsabhängige Logik, proprietäre Funktionen und einige Aggregationsmuster übersetzen sich nicht sauber.
Wie migriere ich Erkennungsinhalte von Splunk zu Microsoft Sentinel?
Inventarisiere die SPL-Regeln, klassifiziere jede nach Konstrukttyp, übersetze durch Sigma mit pySigma oder Uncoder, ordne Felder vom Splunk-Schema zum Sentinel-Schema zu, teste jede Regel mit real injizierten Sentinel-Daten, dann wechsle mit einem Parallelbetrieb-Fenster, bevor die SPL-Version außer Dienst gestellt wird. Microsoft dokumentiert das Sentinel-Schema unter learn.microsoft.com.
Was ist der Unterschied zwischen herstellerspezifischen und herstellerneutralen Erkennungsregeln?
Eine herstellerspezifische Regel ist ein Asset der Plattform, auf der sie läuft. Eine in Sigma erstellte herstellerneutrale Regel ist ein Asset des Teams, unter Versionskontrolle gehalten und pro Backend übersetzt. Der Kostenunterschied zeigt sich bei Migration und beim Mehrplattformbetrieb.
Macht die Weiterleitung von Telemetrie durch eine Pipeline meine Erkennungen portabel?
Nein. Eine Telemetrie-Pipeline bewegt Daten zu einem neuen Ziel. Sie bewegt nicht die Erkennungslogik, die darauf lief. SPL bleibt SPL, wo auch immer die Protokolle landen, sodass die Regeln noch übersetzt oder neu geschrieben werden müssen.
Was sind die besten Praktiken zur Übersetzung einer Abfragesprache wie SPL zu KQL?
Übersetzen Sie die Logik, nicht die Syntax. Ordnen Sie jedes Feld dem Zielschema zu, halten Sie ein bekannt-schlechtes und ein bekannt-harmloses Testereignis pro Regel bereit und überprüfen Sie alles, was der Übersetzer kennzeichnet, da Korrelationsregeln und proprietäre Funktionen menschliche Überprüfung erfordern. pySigma, sigma-cli und Uncoder handhaben die Sigma-Übersetzung, und keines von ihnen entfernt die Feldzuordnungsvalidierung.
Bewerten Sie Ihre vorhandene SIEM-Abdeckung und erstellen Sie einen Plan für Ihren Übergang mit Hilfe von Prime Hunt. Prime Hunt überprüft alle Ihre SIEM-Regeln, identifiziert Lücken und macht einen Plan, um eine vollständige Abdeckung zu erreichen – kritische Arbeit vor einer SIEM-Migration.
