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:

1. Stellen Sie sicher, dass für jede Regel, die Sie migrieren möchten, ein Testsystem vorhanden ist.

   1. Konzipieren Sie einen Überprüfungsprozess für die migrierten Regeln, einschließlich vollständiger Testszenarios und Skripts.

   2. Stellen Sie sicher, dass Ihr Team über nützliche Ressourcen verfügt, damit die migrierten Regeln getestet werden können.

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

2. Ü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 Erstellen von geplanten Analyseregeln aus Vorlagen.

   • 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:

     1. 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.

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

     3. 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.

     4. 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.

3. 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.

4. 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:

• Geplante Analyseregeln in Microsoft Sentinel. 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 • 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 der Azure Monitoring Agent (AMA) die Windows-Sicherheitsereignisse sammelt. 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:

1. Speichern Sie die folgende Abfrage als KQL-Funktion mit dem Alias ExcludeValidUsers.

       SecurityEvent
       | where EventID == 4728
       | where isnotempty(SubjectDomainName)
       | where SubjectUserName =~ "AutoMatedService"
       | project SubjectUserName
   

2. Verwenden Sie die folgende Abfrage, um den Alias ExcludeValidUsers zu filtern.

       SecurityEvent    
       | where EventID == 4728
       | where isnotempty(SubjectDomainName) or 
       isnotempty(TargetDomainName)
       | where SubjectUserName !in (ExcludeValidUsers)
   

Verwenden Sie als dritte Option eine Parameterfunktion:

1. Erstellen Sie eine Parameterfunktion mit ExcludeValidUsers als Name und Alias.

2. Definieren Sie die Parameter der Funktion. Beispiel:

       Tbl: (TimeGenerated:datetime, Computer:string, 
       EventID:string, SubjectDomainName:string, 
       TargetDomainName:string, SubjectUserName:string)
   

3. Die parameter-Funktion besitzt die folgende Abfrage:

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

4. 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 von join (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=broadcast hinzu.

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.

Migrieren Ihrer SOAR-Automatisierung