OpenAI und Microsoft Sentinel Teil 2: Erläuterung der Analyseregeln

Willkommen zurück zu unserer Serie über OpenAI und Microsoft Sentinel! Heute werden wir einen weiteren Anwendungsfall für die beliebten Sprachmodelle von OpenAI untersuchen und einen Blick auf die Sentinel REST API werfen. Wenn Sie noch keine Microsoft Sentinel-Instanz haben, können Sie eine mit einem kostenlosen Azure-Konto erstellen und der Schnellstartanleitung „Erste Schritte mit Sentinel“ folgen. Sie benötigen außerdem ein persönliches OpenAI-Konto mit einem API-Schlüssel. Bereit? Fangen wir an!

Eine der Aufgaben für Sicherheitsexperten besteht darin, mithilfe analytischer Regeln, Abfragen und Definitionen schnell zu verstehen, was eine Warnung ausgelöst hat. Hier ist beispielsweise ein Beispiel für eine relativ kurze Microsoft Sentinel-Analyseregel, die in der Kusto Query Language (KQL) geschrieben wurde: Es wird keine Schwierigkeiten haben, es zu analysieren, aber es wird trotzdem einige Zeit dauern, die Schlüsselwörter, Protokollquellen, Aktionen und Ereignislogik im Kopf zu planen. Personen, die KQL noch nie verwendet haben, benötigen möglicherweise mehr Zeit, um zu verstehen, was diese Regel erkennen soll. Glücklicherweise haben wir einen Freund, der wirklich gut darin ist, Code zu lesen und ihn in natürlicher Sprache zu interpretieren – GPT3 von OpenAI!

Lassen Sie uns durch die Logik-App gehen, beginnend mit Triggern. Wir verwenden für dieses Playbook einen Microsoft Sentinel-Ereignisauslöser, damit wir mithilfe des Sentinel-Connectors alle relevanten Analyseregel-IDs aus dem Ereignis extrahieren können. Wir werden die Sentinel-REST-API verwenden, um den Regelabfragetext anhand der Regel-ID zu finden, die wir in der Textvervollständigungsaufforderung an das KI-Modell übergeben können. Abschließend werden wir die Ausgabe des KI-Modells als Kommentar zum Ereignis hinzufügen.

Unsere erste Aktion ist der Logikblock „Für jeden“, der auf Sentinels „Ereignisbezogenes Analyseregel-ID-Element“ wirkt:

#🎜🎜 ## 🎜🎜#Als nächstes müssen wir die Sentinel-REST-API verwenden, um die geplante Alarmregel selbst anzufordern. Dieser API-Endpunkt ist hier dokumentiert: https://learn.microsoft.com/en-us/rest/api/securityinsights/stable/alert-rules/get ?tabs= HTTP . Wenn Sie die Sentinel-API noch nicht verwendet haben, können Sie auf die grüne Schaltfläche „Ausprobieren“ neben dem Codeblock klicken, um eine Vorschau der tatsächlichen Anfrage mit Ihren Anmeldeinformationen anzuzeigen. Dies ist eine großartige Möglichkeit, die API zu erkunden! In unserem Fall sieht die Anfrage „Get – Alert Rules“ so aus:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId}?api-version=2022-11-01

Wir können diesen API-Aufruf mit der Aktion „HTTP“ in unserer Logik-App durchführen. Glücklicherweise sind bei dem ereignisbezogenen Analyseregel-ID-Element, das wir gerade zum Logikblock „Für jeden“ hinzugefügt haben, fast alle Parameter vorab ausgefüllt. Wir müssen der API-Domäne lediglich am Ende die Versionsangabe voranstellen – alle Parameter für subscriptionID, resourcesGroupName, workspaceName und RuleId stammen aus unserem dynamischen Inhaltsobjekt. Der eigentliche Text meines URI-Blocks lautet wie folgt:

https://management.azure.com@{items('For_each_related_Analytics_Rule_ID')}?api-version=2022-11-01

Wir müssen auch Authentifizierungsoptionen für HTTP-Vorgänge konfigurieren – ich verwende eine verwaltete Identität für meine Logik-App. Der fertige Aktionsblock sieht so aus:

Da wir nun die Alarmregel haben, müssen wir nur noch den Regeltext analysieren, damit wir ihn übergeben können zu GPT3 . Lassen Sie uns die Aktion „JSON analysieren“ verwenden, ihr den Hauptinhalt aus dem HTTP-Schritt bereitstellen und das Schema so definieren, dass es der erwarteten Ausgabe dieses API-Aufrufs entspricht. Der einfachste Weg, das Schema zu generieren, besteht darin, eine Beispielnutzlast hochzuladen. Wir müssen jedoch nicht alle Eigenschaften einschließen, die uns nicht interessieren. Ich habe das Schema so gekürzt, dass es so aussieht:

{"type": "object","properties": {"id": {"type": "string"},"type": {"type": "string"},"kind": {"type": "string"},"properties": {"type": "object","properties": {"severity": {"type": "string"},"query": {"type": "string"},"tactics": {},"techniques": {},"displayName": {"type": "string"},"description": {"type": "string"},"lastModifiedUtc": {"type": "string"}}}}}

Bisher sehen unsere Logikblöcke so aus:

Der letzte Schritt in unserem Playbook besteht darin, mithilfe des resultierenden Textes aus GPT3 einen Kommentar zum Ereignis hinzuzufügen. Wenn Sie stattdessen eine Ereignisaufgabe hinzufügen möchten, wählen Sie einfach die Sentinel-Aktion aus. Fügen Sie ein dynamisches Inhaltsobjekt „Event ARM ID“ hinzu und verfassen Sie die Kommentarnachricht mithilfe des von der GPT3-Aktion ausgegebenen „Text (Abschlusstext)“. Der Logic App Designer verpackt Ihre Kommentaraktionen automatisch in einen „Für jeden“-Logikblock. Die fertige Kommentaraktion sollte etwa so aussehen:

Speichern Sie Ihre Logik-App und lassen Sie uns sie in einem Event ausprobieren! Wenn alles gut geht, zeigt unser Ausführungsverlauf der Logik-App den erfolgreichen Abschluss an. Wenn Probleme auftreten, können Sie die genauen Eingabe- und Ausgabedetails jedes Schritts überprüfen – ein unschätzbares Tool zur Fehlerbehebung! In unserem Fall war es immer ein grünes Häkchen:

Erfolg! Das Playbook fügt dem Ereignis einen Kommentar hinzu und erspart unseren überarbeiteten Sicherheitsanalysten so ein paar Minuten.

Das obige ist der detaillierte Inhalt vonOpenAI und Microsoft Sentinel Teil 2: Erläuterung der Analyseregeln. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!