Automatisieren der Bedrohungsabwehr mit Playbooks in Microsoft Sentinel

  • Artikel
  • Gilt für::
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

In diesem Artikel wird erklärt, was Microsoft Sentinel-Playbooks sind und wie Sie sie für die Implementierung Ihrer SOAR-Vorgänge (Security Orchestration, Automation and Response) verwenden, um bessere Ergebnisse zu erzielen und gleichzeitig Zeit und Ressourcen zu sparen.

Wichtig

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

Was ist ein Playbook?

SOC-Analysten werden regelmäßig mit Sicherheitswarnungen und -vorfällen überschwemmt, und zwar in einem so großen Umfang, dass das verfügbare Personal überfordert ist. Dies führt häufig dazu, dass viele Alarme ignoriert und viele Incidents nicht untersucht werden, wodurch ein Unternehmen anfällig für Angriffe wird, die unbemerkt bleiben.

Viele – wenn nicht sogar der Großteil – dieser Warnungen und Incidents entsprechen wiederkehrenden Mustern, die mithilfe spezifischer, definierter Wartungsaktionen verarbeitet werden können. Analysten sind auch mit der grundlegenden Behebung und Untersuchung der Vorfälle betraut, die sich bearbeiten lassen. In dem Maß, in dem diese Aktivitäten sich automatisieren lassen, wird ein SOC produktiver und effizienter, sodass Analysten mehr Zeit und Energie für die eigentliche Untersuchungstätigkeit aufwenden können.

Ein Playbook ist eine Sammlung dieser Wartungsaktionen, die Sie in Microsoft Sentinel routinemäßig ausführen, um Ihre Reaktion auf Bedrohungen zu automatisieren und zu orchestrieren. Es gibt zwei Möglichkeiten zum Ausführen:

  • Manuell bei Bedarf für eine bestimmte Entität oder Warnung
  • Automatisch als Reaktion auf bestimmte Warnungen oder Vorfälle, wenn sie durch eine Automatisierungsregel ausgelöst werden.

Wenn zum Beispiel ein Konto und ein Computer kompromittiert sind, kann ein Playbook den Computer vom Netzwerk isolieren und das Konto sperren, bis das SOC-Team über den Incident informiert wird.

Während auf der Registerkarte Aktive Playbooks auf der Seite Automation alle aktiven Playbooks angezeigt werden, die in allen ausgewählten Abonnements verfügbar sind, kann ein Playbook standardmäßig nur innerhalb des Abonnements verwendet werden, zu dem es gehört, es sei denn, Sie erteilen Microsoft Sentinel ausdrücklich Berechtigungen für die Ressourcengruppe des Playbooks.

Nach dem Onboarding auf der einheitlichen Security Operations-Plattform wird auf der Registerkarte Aktive Playbooks ein vordefinierter Filter mit dem Abonnement des integrierten Arbeitsbereichs angezeigt. Fügen Sie im Azure-Portal mithilfe des Azure Abonnementfilters Daten für andere Abonnements hinzu.

Playbookvorlagen

Eine Playbookvorlage ist ein vorgefertigter, getesteter und gebrauchsfertiger Workflow, der an Ihre Bedürfnisse angepasst werden kann. Vorlagen können auch als Referenz für bewährte Methoden bei der Entwicklung vollkommen neuer Playbooks oder als Anregung für neue Automatisierungsszenarien dienen.

Playbookvorlagen können nicht selbst als Playbooks verwendet werden. Sie erstellen ein Playbook (eine bearbeitbare Kopie der Vorlage) aus ihnen.

Sie können Playbookvorlagen aus den folgenden Quellen beziehen:

  • Auf der Seite Automatisierung sind auf der Registerkarte Playbookvorlagen die installierten Playbookvorlagen aufgelistet. Es können mehrere aktive Playbooks aus derselben Vorlage erstellt werden.

    Wenn eine neue Version der Vorlage veröffentlicht wird, wird zu den aus der betreffenden Vorlage erstellten Aktiven Playbooks die Meldung angezeigt, dass ein Update verfügbar ist.

  • Playbookvorlagen sind als Teil von Produktlösungen oder eigenständigen Inhalten verfügbar, die Sie über den Content Hub in Microsoft Sentinel installieren. Weitere Informationen finden Sie unter Microsoft Sentinel-Inhalte und -Lösungen und Entdecken und Verwalten sofort einsatzbereiter Microsoft Sentinel-Inhalte.

  • Das Microsoft Sentinel-GitHub-Repository enthält viele Playbookvorlagen. Diese können in einem Azure-Abonnement bereitgestellt werden, indem auf die Schaltfläche In Azure bereitstellen geklickt wird.

Technisch gesehen ist eine Playbookvorlage eine ARM-Vorlage, die aus mehreren Ressourcen besteht: einem Azure Logic Apps-Workflow und API-Verbindungen für jede einbezogene Verbindung.

Wichtig

Playbookvorlagen befinden sich derzeit in der VORSCHAUPHASE. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten zusätzliche rechtliche Bedingungen, die für Azure-Features gelten, die sich in der Beta- oder Vorschauversion befinden bzw. anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Azure Logic Appspps Grundlegende Konzepte

Playbooks in Microsoft Sentinel basieren auf Workflows, die in Azure Logic Apps erstellt wurden, einem Clouddienst, mit dem Sie Aufgaben und Workflows systemübergreifend im gesamten Unternehmen planen, automatisieren und orchestrieren können. Das bedeutet, dass Playbooks die gesamte Leistungsfähigkeit und die Funktionen der integrierten Vorlagen in Azure Logic Apps nutzen können.

Hinweis

Azure Logic Apps erstellt separate Ressourcen, daher können zusätzliche Gebühren anfallen. Weitere Informationen finden Sie auf der Preisseite von Azure Logic Apps.

Azure Logic Apps kommuniziert mit anderen Systemen und Diensten über Konnektoren. Im Folgenden finden Sie eine kurze Erläuterung der Konnektoren und einiger ihrer wichtigen Eigenschaften:

  • Verwalteter Connector: Eine Reihe von Aktionen und Auslösern, die API-Aufrufe für ein bestimmtes Produkt oder einen bestimmten Dienst umschließen. Azure Logic Apps bietet Hunderte von Konnektoren für die Kommunikation mit Microsoft-und nicht-Microsoft-Diensten. Weitere Informationen finden Sie unter Azure Logic Apps-Connectors und der zugehörigen Dokumentation

  • Benutzerdefinierter Connector:Vielleicht möchten Sie mit Diensten kommunizieren, die nicht als vorgefertigte Connectors verfügbar sind. Benutzerdefinierte Konnektoren adressieren diesen Bedarf, indem Sie einen Konnektor erstellen (und sogar freigeben) und seine eigenen Auslöser und Aktionen definieren können. Weitere Informationen finden Sie unter Erstellen eigener benutzerdefinierter Azure Logic Apps-Connectors.

  • Microsoft Sentinel-Connector: Zum Erstellen von Playbooks, die mit Microsoft Sentinel interagieren, verwenden Sie den Microsoft Sentinel-Connector. Weitere Informationen finden Sie in der Dokumentation zum Microsoft Sentinel-Connector.

  • Trigger: Eine Connector-Komponente, die einen Workflow startet, in diesem Fall ein Playbook. Der Microsoft Sentinel-Trigger definiert das Schema, das das Playbook erwartet, wenn es ausgelöst wird. Der Microsoft Sentinel-Connector verfügt derzeit über drei Trigger:

  • Aktionen: Als Aktionen werden alle Schritte bezeichnet, die nach dem Trigger ausgeführt werden. Sie können sequentiell, parallel oder in einer Matrix komplexer Bedingungen angeordnet sein.

  • Dynamische Felder: Temporäre Felder, die durch das Ausgabeschema von Triggern und Aktionen bestimmt und durch deren tatsächliche Ausgabe befüllt werden, die in den folgenden Aktionen verwendet werden können.

Logik-App-Typen

Microsoft Sentinel unterstützt jetzt die folgenden Logik-App-Ressourcentypen:

  • Verbrauch, der in Azure Logic Apps mit mehreren Mandanten ausgeführt wird und die klassische, ursprüngliche Azure Logic Apps-Engine verwendet.
  • Standard, der in Azure Logic Apps mit einem einzelnen Mandanten ausgeführt wird und eine neu gestaltete Azure Logic Apps-Engine verwendet.

Der Standard-Logik-App-Typ bietet höhere Leistung, Festpreise, mehrere Workflow-Funktionen, einfachere Verwaltung von API-Verbindungen, native Netzwerkfunktionen wie Support für virtuelle Netzwerke und private Endpunkte (siehe Hinweis unten), integrierte CI/CD-Funktionen, bessere Visual Studio Code-Integration, einen aktualisierten Workflow-Designer und mehr.

Um diese Logik-App-Version zu verwenden, erstellen Sie neue Standard-Playbooks in Microsoft Sentinel (siehe Hinweis unten). Sie können diese Playbooks auf die gleiche Weise wie Verbrauchsplaybooks verwenden:

  • Fügen Sie sie an Automatisierungsregeln und/oder Analyseregeln an.
  • Führen Sie sie bei Bedarf über Vorfälle und Warnungen aus.
  • Verwalten Sie sie auf der Registerkarte „Aktive Playbooks“.

Hinweis

  • Standardworkflows unterstützen derzeit keine Playbook-Vorlagen, was bedeutet, dass Sie kein auf einem Standardworkflow basierendes Playbook direkt in Microsoft Sentinel erstellen können. Stattdessen müssen Sie den Workflow in Azure Logic Apps erstellen. Nachdem Sie den Workflow erstellt haben, wird er als Playbook in Microsoft Sentinel angezeigt.

  • Die Standardworkflows von Logik-Apps unterstützen wie oben erwähnt private Endpunkte. Für Microsoft Sentinel muss jedoch eine Zugriffseinschränkungsrichtlinie in Logik-Apps definiert werden, damit die Verwendung privater Endpunkte in Playbooks basierend auf Standardworkflows unterstützt wird.

    Ohne Definition einer Zugriffseinschränkungsrichtlinie sind Workflows mit privaten Endpunkten möglicherweise weiterhin sichtbar und auswählbar, wenn Sie ein Playbook aus einer Liste in Microsoft Sentinel auswählen (ob zur manuellen Ausführung, zum Hinzufügen zu einer Automatisierungsregel oder im Playbook-Katalog). Sie können sie auswählen, ihre Ausführung schlägt jedoch fehl.

  • Ein Indikator identifiziert Standardworkflows entweder als zustandsbehaftet oder zustandslos. Microsoft Sentinel unterstützt derzeit keine zustandslosen Workflows. Hier erfahren Sie mehr über die Unterschiede zwischen zustandsbehafteten und zustandslosen Workflows.

Es gibt viele Unterschiede zwischen diesen beiden Ressourcentypen, von denen einige die Art und Weise beeinflussen, wie sie in Playbooks in Microsoft Sentinel verwendet werden können. In solchen Fällen wird in der Dokumentation auf das hingewiesen, was Sie wissen müssen. Weitere Informationen finden Sie unter Unterschiede zwischen Ressourcentyp und Hostumgebung in der Azure Logic Apps-Dokumentation.

Erforderliche Berechtigungen

Um Ihrem SecOps-Team die Möglichkeit zu geben, Azure Logic Apps zum Erstellen und Ausführen von Playbooks in Microsoft Sentinel zu verwenden, weisen Sie Ihrem Security Operations-Team oder bestimmten Benutzern in dem Team Azure-Rollen zu. Im folgenden werden die verschiedenen verfügbaren Rollen und die Aufgaben beschrieben, denen Sie zugewiesen werden sollten:

Azure-Rollen für Azure Logic Apps

  • Mit Logic-App Contributor können Sie Logik-Apps verwalten und Playbooks ausführen, aber Sie können den Zugriff darauf nicht ändern (dafür ist die Rolle Besitzer erforderlich.)
  • Mit Logik-App-Operator können Sie Logic-Apps lesen, aktivieren und deaktivieren, aber Sie können sie nicht bearbeiten oder aktualisieren.

Azure-Rollen für Microsoft Sentinel

  • Die Rolle Microsoft Sentinel-Mitwirkender ermöglicht Ihnen, ein Playbook an eine Analyse- oder Automatisierungsregel anzufügen.

  • Die Rolle Azure Sentinel-Antwortberechtigter ermöglicht Ihnen den Zugriff auf einen Vorfall, um ein Playbook manuell auszuführen. Aber um das Playbook tatsächlich ausführen zu können, benötigen Sie auch die folgenden Rollen:

    • Microsoft Sentinel-Playbookoperator ermöglicht Ihnen, ein Playbook manuell auszuführen.
    • Als Mitwirkender für Microsoft Sentinel-Automatisierung können Sie mit Automatisierungsregeln Playbooks ausführen. Es wird nicht für andere Zwecke genutzt.

Erfahren Sie mehr

Schritte zum Erstellen eines Playbooks

Anwendungsfälle für Playbooks

Die Azure Logic Apps Plattform bietet Hunderte von Aktionen und Auslösern, sodass nahezu jedes Automatisierungsszenario erstellt werden kann. Microsoft Sentinel empfiehlt, mit den folgenden SOC-Szenarien zu beginnen, für die vorgefertigte Playbookvorlagen standardmäßig verfügbar sind:

Anreicherung

Sammeln Sie Daten, und fügen Sie an den Incident an, um intelligentere Entscheidungen zu treffen.

Beispiel:

Ein Microsoft Sentinel-Incident wurde aus einer Warnung durch eine Analyseregel erstellt, die IP-Adressen-Entitäten generiert.

Der Incident löst eine Automatisierungsregel aus, die ein Playbook mit den folgenden Schritten ausführt:

  • Starten, wenn ein neuer Microsoft Sentinel-Incident erstellt wird. Die im Vorfall dargestellten Entitäten werden in den dynamischen Feldern des Incident-Triggers gespeichert.

  • Für jede IP-Adresse können Sie einen externen Threat Intelligence-Anbieter, z. B. Virus Total, abfragen, um weitere Daten zu erhalten.

  • Fügen Sie die zurückgemeldeten Daten und Erkenntnisse als Kommentare zum Incident hinzu.

Bidirektionale Synchronisierung

Playbooks können dazu verwendet werden, Ihre Microsoft Sentinel-Incidents mit anderen Ticketausstellungssystemen zu synchronisieren.

Beispiel:

Erstellen Sie eine Automatisierungsregel für die Erstellung aller Incidents, und fügen Sie ein Playbook an, das ein Ticket in ServiceNow öffnet:

Orchestrierung

Verwenden Sie die SOC-Chat-Plattform, um die Warteschlange der Incidents besser zu überwachen.

Beispiel:

Ein Microsoft Sentinel-Incident wurde aus einer Warnung durch eine Analyseregel erstellt, die Benutzernamen- und IP-Adressen-Entitäten generiert.

Der Incident löst eine Automatisierungsregel aus, die ein Playbook mit den folgenden Schritten ausführt:

  • Starten, wenn ein neuer Microsoft Sentinel-Incident erstellt wird.

  • Es wird eine Nachricht an Ihren Sicherheitskanal in Microsoft Teams oder Slack gesendet, um Ihre Sicherheitsanalysten auf den Vorfall aufmerksam zu machen.

  • Senden Sie alle Informationen in der Warnmeldung per E-Mail an Ihren leitenden Netzwerkadministrator und Sicherheitsadministrator. Die E-Mail-Nachricht enthält die Optionsschaltflächen Blockieren und Benutzer ignorieren.

  • Warten Sie, bis Sie eine Antwort von den Admins erhalten, und fahren Sie dann mit der Ausführung fort.

  • Wenn die Administratoren Blockieren gewählt haben, senden Sie einen Befehl an die Firewall, um die IP-Adresse aus dem Alarm zu blockieren, und einen weiteren an Microsoft Entra ID, um den Benutzer zu deaktivieren.

Antwort

Sofortige Reaktion auf Bedrohungen, mit minimalem Personalaufwand.

Zwei Beispiele:

Beispiel 1: Reagieren Sie auf eine Analyseregel, die auf einen kompromittierten Benutzer hinweist, der vonMicrosoft Entra ID Protection entdeckt wurde:

  • Starten, wenn ein neuer Microsoft Sentinel-Incident erstellt wird.

  • Für alle Benutzerentitäten des Incidents, die als kompromittiert eingestuft werden:

    • Senden Sie eine Teams-Nachricht an den Benutzer, in der Sie um Bestätigung bitten, dass der Benutzer die verdächtige Aktion durchgeführt hat.

    • Prüfen Sie mit Microsoft Entra ID Protection, ob der Status des Benutzers als kompromittiert gilt. Microsoft Entra ID Protection stuft den Benutzer als riskant ein und wendet alle bereits konfigurierten Durchsetzungsrichtlinien an – zum Beispiel, dass der Benutzer bei der nächsten Anmeldung eine MFA verwenden muss.

      Hinweis

      Diese spezifische Microsoft Entra-Aktion leitet weder eine Erzwingungsaktivität für den Benutzer noch eine Konfiguration der Erzwingungsrichtlinie ein. Microsoft Entra ID Protection wird lediglich angewiesen, bereits definierte Richtlinien entsprechend anzuwenden. Die Durchsetzung hängt vollständig davon ab, dass die entsprechenden Richtlinien in Microsoft Entra ID Protection definiert sind.

Beispiel 2: Reagieren Sie auf eine Analyseregel, die auf einen kompromittierten Rechner hinweist, der von Microsoft Defender for Endpoint entdeckt wurde:

Manuelle Reaktion während der Untersuchung oder des Huntings

Reagieren Sie auf Bedrohungen im Rahmen aktiver Untersuchungsaktivitäten, ohne den Kontext zu verlassen.

Dank des neuen Entitätstriggers (jetzt in der Vorschau) können Sie direkt im Untersuchungsprozess unmittelbar Maßnahmen gegen einzelne entdeckte Bedrohungsakteure ergreifen. Diese Option ist auch im Kontext des Huntings nach Bedrohungen ohne Zusammenhang mit einem bestimmten Vorfall verfügbar. Sie können eine Entität im Kontext auswählen und Maßnahmen unmittelbar ergreifen, was Zeitaufwand und Komplexität reduziert.

Zu den Maßnahmen, die Sie mit diesem Playbooktyp für Entitäten ergreifen können, gehören u. a.:

  • Blockieren eines kompromittierten Benutzers
  • Blockieren von Datenverkehr von einer schädlichen IP-Adresse in Ihrer Firewall
  • Isolieren eines kompromittierten Hosts in Ihrem Netzwerk
  • Hinzufügen einer IP-Adresse zu einer Watchlist für sichere/unsichere Adressen oder zu Ihrer externen Konfigurationsverwaltungsdatenbank (CMDB)
  • Abrufen eines Dateihashberichts aus einer externen Threat Intelligence-Quelle und Hinzufügen eines Dateihashberichts zu einem Vorfall als Kommentar

So führen Sie ein Playbook aus

Playbooks können entweder manuell oder automatisch ausgeführt werden.

Sie sind für die automatische Ausführung konzipiert, und es empfiehlt sich, sie im Normalbetrieb auch so zu verwenden. Sie führen ein Playbook automatisch aus, indem Sie es als automatische Reaktion in einer Analyseregel (für Warnungen) oder als Aktion in einer Automatisierungsregel (für Incidents) festlegen.

In manchen Fällen müssen Playbooks jedoch manuell ausgeführt werden. Beispiel:

  • Wenn Sie ein neues Playbook erstellen, möchten Sie es testen, ehe Sie es in der Produktion ausführen.

  • Es kann Situationen geben, in denen Sie mehr manuelle Steuerungsmöglichkeiten benötigen, um zu beeinflussen, wann und ob ein bestimmtes Playbook ausgeführt wird.

    Sie führen ein Playbook manuell aus, indem Sie einen Vorfall, eine Warnung oder Entität öffnen und das dort angezeigte verknüpfte Playbook auswählen und ausführen. Dieses Feature ist derzeit für Warnungen allgemein verfügbar und für Vorfälle und Entitäten in der Vorschauphase.

Einstellen einer automatisierten Antwort

Security-Operations-Teams können Ihre Arbeitsbelastung erheblich reduzieren, indem sie die Routine-Reaktionen auf wiederkehrende Arten von Incidents und Warnungen vollständig automatisieren. So können Sie sich mehr auf einmalige Incidents und Warnungen, die Analyse von Mustern, die Ermittlung von Bedrohungen und mehr konzentrieren.

Das Einstellen der automatischen Antwort bedeutet, dass jedes Mal, wenn eine Analyseregel ausgelöst wird, zusätzlich zur Erstellung einer Warnung, die Regel ein Playbook ausführt, das die von der Regel erstellte Warnung als Eingabe erhält.

Wenn die Warnung einen Incident erzeugt, löst der Incident eine Automatisierungsregel aus, die wiederum ein Playbook ausführen kann, das als Eingabe den durch die Warnung erzeugten Incident erhält.

Erzeugung von Warnungen automatische Antwort

Für Playbooks, die durch die Erstellung von Warnungen ausgelöst werden und Warnungen als Eingaben erhalten (ihr erster Schritt ist „Microsoft Sentinel-Warnung“), fügen Sie das Playbook an eine Analyseregel an:

  1. Bearbeiten Sie die Analyseregel, mit der die Warnung generiert wird, für die Sie eine automatisierte Antwort definieren möchten.

  2. Wählen Sie unter Warnungsautomatisierung in der Registerkarte Automatisierte Reaktion das oder die Playbooks aus, die diese Analyseregel auslösen soll, wenn eine Warnung erstellt wird.

Erstellung von Incidents automatische Antwort

Für Playbooks, die durch die Erstellung von Incidents ausgelöst werden und Incidents als Eingaben erhalten (ihr erster Schritt ist „Microsoft Sentinel-Vorfall“), erstellen Sie eine Automatisierungsregel und definieren darin eine Aktion Playbook ausführen. Dies kann auf 2 Arten erfolgen:

  • Bearbeiten Sie die Analyseregel, mit der der Incident generiert wird, für die Sie eine automatisierte Antwort definieren möchten. Erstellen Sie unter Incident Automation in der Registerkarte automatisierte Antwort eine Automatisierungsregel. Dadurch wird eine automatisierte Antwort nur für diese Analyseregel erstellt.

  • Erstellen Sie in der Registerkarte Automatisierungsregeln auf der Seite Automatisierung eine neue Automatisierungsregel und geben Sie die entsprechenden Bedingungen und gewünschten Aktionen an. Diese Automatisierungsregel wird auf alle Analyseregeln angewendet, die die angegebenen Bedingungen erfüllen.

    Hinweis

    Microsoft Sentinel benötigt Berechtigungen zum Ausführen von durch Incidents ausgelöste Playbooks.

    Um ein Playbook basierend auf dem Incident-Trigger, sei es manuell oder über eine Automatisierungsregel, ausführen zu können, verwendet Microsoft Sentinel ein Dienstkonto, das speziell dazu autorisiert ist. Die Verwendung dieses Kontos (im Gegensatz zu Ihrem Benutzerkonto) erhöht das Sicherheitsniveau des Dienstes und aktiviert die Automatisierungsregeln-API zur Unterstützung von CI/CD-Anwendungsfällen.

    Diesem Konto müssen explizite Berechtigungen (in Form der Rolle Mitwirkender für Microsoft Sentinel-Automatisierung) für die Ressourcengruppe erteilt werden, in der sich das Playbook befindet. An diesem Punkt können Sie jedes Playbook in dieser Ressourcengruppe entweder manuell oder über eine beliebige Automatisierungsregel ausführen.

    Wenn Sie die Aktion Playbook ausführen zu einer Automatisierungsregel hinzufügen, wird eine Dropdownliste mit Playbooks für Ihre Auswahl angezeigt. Playbooks, für die Microsoft Sentinel nicht über Berechtigungen verfügt, werden als nicht verfügbar (ausgeblendet) angezeigt. Sie können Microsoft Sentinel direkt eine Berechtigung erteilen, indem Sie den Link Playbookberechtigungen verwalten auswählen.

    In einem Szenario mit mehreren Mandanten (Lighthouse) müssen Sie die Berechtigungen für den Mandanten definieren, in dem sich das Playbook befindet, auch wenn sich die Automatisierungsregel, die das Playbook aufruft, in einem anderen Mandanten befindet. Dazu müssen Sie über Besitzerberechtigungen für die Ressourcengruppe des Playbooks verfügen.

    Es gibt ein spezifisches Szenario mit einem Dienstanbieter für verwaltete Sicherheit (Managed Security Service Provider, MSSP) , bei dem ein Dienstanbieter bei seinem eigenen Mandanten angemeldet ist und mithilfe von Azure Lighthouse eine Automatisierungsregel im Arbeitsbereich eines Kunden erstellt. Diese Automatisierungsregel ruft dann ein Playbook auf, das zum Mandanten des Kunden gehört. In diesem Fall müssen Microsoft Sentinel Berechtigungen für beide Mandanten erteilt werden. Im Kundenmandanten gewähren Sie diese im Bereich Playbookberechtigungen verwalten, genau wie im regulären Szenario mit mehreren Mandanten. Um die relevanten Berechtigungen im Mandanten des Dienstanbieters zu erteilen, müssen Sie der Ressourcengruppe, in der sich das Playbook befindet, eine zusätzliche Azure Lighthouse-Delegierung hinzufügen, die der Azure Security Insights-App mit der Rolle Mitwirkender für Microsoft Sentinel-Automatisierung Zugriffsrechte erteilt. Hier erfahren Sie, wie Sie diese Delegierung hinzufügen.

Weitere Informationen finden Sie in der ausführlichen Anleitung zum Erstellen von Automatisierungsregeln.

Manuelles Ausführen eines Playbooks

Vollständige Automatisierung ist die beste Lösung für so viele Aufgaben bei der Bearbeitung von Vorfällen, der Untersuchung und der Schadensbegrenzung, die Sie automatisieren können. Dennoch kann es gute Gründe für eine Art hybride Automatisierung geben: die Verwendung von Playbooks, um eine Reihe von Maßnahmen für eine Vielzahl von Systemen in einem einzigen Befehl zusammenzufassen, wobei die Playbooks nur dann und dort ausgeführt werden, wo Sie es wünschen. Zum Beispiel:

  • Unter Umständen kann es wünschenswert sein, dass Ihre SOC-Analystinnen und -Analysten mehr Einfluss auf bestimmte Situationen haben, um diese besser kontrollieren zu können.

  • Sie möchten möglicherweise auch, dass sie bei Bedarf im Rahmen einer Untersuchung oder einer Bedrohungssuche Maßnahmen gegen bestimmte Bedrohungsakteure (Entitäten) bedarfsgesteuert ergreifen können, und zwar im gleichen Kontext, ohne zu einem anderen Bildschirm wechseln zu müssen. (Diese Möglichkeit befindet sich jetzt in der Vorschauphase.)

  • Sie möchten möglicherweise, dass Ihre SOC-Mitarbeiterinnen und -Mitarbeiter Playbooks schreiben, die für bestimmte Entitäten gelten (jetzt in der Preview) und ausschließlich manuell ausgeführt werden können.

  • Außerdem sollten Ihre SOC-Mitarbeiter die von ihnen geschriebenen Playbooks testen können, ehe sie in Automatisierungsregeln vollständig bereitgestellt werden.

Aus diesen und anderen Gründen ermöglich Microsoft Sentinel Ihnen, Playbooks für sowohl für Entitäten und Vorfälle (jetzt in der Vorschauphase) als auch für Warnungen bedarfsgesteuert manuell auszuführen.

  • Um ein Playbook bei einem bestimmten Incident auszuführen, wählen Sie den Incident im Raster auf der Seite Incidents aus. Wählen Sie im Azure-Portal im Bereich mit den Incidentdetails Aktionen und dann im Kontextmenü Playbook ausführen (Vorschau) aus. Wählen Sie im Defender-PortalPlaybook ausführen (Vorschau) direkt auf der Seite mit den Incidentdetails aus.

    Dadurch wird der Bereich Run playbook on incident (Playbook bei Incident ausführen) geöffnet.

  • Um ein Playbook bei einer Warnung auszuführen, wählen Sei einen Incident aus, geben Sie die Incidentdetails ein, wählen Sie auf der Registerkarte Warnungen eine Warnung aus, und wählen Sie Playbooks anzeigen aus.

    Dadurch wird der Bereich Warnungsplaybooks geöffnet.

  • Um ein Playbook für eine Entität auszuführen, wählen Sie auf eine der folgenden Weisen eine Entität aus:

    • Wählen Sie auf der Registerkarte Entitäten eines Vorfalls in der Liste eine Entität und am Ende ihrer Zeile in der Liste den Link Playbook ausführen (Vorschau) aus.
    • Wählen Sie im Graphen „Untersuchung“ eine Entität und im Seitenbereich der Entität die Schaltfläche Playbook ausführen (Vorschau) aus.
    • Wählen Sie unter Entitätsverhalten eine Entität und auf der Entitätsseite im linken Bereich die Schaltfläche Playbook ausführen (Vorschau) aus.

    Dadurch wird der Bereich Playbook für <Entitätstyp> ausführen geöffnet.

In jedem dieser Bereiche gibt es zwei Registerkarten: Playbooks und Ausführungen.

  • Die Registerkarte Playbooks enthält eine Liste aller Playbooks, auf die Sie Zugriff haben und die den entsprechenden Trigger verwenden: Microsoft Sentinel-Vorfall, Microsoft Sentinel-Warnung oder Microsoft Sentinel-Entität. Jedes Playbook in der Liste verfügt über eine Schaltfläche Ausführen, die Sie auswählen, um das Playbook sofort auszuführen.
    Wenn Sie ein durch Incidents ausgelöstes Playbook ausführen möchten, das in der Liste nicht angezeigt wird, lesen Sie oben den Hinweis zu Microsoft Sentinel-Berechtigungen.

  • Auf der Registerkarte Ausführungen wird eine Liste aller Ausführungen eines Playbooks für den von Ihnen ausgewählten Incident oder die ausgewählte Warnung angezeigt. Es kann ein paar Sekunden dauern, bis ein gerade abgeschlossene Ausführung in dieser Liste erscheint. Durch Auswahl einer spezifischen Ausführung wird das vollständige Ausführungsprotokoll in Azure Logic Apps geöffnet.

Verwalten Ihrer Playbooks

Auf der Registerkarte Aktive Playbooks wird eine Liste aller Playbooks angezeigt, auf die Sie Zugriff haben, gefiltert nach den Abonnements, die derzeit in Azure angezeigt werden. Der Abonnementfilter ist im Menü Verzeichnis + Abonnement der globalen Seiten-Kopfzeile verfügbar.

Wenn Sie auf einen Playbook-Namen klicken, werden Sie in Azure Logic Apps zur Hauptseite des Playbooks weitergeleitet. Die Spalte Status gibt an, ob Sie aktiviert oder deaktiviert ist.

In der Spalte Plan ist angegeben, ob das Playbook den Ressourcentyp Standard oder Verbrauch in Azure Logic Apps verwendet. Sie können die Liste nach Plantyp filtern, um nur einen Playbooktyp anzuzeigen. Sie werden feststellen, dass für Playbooks vom Typ „Standard“ die Benennungskonvention LogicApp/Workflow verwendet wird. Diese Konvention spiegelt die Tatsache wider, dass ein Standard-Playbook einen Workflow darstellt, der neben anderen Workflows in einer einzelnen Logik-App vorhanden ist.

Trigger-Art stellt den Azure Logic Apps Trigger dar, der dieses Playbook startet.

Art des Triggers Zeigt Komponententypen im Playbook an
Microsoft Sentinel-Vorfall/-Warnung/-Entität Das Playbook wird mit einem der Sentinel-Trigger (Vorfall, Warnung, Entität) gestartet
Verwenden der Microsoft Sentinel-Aktion Das Playbook wird mit einem Nicht-Sentinel-Trigger gestartet, verwendet aber eine Microsoft Sentinel-Aktion
Andere Das Playbook enthält keine Sentinel-Komponenten
Nicht initialisiert Das Playbook wurde erstellt, enthält jedoch keine Komponenten (Trigger oder Aktionen).

Auf der Azure Logic Apps-Seite des Playbooks können Sie weitere Informationen über das Playbook anzeigen, einschließlich eines Protokolls aller Ausführungszeiten und des Ergebnisses (Erfolg oder Misserfolg und andere Details). Sie können auch den Workflow-Designer in Azure Logic Apps öffnen und das Playbook direkt bearbeiten, wenn Sie über die entsprechenden Berechtigungen verfügen.

API-Verbindungen

API-Verbindungen werden verwendet, um Azure Logic Apps mit anderen Diensten zu verbinden. Bei jeder neuen Authentifizierung für einen Connector in Azure Logic Apps wird eine neue Ressource vom Typ API-Verbindung erstellt und enthält die Informationen, die beim Konfigurieren des Zugriffs auf den Dienst bereitgestellt werden.

Wenn Sie alle API-Verbindungen anzeigen möchten, geben Sie API-Verbindungen in das Suchfeld in der Kopfzeile des Azure-Portals ein. Beachten Sie die relevanten Spalten:

  • Anzeigename - der „freundliche“ Name (eigene Name), den Sie der Verbindung jedes Mal geben, wenn Sie eine Verbindung erstellen.
  • Status - zeigt den Verbindungsstatus an: Fehler, verbunden.
  • Ressourcengruppe: API-Verbindungen werden in der Ressourcengruppe der Playbook-Ressource (Azure Logic Apps) erstellt.

Eine weitere Möglichkeit zum Anzeigen von API-Verbindungen besteht darin, die SeiteAlle Ressourcen aufzurufen und nach Typ API-Verbindung zu filtern. Auf diese Weise können mehrere Verbindungen gleichzeitig ausgewählt, markiert und gelöscht werden.

Um die Autorisierung einer vorhandenen Verbindung zu ändern, geben Sie die Verbindungs-Ressource ein, und wählen Sie API-Verbindung bearbeitenaus.

Die folgenden empfohlenen Playbooks und ähnliche Playbooks stehen im Inhaltshub oder im GitHub-Repository von Microsoft Sentinel zur Verfügung:

Nächste Schritte