Migrieren von QRadar-Erkennungsregeln zu Microsoft Sentinel

In diesem Artikel wird beschrieben, wie Sie Ihre QRadar-Erkennungsregeln identifizieren, vergleichen und zu Microsoft Sentinel integrierten Regeln migrieren. Es führt Sie durch die Inventarisierung Ihrer bestehenden Erkennungen, den Vergleich der Regelterminologie zwischen QRadar und Microsoft Sentinel und die Wahl des richtigen Migrationswegs – sei es durch die Nutzung integrierter Analysevorlagen aus dem Content Hub, das Konvertieren von Anfragen mit einem Online-Tool oder das Schreiben benutzerdefinierter Kusto Query Language (KQL)-Abfragen. Am Ende haben Sie einen strukturierten Ansatz, um Ihre Erkennungsregeln zu migrieren und dabei die maschinellen Lernanalysen von Microsoft Sentinel zu nutzen.

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 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 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önnten. 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 im Content Hub verfügbar sind:

   • Wenn die integrierten Regeln ausreichend sind, installieren Sie die relevanten Lösungen, und verwenden Sie die Vorlagen, um Regeln für Ihren Arbeitsbereich zu erstellen.

     1. Navigieren Sie in Microsoft Sentinel zu Inhaltsverwaltung > Inhaltshub.
     2. Suchen Sie nach der relevanten Analyseregel, und installieren Sie sie.

     Weitere Informationen finden Sie unter Ermitteln und Verwalten von Microsoft Sentinel sofort einsatzbereiten Inhalten und Erstellen geplanter Analyseregeln aus Vorlagen.

   • Wenn Sie Erkennungen haben, die nicht von den integrierten Regeln abgedeckt werden, die im Content Hub verfügbar sind, 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 Content Hub-Lösungen 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 zum Erstellen 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 mit dem Ergebnis 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 Microsoft Sentinel Analyseregeln und KQL finden Sie in den folgenden Ressourcen:

• 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): Mit der Sie lesgeschützte Anfragen 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 QRadar zu verdeutlichen. Microsoft Sentinel-Regeltypen umfassen geplante Abfragen, Fusion (das Warnungen aus mehreren Datenquellen automatisch mit Vorfällen mittels Machine learning korreliert), Microsoft Security und Machine Learning (ML) Behavior Analytics.

Regelbeispiele abbilden und vergleichen

Verwenden Sie diese Beispiele, um Regeln von QRadar zu Microsoft Sentinel in verschiedenen Szenarien zu vergleichen und zuzuordnen. Die Beispielabfragen sind in der Kusto Query Language (KQL) geschrieben, der von Microsoft Sentinel verwendeten Abfragesprache.

Syntax der allgemeinen Eigenschaftstests

Hier sehen Sie die QRadar-Syntax für eine allgemeine Eigenschaftstestregel.

Allgemeine Eigenschaftstests: Beispiel für reguläre Ausdrücke (QRadar)

Dies ist die Syntax für eine Beispielregel für allgemeine QRadar-Eigenschaftentests, die einen regulären Ausdruck verwendet:

when any of <these properties> match <this regular expression>

Hier ist die Beispielregel in QRadar:

Häufige Eigenschaftstests: Beispiel für einen regulären Ausdruck (KQL)

Dies ist die Regel der allgemeinen Eigenschaftstests mit einem regulären Ausdruck in KQL.

CommonSecurityLog
| where tostring(SourcePort) matches regex @"\d{1,5}" or tostring(DestinationPort) matches regex @"\d{1,5}"

Allgemeine Eigenschaftentests: Beispiel für AQL-Filterabfragen (QRadar)

Hier ist die Syntax einer Beispielregel für QRadar-Common-Property-Tests, die eine AQL-Filteranfrage verwendet:

when the event matches <this> AQL filter query

Hier ist die Beispielregel in QRadar:

Allgemeine Eigenschaftstests: Beispiel für AQL-Filterabfragen (KQL)

Hier ist die Regel für gängige Eigenschaftstests mit einer AQL-Filteranfrage in KQL:

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Häufige Eigenschaftstests: Beispiel für Gleich/ungleich (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Gemeinsamkeits-Eigenschaftstests, die den Operator oder not equals verwendetequals:

and when <this property> <equals/not equals> <this property>

Hier ist die Beispielregel in QRadar:

Allgemeine Eigenschaftstests: equals/not equals-Beispiel (KQL)

Hier ist die Regel für gemeinsame Eigenschaftstests mit dem equals oder-Operator not equals in KQL:

CommonSecurityLog
| where SourceIP == DestinationIP

Syntax für Datums-/Uhrzeittests

Hier ist die QRadar-Syntax für eine Regel für Datum/Uhrzeit-Tests:

Datums-/Uhrzeittests: Beispiel für den ausgewählten Tag des Monats (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Datums-/Zeittests, die einen ausgewählten Monatstag verwendet:

and when the event(s) occur <on/after/before> the <selected> day of the month

Hier ist die Beispielregel in QRadar:

Datums-/Uhrzeittests: Beispiel für den ausgewählten Tag des Monats (KQL)

Hier ist die Regel für Datums- und Zeittests mit einem ausgewählten Monatstag in KQL:

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

Datums-/Uhrzeittests: Beispiel für einen ausgewählten Wochentag (QRadar)

Hier sehen Sie die Syntax für eine Beispielregel für QRadar-Datums-/Uhrzeittests, die einen ausgewählten Wochentag verwendet:

and when the event(s) occur on any of <these days of the week{Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}>

Hier ist die Beispielregel in QRadar:

Datums-/Uhrzeittests: Beispiel für ausgewählten Wochentag (KQL)

Hier ist die Regel für Datum/Uhr-Tests bei einem ausgewählten Wochentag in KQL:

SecurityEvent
 | where dayofweek(TimeGenerated) between (3d .. 5d)

Datums-/Zeit-Tests: Beispiel für „nach/vor/um“ (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Datums-/Zeittests, die den , before, oder at Operator afterverwendet:

and when the event(s) occur <after/before/at> <this time{12.00AM, 12.05AM, ...11.50PM, 11.55PM}>

Hier ist die Beispielregel in QRadar:

Datums-/Uhrzeittests: Beispiel für Nachher/Vorher/Um (KQL)

Hier ist die Regel für Datums-/Zeittests, die den after, before, oder at Operator in KQL verwendet:

SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"

TimeGenerated ist in UTC/GMT.

Syntax der Ereigniseigenschaftstests

Hier ist die QRadar-Syntax für eine Ereignis-Eigenschaftstestregel:

Ereigniseigenschaftstests: IP-Protokollbeispiel (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Ereignis-Eigenschaftstests, die ein IP-Protokoll verwendet:

and when the IP protocol is one of the following <protocols>

Hier ist die Beispielregel in QRadar:

Ereigniseigenschaftstests: IP-Protokollbeispiel (KQL)

Hier ist die Regel für Event-Property-Tests mit einem IP-Protokollfilter in KQL:

CommonSecurityLog
| where Protocol in ("UDP","ICMP")

Ereigniseigenschaftstests: Beispiel für ereignisnutzlastige Zeichenfolge (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Ereignis-Eigenschaftstests, die einen String-Wert Event Payload verwendet:

and when the Event Payload contains <this string>

Hier ist die Beispielregel in QRadar:

Ereigniseigenschaftstests: Beispiel für Ereignisnutzlastzeichenfolge (KQL)

Dies ist die Regel für Ereigniseigenschaftstests mit einer Event Payload-Zeichenfolge in KQL. Um die Leistung zu optimieren, vermeiden Sie die Verwendung des search Befehls, wenn Sie den Tabellennamen bereits kennen.

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Funktionen: Syntax für Zähler

Hier ist die QRadar-Syntax für eine Funktionsregel, die Zähler verwendet:

Zähler: Ereigniseigenschaft und Zeitbeispiel (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Funktionen, die eine definierte Anzahl von Ereigniseigenschaften in einer definierten Anzahl von Minuten verwendet."

and when at least <this many> events are seen with the same <event properties> in <this many> <minutes>

Hier ist die Beispielregel in QRadar:

Zähler: Beispiel für Ereigniseigenschaft und Uhrzeit (KQL)

Hier ist die Zählerregel mit Ereigniseigenschaft und Zeitbedingungen in KQL:

CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5

Funktionen: Syntax für negative Bedingungen

Hier ist die QRadar-Syntax für eine Funktionsregel, die negative Bedingungen verwendet:

Beispiel für negative Bedingungen (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Funktionen, die negative Bedingungen verwendet:

and when none of <these rules> match in <this many> <minutes> after <these rules> match with the same <event properties>

Hier sind zwei definierte Regeln in QRadar. Die negativen Bedingungen basieren auf diesen Regeln:

Hier ist ein Beispiel der Regel für negative Bedingungen basierend auf den beiden zuvor definierten QRadar-Regeln (Test2 und Test6):

Beispiel für negative Bedingungen (KQL)

Hier ist die Regel der negativen Bedingungen bei einem rightanti Join in KQL:

let spanoftime = 10m;
let Test2 = (
CommonSecurityLog
| where Protocol !in ("UDP","ICMP")
| where TimeGenerated > ago(spanoftime)
);
let Test6 = (
CommonSecurityLog
| where SourceIP == DestinationIP
);
Test2
| join kind=rightanti Test6 on $left. SourceIP == $right. SourceIP and $left. Protocol ==$right. Protocol

Funktionen: Einfache Bedingungssyntax

Hier ist die QRadar-Syntax für eine Funktionsregel, die einfache Bedingungen verwendet:

Beispiel für einfache Bedingungen (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar-Funktionen, die einfache Bedingungen verwendet:

and when an event matches <any|all> of the following <rules>

Hier ist die Beispielregel in QRadar:

Beispiel für einfache Bedingungen (KQL)

Hier ist die einfache Bedingungsregel in KQL:

CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP

Syntax für IP-/Porttests

Hier ist die QRadar-Syntax für eine IP/Port-Testregel:

IP-/Porttests: Quellportbeispiel (QRadar)

Hier ist die Syntax für eine QRadar-Beispielregel, die einen Quellport angibt:

and when the source port is one of the following <ports>

Hier ist die Beispielregel in QRadar:

IP-/Porttests: Quellportbeispiel (KQL)

Hier ist die IP/Port-Testregel mit einem Quellportfilter in KQL:

CommonSecurityLog
| where SourcePort == 20

IP-/Porttests: Quell-IP-Beispiel (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar, die eine Quell-IP angibt:

and when the source IP is one of the following <IP addresses>

Hier ist die Beispielregel in QRadar:

IP-/Porttests: Quell-IP-Beispiel (KQL)

Hier ist die IP/Port-Testregel mit einem Quell-IP-Filter in KQL:

CommonSecurityLog
| where SourceIP in ("10.1.1.1","10.2.2.2")

Syntax der Protokollquellentests

Hier ist die QRadar-Syntax für eine Log-Source-Testregel:

Beispiel für eine Log-Quelle (QRadar)

Hier ist die Syntax für eine Beispielregel für QRadar, die Log-Quellen spezifiziert:

and when the event(s) were detected by one or more of these <log source types>

Hier ist die Beispielregel in QRadar:

Protokollquellbeispiel (KQL)

Hier ist die Regel für Log-Source-Tests in KQL.

OfficeActivity
| where OfficeWorkload == "Exchange"

Nächster Schritt