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 die folgenden Überlegungen, wenn 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.
• Stellen Sie sicher, dass Sie die Regelterminologie verstehen.
• Überprüfen Sie alle Regeln, die in den letzten sechs bis zwölf Monaten keine Warnungen ausgelöst haben, und entscheiden 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.

     Gehen Sie in Microsoft Sentinel zur Registerkarte Konfiguration > Analysen > Regelvorlagen, und erstellen und aktualisieren Sie jede entsprechende Analyseregel.

     Um zu lernen, wie man Regeln aus integrierten Vorlagen erstellt, siehe Erstellen von geplanten 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. Du könntest Referenzen verwenden, die von deinem alten SIEM bereitgestellt werden, um die ArcSight-Abfragesyntax auf KQL abzubilden.

     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 mit dem Ergebnis zufrieden sind, können Sie die Regel als migriert betrachten. Erstellen Sie nach Bedarf ein Playbook für Ihre Regelaktion. Um Playbooks für Regelaktionen zu erstellen und zu verwenden, siehe Automate threat response with Playbooks in Microsoft Sentinel.

Weitere Informationen zu Analyseregeln:

• Regeln für geplante Analysen in Microsoft Sentinel: Verwenden Sie Benachrichtigungsgruppierung, um Alarmmüdigkeit zu reduzieren, indem Sie Warnungen gruppieren, die innerhalb eines bestimmten Zeitrahmens auftreten.
• Zuordnung von Datenfeldern zu Entitäten in Microsoft Sentinel: Um SOC-Ingenieuren zu ermöglichen, Entitäten als Teil der Beweismittel zu definieren, die während einer Untersuchung nachverfolgt werden sollen. 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 dafür, wie man Beweise nutzt, um Ereignisse, Warnungen und etwaige Lesezeichen, die mit einem bestimmten Vorfall verbunden sind, im Vorschaufenster des Vorfalls hervorzuheben.
• Kusto Query Language (KQL): Sie können KQL verwenden, um schreibgeschützte Anfragen an Ihre Log Analytics-Datenbank zu senden, 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.

Regelbeispiele abbilden und vergleichen

Verwenden Sie die folgenden Beispiele, um ArcSight-Erkennungsregeln mit äquivalenten Microsoft Sentinel-Abfragen in Kusto Query Language (KQL) zu vergleichen.

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

Considerations

• 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 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 (Suche): ArcSight

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

Beispiel für eine Aktive Liste (Suche): KQL

Die folgende KQL-Abfrage verwendet die Watchlist Cyber-Ark Exception Accounts, um Nachschlagergebnisse zu filtern.

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 (Zuordnung): KQL

Das folgende KQL-Beispiel zeigt, wie die ArcSight-Korrelationsregel in Microsoft Sentinel implementiert wird.

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 hint.strategy=broadcast hinzu, um die Performance zu verbessern.

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

Im folgenden KQL-Beispiel wird eine Korrelationsregel mit einem Zeitfenster implementiert, das dem ArcSight-Beispiel entspricht.

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 Beispielregel in ArcSight mit Aggregationseinstellungen: drei Treffer innerhalb von 10 Minuten.

Aggregationsbeispiel: KQL

Die folgende KQL-Abfrage zeigt, wie drei oder mehr Übereinstimmungen mithilfe der Aggregation erkannt werden.

SecurityEvent
| summarize Count = count() by SubjectUserName, 
SubjectDomainName
| where Count >3

Nächster Schritt