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.

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ö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. Wechseln Sie Microsoft Sentinel zum Inhaltsverwaltungs-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 für die Erstellung Ihrer KQL-Abfragen 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 QRadar zu verdeutlichen.

Zuordnen und Vergleichen von Regelbeispielen

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

Syntax für allgemeine Eigenschaftentests

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 sehen Sie die Beispielregel in QRadar.

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

Hier sehen Sie die allgemeine Eigenschaftstestregel 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 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 Eigenschaftstests: Beispiel für AQL-Filterabfragen (KQL)

Hier sehen Sie die allgemeine Eigenschaftstestregel mit einer AQL-Filterabfrage in KQL.

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Allgemeine Eigenschaftstests: equals/not equals (QRadar)

Hier sehen Sie die Syntax für eine Beispielregel für allgemeine QRadar-Eigenschaftentests, die den equals Operator oder not equals verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

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

Hier sehen Sie die allgemeine Eigenschaftstestregel mit dem equals Operator oder not equals in KQL.

CommonSecurityLog
| where SourceIP == DestinationIP

Syntax für Datums-/Uhrzeittests

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

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

Hier sehen Sie die Syntax für eine QRadar-Beispielregel für Datums-/Uhrzeittests, 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)

Hier sehen Sie die Datums-/Uhrzeit-Testregel mit einem ausgewählten Tag des Monats 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 sehen Sie die Beispielregel in QRadar.

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

Hier sehen Sie die Datums-/Uhrzeittestregel mit einem ausgewählten Wochentag in KQL.

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

Datums-/Uhrzeittests: After/Before/At-Beispiel (QRadar)

Hier sehen Sie die Syntax für eine QRadar-Beispielregel für Datums-/Uhrzeittests, die den afterOperator , beforeoder 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 nach/vor/zu (KQL)

Hier sehen Sie die Datums-/Uhrzeit-Testregel, die den afterOperator , beforeoder at in KQL verwendet.

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

TimeGenerated ist in UTC/GMT.

Syntax von Ereigniseigenschaftstests

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

Ereigniseigenschaftstests: IP-Protokollbeispiel (QRadar)

Hier sehen Sie die Syntax für eine Beispielregel für QRadar-Ereigniseigenschaftentests, die ein IP-Protokoll verwendet.

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

Hier sehen Sie die Beispielregel in QRadar.

Ereigniseigenschaftstests: IP-Protokollbeispiel (KQL)

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

Ereigniseigenschaftstests: Beispiel für ereignisnutzlastige Zeichenfolge (QRadar)

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

and when the Event Payload contains <this string>

Hier sehen Sie die Beispielregel in QRadar.

Ereigniseigenschaftstests: Beispiel für Ereignisnutzlastzeichenfolge (KQL)

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Um die Leistung zu optimieren, vermeiden Sie die Verwendung des search Befehls, wenn Sie den Tabellennamen bereits kennen.

Funktionen: Countersyntax

Hier sehen Sie die QRadar-Syntax für eine Funktionsregel, die Leistungsindikatoren verwendet.

Leistungsindikatoren: Ereigniseigenschaft und Zeitbeispiel (QRadar)

Hier sehen Sie 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 sehen Sie die Beispielregel in QRadar.

Leistungsindikatoren: Ereigniseigenschaft und Zeitbeispiel (KQL)

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

Funktionen: Syntax für negative Bedingungen

Hier sehen Sie die QRadar-Syntax für eine Funktionsregel, die negative Bedingungen verwendet.

Beispiel für negative Bedingungen (QRadar)

Hier sehen Sie 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 sehen Sie ein Beispiel für die Regel für negative Bedingungen, die auf den oben genannten Regeln basiert.

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: Einfache Bedingungssyntax

Hier sehen Sie die QRadar-Syntax für eine Funktionsregel, die einfache Bedingungen verwendet.

Beispiel für einfache Bedingungen (QRadar)

Hier sehen Sie 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 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

Hier sehen Sie die QRadar-Syntax für eine IP/Port-Testregel.

IP-/Porttests: Quellportbeispiel (QRadar)

Hier sehen Sie die Syntax für eine QRadar-Beispielregel, die einen Quellport angibt.

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

Hier sehen Sie die Beispielregel in QRadar.

IP-/Porttests: Quellportbeispiel (KQL)

CommonSecurityLog
| where SourcePort == 20

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

Dies ist die Syntax für eine QRadar-Beispielregel, die eine Quell-IP-Adresse angibt.

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

Hier sehen Sie die Beispielregel in QRadar.

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

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

Syntax für Protokollquellentests

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

Protokollquelle (Beispiel) (QRadar)

Hier sehen Sie die Syntax für eine QRadar-Beispielregel, 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.

Protokollquellbeispiel (KQL)

OfficeActivity
| where OfficeWorkload == "Exchange"

Nächste Schritte

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