Migrieren von ArcSight-Erkennungsregeln zu Microsoft Sentinel

In diesem Artikel wird beschrieben, wie Sie Ihre ArcSight-Erkennungsregeln identifizieren, vergleichen und zu Microsoft Sentinel Analyseregeln migrieren.

Identifizieren und Migrieren von Regeln

Microsoft Sentinel verwendet Machine Learning-Analysen, um Vorfälle mit hoher Genauigkeit und Umsetzbarkeit zu erstellen, und einige Ihrer vorhandenen Erkennungen können in Microsoft Sentinel redundant sein. Migrieren Sie daher nicht alle Ihre Erkennungs- und Analyseregeln blind. Überprüfen Sie diese Überlegungen, wenn Sie Ihre vorhandenen Erkennungsregeln identifizieren.

• Stellen Sie sicher, dass Sie Anwendungsfälle auswählen, die die Regelmigration unter Berücksichtigung der Geschäftlichen Priorität und Effizienz rechtfertigen.
• Vergewissern Sie sich, dass Sie Microsoft Sentinel Regeltypen verstehen.
• Überprüfen Sie, ob Sie die Regelterminologie verstehen.
• Überprüfen Sie alle Regeln, die in den letzten 6 bis 12 Monaten keine Warnungen ausgelöst haben, und ermitteln Sie, ob sie noch relevant sind.
• Beseitigen Sie Bedrohungen oder Warnungen auf niedriger Ebene, die Sie routinemäßig ignorieren.
• Verwenden Sie vorhandene Funktionen, und überprüfen Sie, ob die integrierten Analyseregeln von Microsoft Sentinel Ihre aktuellen Anwendungsfälle erfüllen können. Da Microsoft Sentinel Machine Learning-Analysen verwendet, um Vorfälle mit hoher Genauigkeit und Umsetzbarkeit zu erzeugen, ist es wahrscheinlich, dass einige Ihrer vorhandenen Erkennungen nicht mehr erforderlich sind.
• Bestätigen Sie verbundene Datenquellen, und überprüfen Sie Ihre Datenverbindungsmethoden. Rufen Sie die Konversationen zur Datensammlung erneut auf, um die Datentiefe und -breite in den Anwendungsfällen sicherzustellen, die Sie erkennen möchten.
• Erkunden Sie Communityressourcen wie den SOC Prime Threat Detection Marketplace , um zu überprüfen, ob Ihre Regeln verfügbar sind.
• Überlegen Sie, ob ein Onlineabfragekonverter wie Uncoder.io für Ihre Regeln funktionieren könnte.
• 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 für die Migration von Erkennungsregeln.

So migrieren Sie Ihre Analyseregeln zu Microsoft Sentinel:

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 alle erforderlichen Datenquellen verbunden sind, und überprüfen Sie Ihre Datenverbindungsmethoden.

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

   • Wenn die integrierten Regeln ausreichen, verwenden Sie integrierte Regelvorlagen, um Regeln für Ihren eigenen Arbeitsbereich zu erstellen.

     Wechseln Sie Microsoft Sentinel zur Registerkarte Konfigurationsanalyseregelvorlagen >>, und erstellen und aktualisieren Sie jede relevante Analyseregel.

     Weitere Informationen finden Sie unter Erstellen geplanter Analyseregeln aus Vorlagen.

   • Wenn Sie über Erkennungen verfügen, die nicht von den integrierten Regeln Microsoft Sentinel abgedeckt werden, probieren Sie einen Onlineabfragekonverter aus, z. B. Uncoder.io, um Ihre Abfragen in KQL zu konvertieren.

     Identifizieren Sie die Triggerbedingung und die Regelaktion, erstellen und überprüfen Sie dann Ihre KQL-Abfrage.

   • Wenn weder die integrierten Regeln noch ein Onlineregelkonverter ausreichen, müssen Sie die Regel manuell erstellen. Führen Sie in solchen Fällen die folgenden Schritte aus, um mit dem Erstellen ihrer Regel zu beginnen:

     1. Identifizieren Sie die Datenquellen, die Sie in Ihrer 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 Ihren Daten, die Sie in Ihren Regeln verwenden möchten.

     3. Identifizieren Sie Ihre Regelkriterien und -logik. In dieser Phase sollten Sie Regelvorlagen als Beispiele für die Erstellung Ihrer KQL-Abfragen verwenden.

        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, sollten Sie die KQL überprüfen und erneut testen.

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:

• Geplante Analyseregeln in Microsoft Sentinel. 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 zu nutzen, das dazu beitragen kann, Zeit und Aufwand zu reduzieren.
• Untersuchen Sie Vorfälle mit UEBA-Daten als Beispiel für die Verwendung von Beweisen, um Ereignisse, Warnungen und lesezeichen, die einem bestimmten Incident zugeordnet sind, im Vorschaubereich des Incidents anzuzeigen.
• Kusto-Abfragesprache (KQL), mit dem Sie schreibgeschützte Anforderungen 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

Diese Tabelle hilft Ihnen, das Konzept einer Regel in Microsoft Sentinel im Vergleich zu ArcSight zu verdeutlichen.

Zuordnen und Vergleichen von Regelbeispielen

Verwenden Sie diese Beispiele, um Regeln aus ArcSight in verschiedenen Szenarien zu Microsoft Sentinel zu vergleichen und zuzuordnen.

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)

Bei dieser Regel wird davon ausgegangen, dass der Azure Monitoring Agent (AMA) die Windows-Sicherheit Ereignisse sammelt. Daher verwendet die Regel die Microsoft Sentinel SecurityEvent-Tabelle.

Beachten Sie die folgenden bewährten Methoden:

• Um Ihre Abfragen zu optimieren, vermeiden Sie nach Möglichkeit Operatoren ohne Berücksichtigung der Groß-/Kleinschreibung: =~.
• Verwenden Sie == , wenn bei dem Wert die Groß-/Kleinschreibung nicht beachtet wird.
• Ordnen Sie die Filter an, 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

Im Folgenden finden Sie einige Möglichkeiten zum Schreiben der Filterregel mit OR Bedingungen in KQL.

Verwenden Sie als erste Option die in -Anweisung:

SecurityEvent
| where SubjectUserName in
 ("Adm1","ServiceAccount1","AutomationServices")

Verwenden Sie als zweite Option 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 für geschachtelte Filter: ArcSight

Hier sehen Sie eine Beispielregel für geschachtelte Filter in ArcSight.

Dies ist eine Regel für den /All Filters/Soc Filters/Exclude Valid Users Filter.

Beispiel für geschachtelte Filter: KQL

Im Folgenden finden Sie einige Möglichkeiten zum Schreiben der Filterregel mit OR Bedingungen in KQL.

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 ExcludeValidUsers Alias.

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

2. Verwenden Sie die folgende Abfrage, um den ExcludeValidUsers Alias 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. Zum Beispiel:

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

3. Die parameter Funktion verfügt über 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:

• Aufgrund der Einfachheit wird empfohlen, einen direkten Filter mit einer where -Anweisung (erste Option) zu verwenden. Um die Leistung zu optimieren, vermeiden Sie die Verwendung von join (vierte Option).
• Um Ihre Abfragen zu optimieren, vermeiden Sie nach Möglichkeit die Operatoren und !~ ohne Beachtung der =~ Groß-/Kleinschreibung. Verwenden Sie die == Operatoren und != , wenn bei dem Wert die Groß-/Kleinschreibung nicht beachtet wird.

Beispiel für eine aktive Liste (Suche): ArcSight

Hier sehen Sie eine aktive Listenregel (Nachschlageregel) in ArcSight.

Beispiel für eine aktive Liste (Nachschlagevorgang): KQL

Bei dieser Regel wird davon ausgegangen, dass die Watchlist Cyber-Ark Ausnahmekonten in Microsoft Sentinel mit einem Feld Konto 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 an, indem Sie mit der where Anweisung beginnen, die die meisten Daten herausfiltert.

Korrelationsbeispiel (Abgleich): ArcSight

Hier sehen Sie eine ArcSight-Beispielregel, die eine Bedingung für eine Reihe von Basisereignissen mithilfe der Matching Event -Anweisung definiert.

Korrelationsbeispiel (Abgleich): KQL

let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2 
on $left.TargetUserName==$right.TargetUserName

Bewährte 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.000 Datensätze), fügen Sie für eine bessere Leistung hinzu hint.strategy=broadcast .

Korrelationsbeispiel (Zeitfenster): ArcSight

Hier sehen Sie eine ArcSight-Beispielregel, die eine Bedingung für eine Reihe von Basisereignissen definiert, die die Matching Event -Anweisung verwendet und die Wait time Filterbedingung verwendet.

Korrelationsbeispiel (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 sehen Sie eine ArcSight-Beispielregel mit Aggregationseinstellungen: drei Übereinstimmungen innerhalb von 10 Minuten.

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