Verwendung von Auslösern und Aktionen in Microsoft Sentinel-Playbooks

In diesem Dokument werden die Arten von Triggern und Aktionen im Logic Apps Microsoft Sentinel-Connector erläutert, die Playbooks zur Interaktion mit Microsoft Sentinel und den Informationen in den Tabellen Ihres Arbeitsbereichs verwenden können. Außerdem wird Ihnen gezeigt, wie Sie zu bestimmten Arten von Microsoft Sentinel-Informationen gelangen, die Sie wahrscheinlich benötigen werden.

Dieses Dokument ist zusammen mit unserem Leitfaden zur Authentifizierung von Playbooks in Microsoft Sentinel eine Ergänzung zu unserer anderen Playbook-Dokumentation - Tutorial: Verwendung von Playbooks mit Automatisierungsregeln in Microsoft Sentinel. In diesen drei Dokumenten wird immer wieder aufeinander verwiesen.

Eine Einführung in Playbooks finden Sie unter Automatisierung Reaktion auf Bedrohungen mit Playbooks in Microsoft Sentinel.

Die vollständige Spezifikation des Microsoft Sentinel-Konnektors finden Sie in der Dokumentation zum Logic Apps-Konnektor.

Wichtig

Microsoft Sentinel ist als Teil der öffentlichen Vorschau für die Unified Security Operations Platform im Microsoft Defender Portal verfügbar. Weitere Informationen finden Sie unter Microsoft Sentinel im Microsoft Defender-Portal.

Erforderliche Berechtigungen

Rollen/Connectorkomponenten Auslöser „Get“-Aktionen Incident aktualisieren,
Kommentar hinzufügen
Microsoft Sentinel-Leser
Microsoft Sentinel-Responder/Mitwirkender

Erfahren Sie mehr über Berechtigungen in Microsoft Sentinel.

Zusammenfassung der Auslöser von Microsoft Sentinel

Auch wenn der Microsoft Sentinel-Konnektor auf vielfältige Weise verwendet werden kann, lassen sich die Komponenten des Konnektors in drei Abläufe unterteilen, die jeweils durch ein anderes Microsoft Sentinel-Ereignis ausgelöst werden:

Trigger (vollständiger Name im Logic Apps-Designer) Einsatzgebiete Bekannte Einschränkungen
Microsoft Sentinel-Incident (Vorschau) Wird für die meisten Szenarien zur Incidentautomatisierung empfohlen.

Das Playbook empfängt Incidentobjekte, einschließlich Entitäten und Warnungen. Mit diesem Trigger kann das Playbook an eine Automatisierungsregel angefügt werden, damit es ausgelöst werden kann, wenn in Microsoft Sentinel ein Incident erstellt (und jetzt auch aktualisiert) wird. So können alle Vorteile von Automatisierungsregeln auf den Incident angewendet werden.
Playbooks mit diesem Trigger unterstützen keine Gruppierung von Warnungen, d. h., sie empfangen nur die erste Warnung, die bei jedem Incident gesendet wird.

UPDATE: Ab Februar 2023 wird die Warnungsgruppierung für diesen Auslöser unterstützt.
Microsoft Sentinel-Warnung (Vorschau) Empfehlenswert für Playbooks, die manuell auf Alerts aus dem Microsoft Sentinel-Portal ausgeführt werden müssen, oder für geplante Analyseregeln, die keine Incidents für ihre Alerts erzeugen. Dieser Trigger kann nicht verwendet werden, um Reaktionen auf Warnungen zu automatisieren, die von Microsoft-Sicherheitsanalyseregeln generiert werden.

Playbooks, die diesen Trigger verwenden, können nicht von Automatisierungsregeln aufgerufen werden.
Microsoft Sentinel-Entität (Vorschau) Soll für Playbooks verwendet werden, die manuell für bestimmte Entitäten aus einem Untersuchungs- oder Bedrohungssuchkontext ausgeführt werden müssen. Playbooks, die diesen Trigger verwenden, können nicht von Automatisierungsregeln aufgerufen werden.

Die von diesen Flows verwendeten Schemas sind nicht identisch. Es wird empfohlen, den Ablauf Microsoft Sentinel incident trigger zu verwenden, der für die meisten Szenarien geeignet ist.

Dynamische Felder für Incidents

Das Objekt Incident, das vom Microsoft Sentinel-Vorfall empfangen wurde, enthält die folgenden dynamischen Felder:

  • Incidenteigenschaften (als „Incident: Feldname“ angezeigt)

  • Warnungen (Array)

    • Warnungseigenschaften (als „Warnung: Feldname“ angezeigt)

      Wenn Sie eine Warnungseigenschaft wie Warnung: <Eigenschaftenname> auswählen, wird automatisch eine for each-Schleife generiert, da ein Incident mehrere Warnungen enthalten kann.

  • Entitäten (Array aller Entitäten einer Warnung)

  • Felder für Arbeitsbereichsinformationen (gilt für den Sentinel-Arbeitsbereich, in dem der Incident erstellt wurde)

    • Abonnement-ID
    • Arbeitsbereichname
    • Arbeitsbereichs-ID
    • Ressourcengruppenname

Zusammenfassung der Microsoft Sentinel-Aktionen

Komponente Einsatzgebiete
Warnung: Incident abrufen In Playbooks, die mit dem Warnungstrigger beginnen. Nützlich für das Abrufen der Incidenteigenschaften oder der Incident-ARM-ID zur Verwendung mit den Aktionen Incident aktualisieren oder Kommentar zu Incident hinzufügen.
Incident abrufen Wenn ein Playbook über eine externe Quelle oder mit einem Nicht-Sentinel-Trigger ausgelöst wird. Identifizieren Sie es anhand einer Incident-ARM-ID. Ruft die Incidenteigenschaften und Kommentare ab.
Incident aktualisieren Um den Status eines Incidents zu ändern (z. B. beim Schließen des Incidents), einen Besitzer zuzuweisen, ein Tag hinzuzufügen oder zu entfernen oder Schweregrad, Titel oder Beschreibung zu ändern.
Kommentare zu Incidents hinzufügen Zum Anreichern des Incidents mit aus externen Quellen gesammelten Informationen; zum Überprüfen der vom Playbook auf die Entitäten angewendeten Maßnahmen; zur Bereitstellung zusätzlicher Informationen, die für die Untersuchung des Incidents nützlich sind.
Entitäten – <Entitätstyp> abrufen In Playbooks, die mit einem bestimmten Entitätstyp (IP, Konto, Host, URL oder FileHash) arbeiten, der zum Zeitpunkt der Erstellung des Playbooks bekannt ist, müssen Sie in der Lage sein, ihn zu analysieren und mit seinen eindeutigen Feldern zu arbeiten.

Arbeiten mit Incidents: Verwendungsbeispiele

Tipp

Die Aktionen Incident aktualisieren und Kommentar zu Incident hinzufügen erfordern die Incident-ARM-ID.

Verwenden Sie zuvor die Aktion Warnung: Incident abrufen, um die Incident-ARM-ID zu erhalten.

Aktualisieren eines Incidents

  • Das Playbook wird von einem Microsoft Sentinel-Vorfall ausgelöst.

    Incidenttrigger: einfaches Beispiel für „Flow aktualisieren“

  • Das Playbook wird von einer Microsoft Sentinel-Warnung ausgelöst.

    Warnungstrigger: einfaches Beispiel für „Incidentflow aktualisieren“

Verwenden von Incidentinformationen

Einfaches Playbook zum Senden von Incidentdetails per E-Mail:

  • Das Playbook wird von einem Microsoft Sentinel-Vorfall ausgelöst.

    Incidenttrigger: einfaches Beispiel für „Flow abrufen“

  • Das Playbook wird von einer Microsoft Sentinel-Warnung ausgelöst.

    Warnungstrigger: einfaches Beispiel für „Incidentflow abrufen“

Hinzufügen eines Kommentars zum Incident

  • Das Playbook wird von einem Microsoft Sentinel-Vorfall ausgelöst.

    Incidenttrigger: einfaches Beispiel für „Kommentar hinzufügen“

  • Das Playbook wird von einer Microsoft Sentinel-Warnung ausgelöst.

    Warnungstrigger: einfaches Beispiel für „Kommentar hinzufügen“

Deaktivieren eines Benutzers

  • Das Playbook wird von einer Microsoft Sentinel-Entität ausgelöst

    Screenshot: Aktionen, die in einem Entitätstrigger-Playbook zum Deaktivieren eines Benutzers ausgeführt werden sollen

Entitäts-Playbooks ohne Incident-ID

Playbooks, die mit dem Entitätstrigger erstellt wurden, verwenden häufig das Feld incident-ARM-ID (um beispielsweise einen Incident zu aktualisieren, nachdem für die Entität eine Aktion durchgeführt wurde).

Wenn ein solches Playbook in einem Kontext ausgelöst wird, der nicht mit einem Incident verbunden ist (z. B. bei der Bedrohungssuche), gibt es keinen Incident, mit dessen ID dieses Feld aufgefüllt werden kann. In diesem Fall wird das Feld mit einem NULL-Wert belegt.

Dies hat zur Folge, dass das Playbook möglicherweise nicht bis zum Abschluss ausgeführt werden kann. Um diesen Fehler zu verhindern, wird empfohlen, eine Bedingung zu erstellen, die vor dem Ausführen von Aktionen nach einem Wert im Feld „Incident-ID“ sucht, und einen anderen Aktionssatz vorzusehen, wenn das Feld einen NULL-Wert aufweist, d. h. wenn das Playbook nicht von einem Incident aus ausgeführt wird.

  1. Fügen Sie vor der ersten Aktion, die auf das Feld Incident-ARM-ID verweist, einen Schritt vom Typ Bedingung hinzu.

  2. Wählen Sie das Feld Wert auswählen aus, und öffnen Sie das Dialogfeld Dynamischen Inhalt hinzufügen.

  3. Wählen Sie die Registerkarte Ausdruck und die Funktion length(collection) aus.

  4. Wählen Sie die Registerkarte Dynamischer Inhalt und das Feld Incident-ARM-ID aus.

  5. Vergewissern Sie sich, dass der resultierende Ausdruck length(triggerBody()?['IncidentArmID']) lautet, und wählen Sie OK aus.

    Screenshot: Dialogfelds für dynamische Inhalte zum Auswählen von Feldern für eine Playbookbedingung

  6. Legen Sie den Operator und den Wert in der Bedingung auf „ist größer als“ und „0“ fest.

    Screenshot: endgültige Definition der im vorherigen Screenshot beschriebenen Bedingung

  7. Fügen Sie im Feld True die Aktionen hinzu, die ausgeführt werden sollen, wenn das Playbook aus einem Incidentkontext ausgeführt wird.

    Fügen Sie im Feld False die Aktionen hinzu, die ausgeführt werden sollen, wenn das Playbook nicht aus einem Incidentkontext ausgeführt wird.

Arbeiten mit bestimmten Entitätstypen

Das dynamische Feld Entitäten ist ein Array von JSON-Objekten, von denen jedes eine Entität darstellt. Jede Entität hat abhängig von ihren eindeutigen Eigenschaften ihr eigenes Schema.

Die Aktion Entitäten – <Entitätstyp> abrufen ermöglicht Ihnen Folgendes:

  • Filtern des Arrays von Entitäten nach dem angeforderten Typ.
  • Analysieren der spezifischen Felder dieses Typs, damit sie in weiteren Aktionen als dynamische Felder verwendet werden können.

Die Eingabe erfolgt in das dynamische Feld Entitäten.

Die Antwort ist ein Array von Entitäten, in dem die speziellen Eigenschaften analysiert werden und direkt in einer For each-Schleife verwendet werden können.

Die folgenden Entitätstypen werden derzeit unterstützt:

Für andere Entitätstypen kann eine ähnliche Funktionalität mit den integrierten Aktionen von Logic Apps erreicht werden:

  • Filtern des Arrays von Entitäten nach dem angeforderten Typ mithilfe von Array filtern.

  • Analysieren der spezifischen Felder dieses Typs, damit sie in weiteren Aktionen als dynamische Felder verwendet werden können, mithilfe von JSON analysieren.

Arbeiten mit benutzerdefinierten Details

Das dynamische Feld Benutzerdefinierte Warnungsdetails, das im Incidenttrigger verfügbar ist, ist ein Array von JSON-Objekten, von denen jedes ein benutzerdefiniertes Detail einer Warnung darstellt. Bei benutzerdefinierten Details handelt es sich um Schlüssel-Wert-Paare, die es Ihnen ermöglichen, Informationen aus Ereignissen in der Warnung sichtbar zu machen, damit sie als Teil des Incidents dargestellt, nachverfolgt und analysiert werden können.

Da dieses Feld in der Warnung anpassbar ist, hängt das Schema vom Typ des sichtbar gemachten Ereignisses ab. Sie müssen Daten aus einer Instanz dieses Ereignisses bereitstellen, um das Schema zu generieren, das bestimmt, wie das benutzerdefinierte Detailfeld analysiert werden soll.

Sehen Sie sich folgendes Beispiel an:

In der Analyseregel definierte benutzerdefinierte Details.

Bei diesen Schlüssel-Wert-Paaren steht der Schlüssel (die linke Spalte) für die von Ihnen erstellten benutzerdefinierten Felder und der Wert (die rechte Spalte) für die Felder aus den Ereignisdaten, die die benutzerdefinierten Felder auffüllen.

Sie können den folgenden JSON-Code zum Generieren des Schemas bereitstellen. Der Code zeigt die Schlüsselnamen als Arrays und die Werte (die tatsächlichen Werte, nicht die Spalte, die die Werte enthält) als Elemente in den Arrays.

{ "FirstCustomField": [ "1", "2" ], "SecondCustomField": [ "a", "b" ] }
  1. Fügen Sie einen neuen Schritt mit der integrierten Aktion JSON analysieren hinzu. Sie können „JSON analysieren“ in das Suchfeld eingeben, um sie zu finden.

  2. Suchen Sie Benutzerdefinierte Warnungsdetails in der Liste Dynamischer Inhalt unter dem Incidenttrigger, und wählen Sie sie aus.

    Wählen Sie unter „Dynamischer Inhalt“ die Option „Benutzerdefinierte Warnungsdetails“ aus.

    Dadurch wird eine For each-Schleife erstellt, da ein Incident ein Array mit Warnungen enthält.

  3. Wählen Sie den Link Beispielnutzdaten zum Generieren eines Schemas verwenden.

    Wählen Sie den Link „Beispielnutzdaten zum Generieren eines Schemas verwenden“ aus

  4. Geben Sie Beispielnutzdaten an. Ein Beispiel für die Nutzdaten finden Sie, wenn Sie in Log Analytics nach einer anderen Instanz dieser Warnung suchen und das benutzerdefinierte Detailobjekt (unter Erweiterte Eigenschaften) kopieren. Greifen Sie auf Log Analytics-Daten entweder auf der Seite Protokolle im Azure-Portal oder auf der Seite Erweiterte Suche im Defender-Portal zu. Im folgenden Screenshot haben wir den oben gezeigten JSON-Code verwendet.

    Geben Sie JSON-Beispielnutzdaten ein.

  5. Die benutzerdefinierten Felder sind bereit, dynamische Felder des Typs Array zu verwenden. Sie sehen hier das Array und seine Elemente, sowohl im Schema als auch in der Liste, die unter Dynamischer Inhalt angezeigt wird, die wir oben beschrieben haben.

    Felder aus dem Schema, die verwendet werden können.

Nächste Schritte

In diesem Artikel haben Sie mehr über die Verwendung der Auslöser und Aktionen in Microsoft Sentinel-Playbooks erfahren, um auf Bedrohungen zu reagieren.