Migrieren von Splunk-Erkennungsregeln zu Microsoft Sentinel

Splunk-Erkennungsregeln sind SIEM-Komponenten (Security Information and Event Management), die mit Analyseregeln in Microsoft Sentinel verglichen werden. Dieser Artikel beschreibt die Konzepte, die zur Identifizierung, Vergleichung und Migration von Splunk-Erkennungsregeln zu Microsoft Sentinel verwendet werden. Die beste Möglichkeit zum Migrieren von Splunk-Erkennungsregeln zu Microsoft Sentinel besteht darin, mit der SIEM-Migrationserfahrung zu beginnen, die sofort einsatzbereite (OOTB)-Analyseregeln für die automatische Übersetzung identifiziert.

Wenn Sie Ihre Splunk Observability-Bereitstellung migrieren möchten, erfahren Sie mehr darüber, wie Sie von Splunk zu Azure Monitor-Protokollen migrieren.

Überwachungsregeln

Microsoft Sentinel verwendet Machine Learning-Analysen, um hochgenaue und umsetzbare Incidents zu erstellen. Einige deiner bestehenden Splunk-Erkennungen könnten in Microsoft Sentinel redundant sein, daher sollte man nicht alle Splunk-Erkennungen blind migrieren. Überprüfen Sie die folgenden Überlegungen zur Regelüberwachung, während Sie Ihre vorhandenen Erkennungsregeln identifizieren.

• Stellen Sie sicher, dass Sie Anwendungsfälle auswählen, die die Migration von Regeln unter Berücksichtigung geschäftlicher Prioritäten und der Effizienz rechtfertigen.
• Vergewissern Sie sich, dass Sie Microsoft Sentinel Regeltypen verstehen.
• Überprüfen Sie, ob Sie die Regelterminologie verstehen.
• Überprüfen Sie veraltete Regeln, die in den letzten 6 bis 12 Monaten keine Warnungen enthalten, und ermitteln Sie, ob sie weiterhin relevant sind.
• Beseitigen Sie Bedrohungen oder Warnungen auf niedriger Ebene, die Sie routinemäßig ignorieren.
• Microsoft Sentinel Analytics erfordern, dass der Datentyp im Log Analytics-Arbeitsbereich vorhanden ist, bevor eine Regel aktiviert wird. Vergewissern Sie sich, dass Ihre erforderlichen Datenquellen verbunden sind, und überprüfen Sie die Datenverbindungsmethoden. Rufen Sie die Konversationen zur Datensammlung erneut auf, um die Datentiefe und -breite in den Anwendungsfällen sicherzustellen, die Sie erkennen möchten. Verwenden Sie dann die SIEM-Migrationsumgebung , um sicherzustellen, dass die Datenquellen ordnungsgemäß zugeordnet sind.

Migrieren von Regeln

Nachdem Sie die zu migrierenden Splunk-Erkennungen identifiziert haben, überprüfen Sie die folgenden Überlegungen zum Migrationsprozess:

• Vergleichen Sie die vorhandenen Funktionen der OOTB-Analyseregeln von Microsoft Sentinel mit Ihren aktuellen Anwendungsfällen. Verwenden Sie die SIEM-Migrationsumgebung , um zu sehen, welche Splunk-Erkennungen automatisch in OOTB-Vorlagen konvertiert werden.
• Übersetzen Sie Erkennungen, die nicht an OOTB-Analyseregeln ausgerichtet sind. Die beste Möglichkeit, Splunk-Erkennungen automatisch zu übersetzen, ist die SIEM-Migrationserfahrung.
• Entdecken Sie weitere Algorithmen für Ihre Anwendungsfälle, indem Sie Communityressourcen wie den SOC Prime Threat Detection Marketplace erkunden.
• Manuelles Übersetzen von Erkennungen, wenn integrierte Regeln nicht verfügbar sind oder nicht automatisch übersetzt werden. Erstellen Sie die neuen KQL-Abfragen, und überprüfen Sie die Regelzuordnung.

Weitere Informationen finden Sie unter Bewährte Methoden für die Migration von Erkennungsregeln.

Schritte zur Regelmigration

Führen Sie die folgenden Schritte aus, um jede Splunk-Erkennungsregel während der Migration zu Microsoft Sentinel zu überprüfen, zu übersetzen und zu testen.

1. Vergewissern Sie sich, dass für jede Zu migrierende Regel ein Testsystem vorhanden ist.

   1. Bereiten Sie einen Validierungsprozess für Ihre migrierten Regeln vor, einschließlich vollständiger Testszenarien und Skripts.

   2. Stellen Sie sicher, dass Ihr Team über nützliche Ressourcen zum Testen Der migrierten Regeln verfügt.

   3. Vergewissern Sie sich, dass die erforderlichen Datenquellen verbunden sind, und überprüfen Sie Ihre Datenverbindungsmethoden.

2. Überprüfen Sie, ob Ihre Erkennungen als OOTB-Vorlagen in Microsoft Sentinel verfügbar sind:

   • Verwenden Sie die SIEM-Migrationsumgebung , um die Übersetzung und Installation der OOTB-Vorlagen zu automatisieren.

     Weitere Informationen finden Sie unter Verwenden der SIEM-Migrationsumgebung.

   • Wenn Sie Anwendungsfälle haben, die in den Erkennungen nicht widerspiegelt sind, erstellen Sie Regeln für Ihren eigenen Arbeitsbereich mit OOTB-Regelvorlagen.

     Wechseln Sie in Microsoft Sentinel zum Content Hub.

     Inhaltstyp für Vorlagen für Analytics-Regeln filtern.

     Suchen und installieren/aktualisieren Sie jede entsprechende Content Hub-Lösung oder eigenständige Analyseregelvorlage.

     Weitere Informationen finden Sie unter Bedrohungen sofort erkennen.

   • Wenn Sie über Erkennungen verfügen, die nicht von den OOTB-Regeln Microsoft Sentinel abgedeckt werden, probieren Sie zunächst die SIEM-Migrationsumgebung für die automatische Übersetzung aus.

   • Wenn weder die OOTB-Regeln noch die SIEM-Migration die Erkennung vollständig übersetzen, erstellen Sie die Regel manuell. Führen Sie die folgenden Schritte aus, um Ihre Regel zu erstellen:

     1. Identifizieren Sie die Datenquellen, die Sie in Ihrer Regel verwenden möchten. Identifizieren Sie die Microsoft Sentinel Tabellen, die Sie abfragen möchten, indem Sie eine Zuordnungstabelle zwischen Datenquellen und Datentabellen erstellen.

     2. Identifizieren Sie alle Attribute, Felder oder Entitäten in Ihren Daten, die Sie in Ihren Regeln verwenden möchten.

     3. Identifizieren Sie Ihre Regelkriterien und -logik. Berücksichtigen Sie beim Identifizieren ihrer Regelkriterien und -logik die Verwendung von Regelvorlagen als Beispiele zum Erstellen Ihrer KQL-Abfragen.

        Berücksichtigen Sie Filter, Korrelationsregeln, aktive Listen, Verweissätze, Watchlists, Erkennungsanomalien, Aggregationen usw. Sie können Verweise verwenden, die von Ihrem Legacy-SIEM bereitgestellt werden, um zu verstehen , wie Sie Ihre Abfragesyntax am besten zuordnen.

     4. Identifizieren Sie die Triggerbedingung und die Regelaktion, erstellen und überprüfen Sie dann Ihre KQL-Abfrage. Berücksichtigen Sie beim Überprüfen Ihrer Abfrage die Ressourcen des KQL-Optimierungsleitfadens.

3. Testen Sie die Regel mit jedem Ihrer relevanten Anwendungsfälle. Wenn es keine erwarteten Ergebnisse liefert, überprüfen und bearbeiten Sie die KQL, und testen Sie sie erneut.

4. Wenn Sie zufrieden sind, können Sie die Regel als migriert betrachten. Erstellen Sie nach Bedarf ein Playbook für Ihre Regelaktion. Weitere Informationen finden Sie unter Automatisieren der Reaktion auf Bedrohungen mit Playbooks in Microsoft Sentinel.

Weitere Informationen zu Analyseregeln:

• Erstellen Sie benutzerdefinierte Analyseregeln, um Bedrohungen zu erkennen. Verwenden Sie die Warnungsgruppierung , um die Ermüdung von Warnungen zu reduzieren, indem Sie Warnungen gruppieren, die innerhalb eines bestimmten Zeitraums auftreten.
• Ordnen Sie Datenfelder Entitäten in Microsoft Sentinel zu, damit SOC-Techniker Entitäten als Teil des Nachweises definieren können, der während einer Untersuchung nachverfolgt werden soll. Die Entitätszuordnung ermöglicht es SOC-Analysten auch, ein intuitives [Untersuchungsdiagramm](investigation-cases.md#use-the-investigation-graph-to-deep-dive) zu nutzen, mit dem sie Zeit und Aufwand sparen können.
• Untersuchen Sie Vorfälle mit UEBA-Daten als Beispiel für die Verwendung von Beweismitteln, um im Vorschaufenster des Vorfalls Ereignisse, Warnungen und alle Lesezeichen einzublenden, die einem bestimmten Vorfall zugeordnet sind.
• Kusto-Abfragesprache (KQL), mit der Sie schreibgeschützte Abfragen an Ihre Log Analytics-Datenbank senden können, um Daten zu verarbeiten und Ergebnisse zurückzugeben. KQL wird auch für andere Microsoft-Dienste wie Microsoft Defender for Endpoint und Application Insights verwendet.

Vergleichen der Regelterminologie

In der folgenden Vergleichstabelle wird erläutert, wie eine KQL-basierte Regel in Microsoft Sentinel einer SPL-basierten Erkennung in Splunk entspricht.

Regelbeispiele abbilden und vergleichen

Verwenden Sie die SPL-zu-KQL-Beispieltabellen und Beispiele in diesem Abschnitt, um Regeln von Splunk auf Microsoft Sentinel in verschiedenen Szenarien zu vergleichen und zuzuordnen.

Vergleichen Sie gängige Splunk-Suchbefehle mit KQL-Beispielen

Diese Tabelle ordnet gängige SPL-Suchbefehle ihren KQL-Äquivalenten in Microsoft Sentinel zu.

lookup Befehl: KQL-Beispiel

Dieses KQL-Beispiel wird externaldata verwendet, um das SPL-Muster lookup zu replizieren, indem Benutzer gegen eine externe Datenquelle gefiltert werden.

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats Befehl: KQL-Beispiel

Dieses KQL-Beispiel wird verwendet summarize , um Transaktionen zu zählen und Gesamtsummen zu summieren, gruppiert nach Obst und Monat.

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats Befehl: KQL-Beispiel

Dieses KQL-Beispiel ordnet Metrikwerte in Preisklassen ein und zählt die Datensätze in jedem Bereich.

T | summarize count() by price_range=bin(price, 10.0) 

transaction Befehl: SPL-Beispiel

Dieses SPL-Beispiel fasst verwandte Start- und Stoppereignisse nach Aktivitäts-ID zu einer einzigen Transaktion zusammen.

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction Befehl: KQL-Beispiel

Dieses KQL-Beispiel repliziert die Gruppierung von SPL-Transaktionen, indem Start- und Stoppereignisse auf einer gemeinsamen Aktivitäts-ID verknüpft und die Dauer berechnet wird.

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

Verwenden Sie row_window_session() , um Sitzungsstartwerte für eine Spalte in einem serialisierten Zeilensatz zu berechnen.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats Befehl: SPL-Beispiel

Dieses SPL-Beispiel berechnet die Anzahl der Ereignisse pro Kategorie in Ein-Minuten-Bins und fügt dann eine Pro-Time-Bin-Summe mit .eventstats

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats Befehl: KQL-Beispiel

Hier sehen Sie ein Beispiel mit der join -Anweisung:

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Hier sehen Sie ein Beispiel mit der make_list -Anweisung:

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection Befehl: SPL-Beispiel

Dieses SPL-Beispiel erkennt Anomalien in historischen Schlusskursdaten über einen Zeitraum von 10 Jahren.

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection Befehl: KQL-Beispiel

Dieses KQL-Beispiel verwendet Zeitreihenanalysefunktionen, um Anomalien in Anmeldetrends für deaktivierte Konten über einen siebentägigen Rückblickzeitraum zu erkennen.

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Vergleichen Sie gängige Splunk-Befehle eval mit KQL-Äquivalenten

Diese Tabelle ordnet gängige SPL-Funktionen eval ihren KQL-Äquivalenten in Microsoft Sentinel zu.

case(X,"Y",…) SPL-Beispiel

Dieses SPL-Beispiel liefert eine andere Nachrichtenzeichenkette basierend auf dem HTTP-Fehlercode.

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) KQL-Beispiel

Dieses KQL-Beispiel verwendet case() die Zuweisung einer Nachricht basierend auf dem Wert des Fehlercodes.

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) KQL-Beispiel

Dieses KQL-Beispiel wird verwendet iif() , um zu kennzeichnen, ob ein Zeitstempel auf den aktuellen Tag fällt.

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) KQL-Beispiel

Dieses KQL-Beispiel prüft, ob X ein ganzzahlkompatibler Typ besitzt, indem es und iifverwendetgettype.

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) KQL-Beispiel

Dieses KQL-Beispiel prüft, ob X ein Zeichenkettenwert ist, indem es und iifverwendetgettype.

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") Beispiel

Diese KQL-Beispiele zeigen mehrere String-Matching-Operatoren, die man verwenden kann, um SPL-Musterabstimmung like zu replizieren.

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) KQL-Beispiel

Diese KQL-Beispiele zeigen verschiedene Methoden zur Berechnung von Mindestwerten unter Verwendung von min_of, min, und arg_min.

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) KQL-Beispiel

Dieses KQL-Beispiel filtert mv-apply und reduziert mehrwertige Inhalte, ähnlich wie die SPL-Funktion mvfilter .

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) KQL-Beispiel

Dieses KQL-Beispiel verwendet, strcat_array um Array-Elemente zu einer einzigen Zeichenkette mit einem benutzerdefinierten Separator zu verbinden.

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) KQL-Beispiel

Dieses KQL-Beispiel wandelt einen Datumszeitwert in Unix-Epochenzeit um für relativzeitliche Berechnungen.

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) KQL-Beispiel

Dieses KQL-Beispiel verwendet replace() mit einem Regex-Muster, um die Monats- und Tagesteile einer Datumsreihe zu tauschen.

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) KQL-Beispiel

Dieses KQL-Beispiel wird format_datetime verwendet, um nur die Stunden und Minuten eines Date-Time-Werts anzuzeigen.

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() KQL-Beispiel

Dieses KQL-Beispiel formatiert einen Datetime-Wert als Zeitzeichen, die Stunden, Minuten und Sekunden anzeigt.

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y) Beschreibung

Die SPL-Funktion tostring(X,Y) wandelt Werte in Zeichenketten um und unterstützt mehrere Formatierungsoptionen. Es gibt einen Feldwert von als X Zeichenkette zurück.

• Wenn der Wert von X eine Zahl ist, X wird in einen Zeichenfolgenwert neu formatiert.
• Wenn X ein boolescher Wert ist, X wird in TRUE oder FALSEneu formatiert.
• Wenn X eine Zahl ist, ist das zweite Argument Y optional und kann entweder hex sein (konvertiert X in ein Hexadezimal), commas (Formate X mit Kommas und zwei Dezimalstellen) oder duration (konvertiert X von einem Zeitformat in Sekunden in ein lesbares Zeitformat: HH:MM:SS).

tostring(X,Y) SPL-Beispiel

Dieses tostring SPL-Beispiel liefert:

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) SPL-Beispiel

Dieses SPL-Beispiel dekodiert einen URL-kodierten String wieder in seine ursprüngliche Form.

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

Vergleichen Sie gängige Splunk-Befehle stats mit KQL-Äquivalenten

Diese Tabelle bildet gängige SPL-Aggregationsfunktionen stats ihren KQL-Äquivalenten in Microsoft Sentinel zu.

Nächste Schritte

Sie haben erfahren, wie Sie Splunk-Erkennungsregeln identifizieren, vergleichen und den Microsoft Sentinel-Analyseregeln zuordnen. Fahren Sie mit der Migration Ihrer SOAR-Automatisierung fort.