Migrieren von QRadar-Erkennungsregeln zu Microsoft Sentinel

In diesem Artikel erfahren Sie, wie Sie Ihre QRadar-Erkennungsregeln identifizieren, vergleichen und zu den in Microsoft Sentinel integrierten Regeln 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](investigate-cases.md#use-the-investigation-graph-to-deep-dive) 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 QRadar zu klären.

	QRadar	Microsoft Sentinel
Regeltyp	• Ereignisse • Flow • Allgemein • Verstoß • Anomalieerkennungsregeln	• Geplante Abfrage • Fusion • Microsoft Security • Machine Learning-(ML-)Verhaltensanalysen
Kriterien	Definieren unter Testbedingung	Definieren in KQL
Auslöserbedingung	Definieren in Regel	Schwellenwert: Die Anzahl der Abfrageergebnisse
Aktion	• Verstoß erstellen • Neues Ereignis senden • Zu Referenzsatz oder -daten hinzufügen • Und vieles mehr	• Warnungen und Vorfälle erstellen • Integration in Logic Apps herstellen

Zuordnen und Vergleichen von Regelbeispielen

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

Regel	Syntax	Beispielerkennungsregel (QRadar)	Beispiel-KQL-Abfrage	Ressourcen
Allgemeine Eigenschaftstests	QRadar-Syntax	• Beispiel für einen regulären Ausdruck • Beispiel für AQL-Filterabfrage • Beispiel für Gleich/Ungleich	• Beispiel für einen regulären Ausdruck • Beispiel für AQL-Filterabfrage • Beispiel für Gleich/Ungleich	• Regulärer Ausdruck: Stimmt mit RegEx überein • AQL-Filterabfrage: Zeichenfolgenoperatoren • Gleich/Ungleich: Zeichenfolgenoperatoren
Datums-/Uhrzeittests	QRadar-Syntax	• Beispiel für ausgewählten Tag des Monats • Beispiel für ausgewählten Tag der Woche • Beispiel für Nachher/Vorher/Um	• Beispiel für ausgewählten Tag des Monats • Beispiel für ausgewählten Tag der Woche • Beispiel für Nachher/Vorher/Um	• Datums- und Uhrzeitoperatoren • Ausgewählter Tag des Monats: dayofmonth() • Ausgewählter Tag der Woche: dayofweek() • Nachher/Vorher/Um: format_datetime()
Ereigniseigenschaftstests	QRadar-Syntax	• Beispiel für IP-Protokoll • Beispiel für Ereignisnutzdatenzeichenfolge	• Beispiel für IP-Protokoll • Beispiel für Ereignisnutzdatenzeichenfolge	• IP-Protokoll: Zeichenfolgenoperatoren • Ereignisnutzdatenzeichenfolge: hat
Funktionen: Zähler	QRadar-Syntax	Beispiel für Ereigniseigenschaft und Uhrzeit	Beispiel für Ereigniseigenschaft und Uhrzeit	summarize
Funktionen: negative Bedingungen	QRadar-Syntax	Beispiel für negative Bedingungen	Beispiel für negative Bedingungen	• join() • Zeichenfolgenoperatoren • Numerische Operatoren
Funktionen: einfach	QRadar-Syntax	Beispiel für einfache Bedingungen	Beispiel für einfache Bedingungen	or
IP-/Port-Tests	QRadar-Syntax	• Beispiel für Quellport • Beispiel für Quell-IP	• Beispiel für Quellport • Beispiel für Quell-IP
Protokollquellentests	QRadar-Syntax	Beispiel für Protokollquelle	Beispiel für Protokollquelle

Syntax der allgemeinen Eigenschaftstests

Dies ist die QRadar-Syntax für eine allgemeine Eigenschaftstestregel.

Allgemeine Eigenschaftstests: Beispiel für einen regulären Ausdruck (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 sehen Sie die Beispielregel in QRadar.

Allgemeine 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 einer AQL-Filterabfrage (QRadar)

Dies ist die Syntax für eine Beispielregel für allgemeine QRadar-Eigenschaftentests, die eine AQL-Filterabfrage verwendet.

when the event matches <this> AQL filter query

Hier sehen Sie die Beispielregel in QRadar.

Allgemeine Eigenschaftentests: Beispiel einer AQL-Filterabfrage (KQL)

Dies ist die Regel der allgemeinen Eigenschaftstests mit einer AQL-Filterabfrage in KQL.

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Allgemeine Eigenschaftstests: Beispiel für Gleich/Ungleich (QRadar)

Dies ist die Syntax für eine Beispielregel für allgemeine QRadar-Eigenschaftentests, die die Operatoren equals oder not equals verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

Allgemeine Eigenschaftstests: Beispiel für Gleich/Ungleich (KQL)

Dies ist die Regel der allgemeinen Eigenschaftentests mit den Operatorenequals oder not equals in KQL.

CommonSecurityLog
| where SourceIP == DestinationIP

Syntax für Datums-/Uhrzeittests

Hier finden Sie die QRadar-Syntax für eine Datums-/Uhrzeittestregel.

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

Dies ist die Syntax für eine Beispiel-QRadar-Datums-/Uhrzeittestregel, die einen ausgewählten Tag des Monats verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

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

Dies ist die Datums-/Uhrzeittestregel mit einem ausgewählten Tag des Monats in KQL.

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

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

Dies ist die Syntax für eine Beispiel-QRadar-Datums-/Uhrzeittestregel, die einen ausgewählten Tag der Woche verwendet:

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

Hier sehen Sie die Beispielregel in QRadar.

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

Dies ist die Datums-/Uhrzeittestregel mit einem ausgewählten Tag der Woche in KQL.

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

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

Dies ist die Syntax für eine Beispiel-QRadar-Datums-/Uhrzeittestregel, die die Operatoren after, before oder at verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

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

Dies ist die Datum/Uhrzeittestregel, die die Operatoren after, before oder at in KQL verwendet.

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

TimeGenerated ist in UTC/GMT angegeben.

Syntax der Ereigniseigenschaftstests

Dies ist die QRadar-Syntax für eine Ereigniseigenschaftstestregel.

Ereigniseigenschaftstests: Beispiel für ein IP-Protokoll (QRadar)

Dies ist die Syntax für eine Beispiel-QRadar-Ereigniseigenschaftstestregel, die ein IP-Protokoll verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

Ereigniseigenschaftstests: Beispiel für ein IP-Protokoll (KQL)

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

Ereigniseigenschaftstests: Beispiel für Ereignisnutzdatenzeichenfolgen (QRadar)

Dies ist die Syntax für eine Beispiel-QRadar-Ereigniseigenschaftstestregel, die einen Event Payload-Zeichenfolgenwert verwendet.

and when the Event Payload contains <this string>

Hier sehen Sie die Beispielregel in QRadar.

Ereigniseigenschaftstests: Beispiel für Ereignisnutzdatenzeichenfolgen (KQL)

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Um die Leistung zu optimieren, vermeiden Sie es, den Befehl search zu verwenden, wenn Sie den Tabellennamen bereits kennen.

Funktionen: Zählersyntax

Dies ist die QRadar-Syntax für eine Funktionsregel, die Zähler verwendet.

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

Dies ist die Syntax für eine Beispiel-QRadar-Funktionsregel, 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 sehen Sie die Beispielregel in QRadar.

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

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

Funktionen: Syntax für negative Bedingungen

Dies ist die QRadar-Syntax für eine Funktionsregel, die negative Bedingungen verwendet.

Beispiel für negative Bedingungen (QRadar)

Dies ist die Syntax für eine QRadar-Funktionsregel, die negative Bedingungen verwendet.

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

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

Dies ist ein Beispiel für die Regel für negativer Bedingungen basierend auf den oben genannten Regeln.

Beispiel für negative Bedingungen (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: Syntax einfacher Bedingungen

Dies ist die QRadar-Syntax für eine Funktionsregel, die einfache Bedingungen verwendet.

Beispiel für einfache Bedingungen (QRadar)

Dies ist die Syntax für eine Beispiel-QRadar-Funktionsregel, die einfache Bedingungen verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

Beispiel für einfache Bedingungen (KQL)

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

Syntax für IP-/Porttests

Dies ist die QRadar-Syntax für eine IP/Port-Testregel.

IP/Porttests: Beispiel für den Quellport (QRadar)

Dies ist die Syntax für eine Beispiel-QRadar-Regel, die einen Quellport angibt.

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

Hier sehen Sie die Beispielregel in QRadar.

IP/Porttests: Beispiel für den Quellport (KQL)

CommonSecurityLog
| where SourcePort == 20

IP/Porttests: Beispiel für die Quell-IP (QRadar)

Dies ist die Syntax für eine Beispiel-QRadar-Regel, die eine Quell-IP angibt.

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

Hier sehen Sie die Beispielregel in QRadar.

IP/Porttests: Beispiel für die Quell-IP (KQL)

CommonSecurityLog
| where SourceIP in (“10.1.1.1”,”10.2.2.2”)

Syntax der Protokollquellentests

Dies ist die QRadar-Syntax für eine Protokollquellentestregel.

Beispiel für die Protokollquelle (QRadar)

Dies ist die Syntax für eine Beispiel-QRadar-Regel, die Protokollquellen angibt.

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

Hier sehen Sie die Beispielregel in QRadar.

Beispiel für Protokollquelle (KQL)

OfficeActivity
| where OfficeWorkload == "Exchange"

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie Ihre Migrationsregeln von QRadar zu Microsoft Sentinel zuordnen.

Migrieren Ihrer SOAR-Automatisierung