Migrieren von ArcSight-Erkennungsregeln zu Microsoft Sentinel
In diesem Artikel erfahren Sie, wie Sie Ihre ArcSight-Erkennungsregeln identifizieren, vergleichen und zu den Microsoft Sentinel-Analyseregeln migrieren können.
Identifizieren und Migrieren von Regeln
Von Microsoft Sentinel werden aus maschinellem Lernen gewonnene Analysen dazu verwendet, hochwertige und praktisch verwertbare Incidents zu erstellen; einige Ihrer vorhandenen Erkennungen sind in Microsoft Sentinel möglicherweise redundant. Migrieren Sie daher nicht einfach unbedacht alle Erkennungs- und Analyseregeln. Überdenken Sie diese Aspekte, während Sie Ihre vorhandenen Erkennungsregeln identifizieren.
- Achten Sie darauf, dass Sie Anwendungsfälle auswählen, die die Regelmigration unter Berücksichtigung von Geschäftspriorität und Effizienz rechtfertigen.
- Stellen Sie sicher, dass Sie die Microsoft Sentinel-Regeltypen verstehen.
- Stellen Sie sicher, dass Sie die Regelterminologie verstehen.
- Überprüfen Sie alle Regeln, durch die in den letzten 6 bis 12 Monaten keine Warnungen ausgelöst wurden, und bestimmen Sie, ob sie weiterhin relevant sind.
- Beseitigen Sie Bedrohungen oder Warnungen mit niedrigem Schweregrad, die Sie routinemäßig ignorieren.
- Verwenden Sie vorhandene Funktionen, und überprüfen Sie, ob die integrierten Analyseregeln von Microsoft Sentinel für Ihre aktuellen Anwendungsfälle geeignet sind. Da von Microsoft Sentinel aus maschinellem Lernen gewonnene Analysen dazu verwendet werden, hochwertige und praktisch verwertbare Vorfälle zu erzeugen, ist es wahrscheinlich, dass einige Ihrer bestehenden Erkennungen nicht mehr benötigt werden.
- Vergewissern Sie sich, dass die Datenquellen verbunden sind, und überprüfen Sie die Datenverbindungsmethoden. Gehen Sie erneut die Konversationen zur Datensammlung durch, um die Datentiefe und -breite für die zu erkennenden Anwendungsfälle sicherzustellen.
- Erkunden Sie Communityressourcen wie den SOC Prime Threat Detection Marketplace, um zu überprüfen, ob Ihre Regeln verfügbar sind.
- Überlegen Sie, ob möglicherweise ein Onlineabfragekonverter wie Uncoder.io für Ihre Regeln in Frage kommt.
- Wenn Regeln nicht verfügbar sind oder nicht konvertiert werden können, müssen sie mithilfe einer KQL-Abfrage manuell erstellt werden. Überprüfen Sie die Regelzuordnung, um neue Abfragen zu erstellen.
Erfahren Sie mehr über bewährte Methoden zum Migrieren von Erkennungsregeln.
Migrieren von Analyseregeln zu Microsoft Sentinel:
Stellen Sie sicher, dass für jede Regel, die Sie migrieren möchten, ein Testsystem vorhanden ist.
Konzipieren Sie einen Überprüfungsprozess für die migrierten Regeln, einschließlich vollständiger Testszenarios und Skripts.
Stellen Sie sicher, dass Ihr Team über nützliche Ressourcen verfügt, damit die migrierten Regeln getestet werden können.
Vergewissern Sie sich, dass alle erforderlichen Datenquellen verbunden sind, und überprüfen Sie die Datenverbindungsmethoden.
Überprüfen Sie, ob die Erkennungen als integrierte Vorlagen in Microsoft Sentinel verfügbar sind:
Wenn die integrierten Regeln ausreichend sind, verwenden Sie integrierte Regelvorlagen, um Regeln für Ihren eigenen Arbeitsbereich zu erstellen.
Öffnen Sie in Microsoft Azure Sentinel die Registerkarte Konfiguration > Analytics > Regelvorlagen, um die jeweils relevante Analyseregel zu erstellen und zu aktualisieren.
Weitere Informationen finden Sie unter Standardmäßig verfügbare Erkennung von Bedrohungen.
Wenn Sie über Erkennungen verfügen, die nicht durch die integrierten Regeln von Microsoft Sentinel abgedeckt sind, versuchen Sie es mit einem Onlineabfragekonverter wie Uncoder.io, um Ihre Abfragen in KQL zu konvertieren.
Identifizieren Sie die Auslöserbedingung und die Regelaktion, und erstellen und überprüfen Sie dann die KQL-Abfrage.
Wenn weder die integrierten Regeln noch ein Onlineregelkonverter ausreichend sind, müssen Sie die Regel manuell erstellen. Führen Sie in solchen Fällen die folgenden Schritte aus, um mit der Erstellung der Regel zu beginnen:
Identifizieren Sie die Datenquellen, die Sie in der Regel verwenden möchten. Sie sollten eine Zuordnungstabelle zwischen Datenquellen und Datentabellen in Microsoft Sentinel erstellen, um die Tabellen zu identifizieren, die Sie abfragen möchten.
Identifizieren Sie alle Attribute, Felder oder Entitäten in den Daten, die Sie in den Regeln verwenden möchten.
Identifizieren Sie die Regelkriterien und die Logik. In dieser Phase sollten Sie Regelvorlagen als Beispiele zum Erstellen der KQL-Abfragen verwenden.
Berücksichtigen Sie Filter, Korrelationsregeln, aktive Listen, Verweissätze, Watchlists, Erkennungsanomalien, Aggregationen usw. Sie können die von der Legacy-SIEM-Lösung bereitgestellten Verweise verwenden, um nachzuvollziehen, wie Sie die Abfragesyntax am besten zuordnen können.
Identifizieren Sie die Auslöserbedingung und die Regelaktion, und erstellen und überprüfen Sie dann die KQL-Abfrage. Wenn Sie die Abfrage überprüfen, sollten Sie die Anleitungsressourcen für die KQL-Optimierung in Betracht ziehen.
Testen Sie die Regel mit jedem der relevanten Anwendungsfälle. Wenn keine erwarteten Ergebnisse bereitgestellt werden, sollten Sie die KQL-Abfrage überprüfen und erneut testen.
Wenn Sie mit dem Ergebnis zufrieden sind, können Sie die Regel als migriert betrachten. Erstellen Sie bei Bedarf ein Playbook für die Regelaktion. Weitere Informationen finden Sie unter Automatisieren der Bedrohungsabwehr mit Playbooks in Microsoft Sentinel.
Weitere Informationen zu Analyseregeln:
- Erstellen benutzerdefinierter Analyseregeln zum Erkennen von Bedrohungen. Verwenden Sie Warnungsgruppen, um Warnungsmüdigkeit 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 Beweismaterials definieren können, das während einer Untersuchung nachverfolgt werden soll. Die Entitätszuordnung ermöglicht es SOC-Analysten zudem, ein intuitives Untersuchungsdiagramm zu nutzen, mit dem sie Zeit und Aufwand reduzieren können.
- Untersuchen Sie Incidents mit UEBA-Daten als Beispiel für die Verwendung von Beweisen, um Ereignisse, Warnungen und alle Lesezeichen, die einem bestimmten Incident zugeordnet sind, im Bereich der Incidentvorschau anzuzeigen.
- Kusto Query Language (KQL), mit der Sie schreibgeschützte Anforderungen an die Log Analytics-Datenbank senden können, um Daten zu verarbeiten und Ergebnisse zurückzugeben. KQL wird auch für andere Microsoft-Dienste verwendet, z. B. Microsoft Defender für Endpunkt und Application Insights.
Vergleichen der Regelterminologie
Diese Tabelle hilft Ihnen, das Konzept einer Regel in Microsoft Sentinel im Vergleich zu ArcSight zu klären.
| ArcSight | Microsoft Sentinel | |
|---|---|---|
| Regeltyp | • Filterregel • Join Rule • Aktive Listenregel • Und mehr |
• Geplante Abfrage • Fusion • Microsoft Security • Machine Learning-(ML-)Verhaltensanalysen |
| Kriterien | Definieren in Regelbedingungen | Definieren in KQL |
| Auslöserbedingung | • Definieren in Aktion • Definieren in Aggregation (für Ereignisaggregation) |
Schwellenwert: Die Anzahl der Abfrageergebnisse |
| Aktion | • Ereignisfeld festlegen • Benachrichtigung senden • Neuen Fall erstellen • Zur aktiven Liste hinzufügen • Und mehr |
• Warnungen und Vorfälle erstellen • Integration in Logic Apps herstellen |
Zuordnen und Vergleichen von Regelbeispielen
Verwenden Sie diese Beispiele, um Regeln von ArcSight zu Microsoft Sentinel in verschiedenen Szenarien zu vergleichen und zuzuordnen.
| Regel | BESCHREIBUNG | Beispielerkennungsregel (ArcSight) | Beispiel-KQL-Abfrage | Ressourcen |
|---|---|---|---|---|
Filter (AND) |
Eine Beispielregel mit AND-Bedingungen. Das Ereignis muss allen Bedingungen entsprechen. |
Filter (AND)-Beispiel | Filter (AND)-Beispiel | Zeichenfolgenfilter: • Zeichenfolgenoperatoren Numerischer Filter: • Numerische Operatoren Datum/Uhrzeit-Filter: • ago • Datetime • between • now Analysieren: • parse • extract • parse_json • parse_csv • parse_path • parse_url |
Filter (OR) |
Eine Beispielregel mit OR-Bedingungen. Das Ereignis kann jeder der Bedingungen entsprechen. |
Filter (OR)-Beispiel | Filter (OR)-Beispiel | • Zeichenfolgenoperatoren • in |
| Geschachtelter Filter | Eine Beispielregel mit geschachtelten Filterbedingungen. Die Regel enthält die MatchesFilter Anweisung, die auch Filterbedingungen enthält. |
Beispiel für geschachtelte Filter | Beispiel für geschachtelte Filter | • Beispiel-KQL-Funktion • Beispielparameterfunktion • Join • Dabei gilt |
| Aktive Liste (Lookup) | Eine Beispiel-Lookup-Regel, die die InActiveList-Anweisung verwendet. |
Beispiel für aktive Liste (Lookup) | Beispiel für aktive Liste (Lookup) | • Eine Watchlist entspricht dem aktiven Listenfeature. Erfahren Sie mehr über Watchlists. • Weitere Möglichkeiten zum Implementieren von Lookups |
| Korrelation (Abgleich) | Eine Beispielregel, die eine Bedingung für eine Reihe von Basisereignissen mithilfe der Matching Event-Anweisung definiert. |
Beispiel einer Korrelation (eines Abgleichs) | Beispiel einer Korrelation (eines Abgleichs) | Join-Operator: • Join • Join mit Zeitfenster • Shuffle • Broadcast • Union define-Anweisung: • let Aggregation: • make_set • make_list • make_bag • pack |
| Korrelation (Zeitfenster) | Eine Beispielregel, die eine Bedingung für eine Reihe von Basisereignissen mithilfe der Matching Event-Anweisung definiert und die Wait time-Filterbedingung verwendet. |
Beispiel für eine Korrelation (Zeitfenster) | Beispiel für eine Korrelation (Zeitfenster) | • Join • Microsoft Sentinel-Regeln und Join-Anweisung |
Filter (AND) Beispiel: ArcSight
Hier sehen Sie eine Beispielfilterregel mit AND-Bedingungen in ArcSight.
Filter (AND) Beispiel: KQL
Hier sehen Sie die Filterregel mit AND-Bedingungen in KQL.
SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)
Diese Regel geht davon aus, dass Microsoft Monitoring Agent (MMA) oder Azure Monitoring Agent (AMA) die Windows-Sicherheitsereignisse sammeln. Daher verwendet die Regel die Microsoft Sentinel SecurityEvent-Tabelle.
Berücksichtigen Sie die folgenden bewährten Methoden:
- Um Ihre Abfragen zu optimieren, vermeiden Sie es möglichst, Operatoren zu verwenden, bei denen es auf die Groß-/Kleinschreibung ankommt:
=~. - Verwenden Sie
==, wenn es bei dem Wert nicht auf die Groß-/Kleinschreibung ankommt. - Ordnen Sie die Filter, indem Sie mit der
where-Anweisung beginnen, die die meisten Daten herausfiltert.
Filter (OR) Beispiel: ArcSight
Hier sehen Sie eine Beispielfilterregel mit OR-Bedingungen in ArcSight.
Filter (OR) Beispiel: KQL
Hier einige Möglichkeiten, die Filterregel mit OR-Bedingungen in KQL zu schreiben.
Verwenden Sie als erste Option die in-Anweisung:
SecurityEvent
| where SubjectUserName in
("Adm1","ServiceAccount1","AutomationServices")
Als zweite Option verwenden Sie die or-Anweisung:
SecurityEvent
| where SubjectUserName == "Adm1" or
SubjectUserName == "ServiceAccount1" or
SubjectUserName == "AutomationServices"
Obwohl beide Optionen in der Leistung identisch sind, empfehlen wir die erste Option, die einfacher zu lesen ist.
Beispiel eines geschachtelten Filters: ArcSight
Hier ein Beispiel für eine Regel mit geschachteltem Filter in ArcSight.
Hier eine Regel für den /All Filters/Soc Filters/Exclude Valid Users-Filter.
Beispiel für geschachtelte Filter: KQL
Hier einige Möglichkeiten, die Filterregel mit OR-Bedingungen in KQL zu schreiben.
Verwenden Sie als erste Option einen direkten Filter mit einer where-Anweisung:
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) or
isnotempty(TargetDomainName)
| where SubjectUserName !~ "AutoMatedService"
Verwenden Sie als zweite Option eine KQL-Funktion:
Speichern Sie die folgende Abfrage als KQL-Funktion mit dem Alias
ExcludeValidUsers.SecurityEvent | where EventID == 4728 | where isnotempty(SubjectDomainName) | where SubjectUserName =~ "AutoMatedService" | project SubjectUserNameVerwenden Sie die folgende Abfrage, um den Alias
ExcludeValidUserszu filtern.SecurityEvent | where EventID == 4728 | where isnotempty(SubjectDomainName) or isnotempty(TargetDomainName) | where SubjectUserName !in (ExcludeValidUsers)
Verwenden Sie als dritte Option eine Parameterfunktion:
Erstellen Sie eine Parameterfunktion mit
ExcludeValidUsersals Name und Alias.Definieren Sie die Parameter der Funktion. Beispiel:
Tbl: (TimeGenerated:datatime, Computer:string, EventID:string, SubjectDomainName:string, TargetDomainName:string, SubjectUserName:string)Die
parameter-Funktion besitzt die folgende Abfrage:Tbl | where SubjectUserName !~ "AutoMatedService"Führen Sie die folgende Abfrage aus, um die Parameterfunktion aufzurufen:
let Events = ( SecurityEvent | where EventID == 4728 ); ExcludeValidUsers(Events)
Verwenden Sie als vierte Option die join-Funktion:
let events = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
or isnotempty(TargetDomainName)
);
let ExcludeValidUsers = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
| where SubjectUserName =~ "AutoMatedService"
);
events
| join kind=leftanti ExcludeValidUsers on
$left.SubjectUserName == $right.SubjectUserName
Überlegungen:
- Es wird empfohlen, aufgrund seiner Einfachheit einen direkten Filter mit einer
where-Anweisung (erste Option) zu verwenden. Für eine optimierte Leistung vermeiden Sie die Verwendung vonjoin(vierte Option). - Um Ihre Abfragen zu optimieren, vermeiden Sie es möglichst, die Operatoren
=~and!~zu verwenden, bei denen es auf die Groß-/Kleinschreibung ankommt. Verwenden Sie die Operatoren==und!=, wenn es bei dem Wert nicht auf die Groß-/Kleinschreibung ankommt.
Beispiel für eine aktive Liste (Lookup): ArcSight
Hier eine aktive Liste (Lookup) in ArcSight.
Beispiel einer aktiven Liste (Lookup): KQL
Diese Regel geht davon aus, dass die Watchlist für Cyber-Ark Ausnahmekonten in Microsoft Sentinel mit einem Kontofeld vorhanden ist.
let Activelist=(
_GetWatchlist('Cyber-Ark Exception Accounts')
| project Account );
CommonSecurityLog
| where DestinationUserName in (Activelist)
| where DeviceVendor == "Cyber-Ark"
| where DeviceAction == "Get File Request"
| where DeviceCustomNumber1 != ""
| project DeviceAction, DestinationUserName,
TimeGenerated,SourceHostName,
SourceUserName, DeviceEventClassID
Ordnen Sie die Filter, indem Sie mit der where-Anweisung beginnen, die die meisten Daten herausfiltert.
Beispiel einer Korrelation (eines Abgleichs): ArcSight
Hier eine Beispiel-ArcSight-Regel, die eine Bedingung für eine Reihe von Basisereignissen mithilfe der Matching Event-Anweisung definiert.
Beispiel einer Korrelation (eines Abgleichs): KQL
let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2
on $left.TargetUserName==$right.TargetUserName
Bewährten Methoden:
- Um Ihre Abfrage zu optimieren, stellen Sie sicher, dass sich die kleinere Tabelle auf der linken Seite der
join-Funktion befindet. - Wenn die linke Seite der Tabelle relativ klein ist (bis zu 100 K-Datensätze), fügen Sie für eine bessere Leistung
hint.strategy=broadcasthinzu.
Beispiel für eine Korrelation (Zeitfenster): ArcSight
Hier eine Beispiel-ArcSight-Regel, die eine Bedingung für eine Reihe von Basisereignissen mithilfe der Matching Event-Anweisung definiert und die Wait time-Filterbedingung verwendet.
Beispiel für eine Korrelation (Zeitfenster): KQL
let waittime = 10m;
let lookback = 1d;
let event1 = (
SecurityEvent
| where TimeGenerated > ago(waittime+lookback)
| where EventID == 4728
| project event1_time = TimeGenerated,
event1_ID = EventID, event1_Activity= Activity,
event1_Host = Computer, TargetUserName,
event1_UPN=UserPrincipalName,
AccountUsedToAdd = SubjectUserName
);
let event2 = (
SecurityEvent
| where TimeGenerated > ago(waittime)
| where EventID == 4729
| project event2_time = TimeGenerated,
event2_ID = EventID, event2_Activity= Activity,
event2_Host= Computer, TargetUserName,
event2_UPN=UserPrincipalName,
AccountUsedToRemove = SubjectUserName
);
event1
| join kind=inner event2 on TargetUserName
| where event2_time - event1_time < lookback
| where tolong(event2_time - event1_time ) >=0
| project delta_time = event2_time - event1_time,
event1_time, event2_time,
event1_ID,event2_ID,event1_Activity,
event2_Activity, TargetUserName, AccountUsedToAdd,
AccountUsedToRemove,event1_Host,event2_Host,
event1_UPN,event2_UPN
Aggregationsbeispiel: ArcSight
Hier ist eine Beispiel-ArcSight-Regel mit Aggregationseinstellungen: drei Übereinstimmungen innerhalb von 10 Minuten.
Beispiel für eine Aggregation: KQL
SecurityEvent
| summarize Count = count() by SubjectUserName,
SubjectDomainName
| where Count >3
Nächste Schritte
In diesem Artikel haben Sie erfahren, wie Sie Ihre Migrationsregeln von ArcSight zu Microsoft Sentinel zuordnen.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für