Automatisieren der Bedrohungsabwehr in Microsoft Sentinel mit Automatisierungsregeln
In diesem Artikel wird erläutert, was Microsoft Sentinel-Automatisierungsregeln sind und wie Sie diese verwenden, um Ihre SOAR-Vorgänge (Security Orchestration, Automation and Response) zu implementieren. Automatisierungsregeln erhöhen die Effektivität Ihres SOC und sparen Zeit und Ressourcen.
Wichtig
Microsoft Sentinel ist in der Unified Security Operations Platform von Microsoft im Microsoft Defender-Portal allgemein verfügbar. Für die Vorschau ist Microsoft Sentinel im Defender-Portal ohne Microsoft Defender XDR oder eine E5-Lizenz verfügbar. Weitere Informationen finden Sie unter Microsoft Sentinel im Microsoft Defender-Portal.
Was sind Automatisierungsregeln?
Automatisierungsregeln sind eine Möglichkeit, die Automatisierung in Microsoft Sentinel zentral zu verwalten, indem Sie eine kleine Reihe von Regeln definieren und koordinieren können, die in verschiedenen Szenarien angewendet werden können.
Automatisierungsregeln gelten für die folgenden Kategorien von Anwendungsfällen:
Führen Sie grundlegende Automatisierungsaufgaben für die Behandlung von Vorfällen aus, ohne Playbooks zu verwenden. Beispiel:
- Fügen Sie Vorfallaufgaben hinzu, welche Analysten befolgen sollen.
- Unterdrücken von lauten Vorfällen.
- Triagieren neuer Vorfälle durch Ändern ihres Status von „Neu“ in „Aktiv“ und Zuweisen eines Besitzers.
- Markieren von Vorfälle, um sie zu klassifizieren.
- Eskalieren eines Vorfalls durch Zuweisen eines neuen Besitzers.
- Schließen geklärter Vorfälle unter Angabe eines Grundes und Hinzufügung von Kommentaren.
Sie können Reaktionen für mehrere Analyseregeln gleichzeitig automatisieren.
Sie können die Reihenfolge der auszuführenden Aktionen steuern.
Überprüfen Sie die Inhalte des Vorfalls (Warnungen, Entitäten und andere Eigenschaften) und ergreifen Sie weitere Maßnahmen durch Aufrufen eines Playbooks.
Automatisierungsregeln können auch der Mechanismus sein, durch den Sie ein Playbook als Reaktion auf eine Warnung ausführen, die keinem Incident zugeordnet ist.
Kurz gesagt optimieren Automatisierungsregeln die Verwendung der Automatisierung in Microsoft Sentinel und ermöglichen es Ihnen, komplexe Workflows für Ihre Prozesse zur Orchestrierung von Vorfällen zu vereinfachen.
Komponenten
Automatisierungsregeln bestehen aus mehreren Komponenten:
- Trigger, die definieren, welche Art von Vorfallereignis die Regel ausführt, vorbehaltlich der Bedingungen.
- Bedingungen, welche die genauen Umstände bestimmen, unter denen die Regel ausgeführt wird und die Aktionen werden ausgeführt.
- Aktionen, um den Vorfall auf irgendeine Weise zu ändern oder ein Playbook aufzurufen, das komplexere Aktionen ausführt und mit anderen Diensten interagiert.
Auslöser
Automatisierungsregeln werden ausgelöst, wenn ein Incident erstellt oder aktualisiert wird bzw. wenn eine Warnung erstellt wird. Denken Sie daran, dass Vorfälle Warnungen einschließen und dass sowohl Warnungen als auch Vorfälle durch Analyseregeln erstellt werden. Erläuterungen finden Sie unter Erkennen von Bedrohungen in Microsoft Sentinel.
Die folgende Tabelle zeigt die verschiedenen möglichen Szenarios, die zur Ausführung einer Automatisierungsregel führen.
| Triggertyp | Ereignisse, die dazu führen, dass die Regel ausgeführt wird |
|---|---|
| Bei Erstellung des Vorfalls | Microsoft Defender-Portal: Microsoft Sentinel ist nicht in das Defender-Portal integriert: |
| Wenn der Vorfall aktualisiert wird | |
| Wann wird eine Warnung erstellt? |
Vorfallbasierte oder warnungsbasierte Automatisierung?
Bei Automatisierungsregeln, welche die Reaktion sowohl auf Vorfälle als auch Warnungen zentral behandeln - wie sollten Sie auswählen, was automatisiert werden soll und unter welchen Umständen?
Bei den meisten Anwendungsfällen ist die von Vorfällen ausgelöste Automatisierung der bevorzugte Ansatz. In Microsoft Sentinel ist ein Vorfall eine „Falldatei“ – eine Aggregation aller relevanten Beweise für eine bestimmte Untersuchung. Es handelt sich um einen Container für Warnungen, Entitäten, Kommentare, Zusammenarbeit und andere Artefakte. Im Gegensatz zu Warnungen, die einzelne Nachweise sind, sind Vorfälle modifizierbar, haben den aktuellsten Status und können mit Kommentaren, Tags und Lesezeichen erweitert werden. Mit dem Incident können Sie den Angriffsverlauf nachverfolgen, der sich mit der Ergänzung neuer Warnungen weiterentwickelt.
Aus diesen Gründen ist es sinnvoller, Ihre Automatisierung um Vorfälle herum zu erstellen. Die am besten geeignete Möglichkeit zum Erstellen von Playbooks besteht also darin, sie auf dem Microsoft Sentinel-Vorfalltrigger in Azure Logic Apps zu basieren.
Der Hauptgrund für die Verwendung der durch Warnungen ausgelösten Automatisierung ist die Reaktion auf Warnungen, die von Analyseregeln generiert werden, die keine Vorfälle erstellen (d. h., wenn die Erstellung von Vorfällen auf der Registerkarte Vorfalleinstellungen des Assistenten für Analyseregeln deaktiviert ist).
Dieser Grund ist besonders relevant, wenn Ihr Microsoft Sentinel-Arbeitsbereich in das Defender-Portal integriert ist. In diesem Szenario erfolgt die Erstellung von Incidents im Defender-Portal, und daher müssen die Regeln zur Erstellung von Incidents in Microsoft Sentinel deaktiviert werden.
Auch wenn Sie nicht in das einheitliche Portal integriert werden müssen, entscheiden Sie sich möglicherweise trotzdem für die Verwendung von Benachrichtigungen ausgelöster Automatisierung, wenn Sie andere externe Logik verwenden möchten, um zu entscheiden, ob und wann Vorfälle aus Warnungen erstellt werden sollen und wie Warnungen gruppiert werden. Zum Beispiel:
Ein durch eine Warnung ausgelöstes Playbook, die keinen zugehörigen Vorfall hat, die Warnung mit Informationen aus anderen Quellen bereichern und basierend auf einer externen Logik entscheiden kann, ob ein Vorfall erstellt werden soll oder nicht.
Ein durch eine Warnung ausgelöstes Playbook kann anstatt einen Vorfall zu erstellen, nach einem geeigneten vorhandenen Vorfall suchen, um die Warnung hinzuzufügen. Erfahren Sie mehr über die Erweiterung von Vorfällen.
Ein durch eine Warnung ausgelöstes Playbook kann einen SOC-Mitarbeiter der Warnung benachrichtigen, sodass das Team entscheiden kann, ob ein Vorfall erstellt werden soll.
Ein durch eine Warnung ausgelöstes Playbook kann an ein externes Ticketingsystem für die Erstellung und Verwaltung von Vorfällen gesendet werden, um für jede Warnung ein neues Ticket zu erstellen.
Hinweis
Die durch Warnungen ausgelöste Automatisierung ist nur für Warnungen verfügbar, die mit Analyseregeln der Typen Geplant, NRT oder Microsoft-Sicherheit erstellt wurden.
Die durch Warnungen ausgelöste Automatisierung für von Microsoft Defender XDR erstellte Warnungen ist nicht im Defender-Portal verfügbar. Weitere Informationen finden Sie unter Automatisierung im Defender-Portal.
Bedingungen
Es können komplexe Bedingungssätze definiert werden, die bestimmen, wann Aktionen (siehe unten) ausgeführt werden sollen. Zu diesen Bedingungen gehören das Ereignis, das die Regel auslöst (Vorfall erstellt oder aktualisiert oder Warnung erstellt), die Zustände oder Werte der Eigenschaften und Entitätseigenschaften des Vorfalls sowie die Analyseregel oder Regeln, durch die der Vorfall generiert worden ist.
Wenn eine Automatisierungsregel ausgelöst wird, überprüft sie den auslösenden Vorfall anhand der in der Regel definierten Bedingungen. Für Vorfälle werden die eigenschaftenbasierten Bedingungen nach dem aktuellen Zustand der Eigenschaft zum Zeitpunkt der Auswertung ausgewertet, oder nach den Änderungen am Zustand der Eigenschaft (siehe unten). Da eine einzelne Vorfallerstellung oder ein Aktualisierungsereignis mehrere Automatisierungsregeln auslösen könnten, macht die Reihenfolge, in der sie ausgeführt werden (siehe unten), bei der Auswertung des Ergebnisses der Bedingungen den Unterschied. Die in der Regel definierten Aktionen werden nur ausgeführt, wenn alle Bedingungen erfüllt sind.
Vorfallerstellungsauslöser
Bei Regeln, die mithilfe des Auslösers definiert werden Wenn ein Vorfall erstellt wird, können Sie mithilfe einer oder mehrerer der folgenden Operatoren Bedingungen definieren, mit denen der aktuelle Zustand der Werte einer bestimmten Liste von Vorfalleigenschaften überprüft wird:
- gleich oder ungleich dem in der Bedingung definierten Wert.
- enthält oder enthält nicht den in der Bedingung definierten Wert.
- Beginnt mit oder beginnt nicht mit dem in der Bedingung definierten Wert.
- Endet mit oder endet nicht mit dem in der Bedingung definierten Wert.
Wenn Sie z. B. Analytische Regelnamen als Enthält == Brute Force-Angriff auf einen Cloud PC definieren, erfüllt eine Analyseregel mit dem Brute Force-Angriff auf das Azure-Portal nicht die Bedingung. Wenn Sie jedoch Analytische Regelnamen als Enthält nicht == Benutzeranmeldeinformationen definieren, dann erfüllen sowohl der Brute-Force-Angriff auf einen Cloud PC und Brute-Force gegen Azure-Portal Analyseregeln die Bedingung.
Hinweis
Der aktuelle Zustand in diesem Kontext bezieht sich auf den Moment, in dem die Bedingung ausgewertet wird, das heißt, auf den Moment, in dem die Automatisierungsregel ausgeführt wird. Wenn mehr als eine Automatisierungsregel als Reaktion auf die Erstellung dieses Vorfalls definiert wird, gelten Änderungen an dem Vorfall durch eine zuvor ausgeführte Automatisierungsregel als aktueller Zustand für später ausgeführte Regeln.
Vorfallaktualisierungsauslöser
Die Bedingungen, die in Regeln ausgewertet werden, die mithilfe des Auslösers definiert worden sind Wenn ein Vorfall aktualisiert wird, umfassen all diejenigen, die als Vorfallerstellungsauslöser aufgeführt sind. Der Aktualisierungsauslöser enthält jedoch weitere Eigenschaften, die ausgewertet werden können.
Eine dieser Eigenschaften ist Aktualisiert von. Mit dieser Eigenschaft können Sie den Quelltyp nachverfolgen, der die Änderung des Vorfalls vorgenommen hat. Sie können eine Bedingung erstellen, die auswertet, ob der Incident durch einen der folgenden Werte aktualisiert wurde, je nachdem, ob Sie Ihren Arbeitsbereich in das Defender-Portal integriert haben:
- Eine Anwendung, einschließlich Anwendungen in den Azure- und Defender-Portalen
- Ein Benutzerkonto, einschließlich Änderungen, die von Benutzern/Benutzerinnen in den Azure- und Defender-Portalen vorgenommen wurden
- AIR, für Updates durch automatisierte Untersuchung und Reaktion in Microsoft Defender for Office 365
- Eine Warnungsgruppierung (die dem Incident Warnungen hinzugefügt hat), einschließlich Warnungsgruppierungen, die sowohl von Analyseregeln als auch von integrierter Microsoft Defender XDR-Korrelationslogik durchgeführt wurden
- Ein Playbook
- Automatisierungsregel
- Sonstiges, wenn keiner der oben genannten Werte zutrifft
Mithilfe dieser Bedingung können Sie beispielsweise diese Automatisierungsregel anweisen, dass sie an allen Änderungen an einem Vorfall ausgeführt werden, es sei denn, sie wurden von einer anderen Automatisierungsregel vorgenommen.
Genauer gesagt verwendet der Aktualisierungsauslöser auch andere Operatoren, die Statusänderungen in den Werten von Vorfalleigenschaften sowie ihren aktuellen Status überprüfen. Eine Bedingung für eine Statusänderung ist erfüllt, wenn:
auf den Wert einer Vorfalleigenschaft Folgendes zutrifft:
- geändert (unabhängig vom tatsächlichen Wert vorher oder nachher).
- geändert von dem in der Bedingung definierten Wert.
- geändert in den in der Bedingung definierten Wert.
- hinzugefügt zu (dies gilt für Eigenschaften mit einer Liste von Werten).
Tag-Eigenschaft: einzeln oder als Auflistung
Die Tag-Eigenschaft des Incidents ist eine Auflistung einzelner Elemente, wobei auf einen einzelnen Incident auch mehrere Tags angewandt werden können. Sie können Bedingungen definieren, die jedes Tag in der Auflistung einzeln überprüfen, sowie Bedingungen, die die Auflistung von Tags als Einheit überprüfen.
- Operatoren für einzelnen Tags überprüfen die Bedingung für jedes Tag in der Auflistung. Die Auswertung ist true, wenn mindestens ein Tag die Bedingung erfüllt.
- Operatoren für die Auflistung aller Tags überprüft die Bedingung anhand der Auflistung von Tags als Einheit. Die Auswertung ist nur dann true, wenn die Auflistung insgesamt die Bedingung erfüllt.
Diese Unterscheidung ist wichtig, wenn Ihre Bedingung negativ ist („enthält nicht“), und einige Tags in der Auflistung die Bedingung erfüllen, andere hingegen nicht.
Sehen Sie sich ein Beispiel an, in dem Ihre Bedingung Tag enthält nicht „2024“ lautet und Sie zwei Incidents mit zwei Tags haben:
| \ Incidents ▶ Bedingung ▼ \ |
Incident 1 Tag 1: 2024 Tag 2: 2023 |
Incident 2 Tag 1: 2023 Tag 2: 2022 |
|---|---|---|
| Jedes einzelne Tag enthält nicht „2024“ |
TRUE | TRUE |
| Auflistung aller Tags enthält nicht „2024“ |
FALSE | TRUE |
In diesem Beispiel in Incident 1:
- Wenn die Bedingung jedes Tag einzeln überprüft, ist die Gesamtbedingung true, da mindestens ein Tag vorhanden ist, das die Bedingung erfüllt (enthält nicht „2024“)
- Wenn die Bedingung alle Tags im Incident als Einheit überprüft, ist die Gesamtbedingung false, da mindestens ein Tag vorhanden ist, das die Bedingung nicht erfüllt (enthält „2024“).
Bei Incident 2 ist das Ergebnis unabhängig vom Typ der definierten Bedingung immer gleich.
Unterstützte Entitätseigenschaften
Eine Liste der Entitätseigenschaften, die als Bedingungen für Automatisierungsregeln unterstützt werden, finden Sie in der Referenz zu Microsoft Sentinel-Automatisierungsregeln.
Warnungserstellungsauslöser
Derzeit ist die einzige Bedingung, die für den Warnungserstellungstrigger konfiguriert werden kann, der Satz von Analyseregeln, für welche die Automatisierungsregel ausgeführt wird.
Aktionen
Es können Aktionen definiert werden, die ausgeführt werden, wenn die Bedingungen (siehe oben) erfüllt sind. Sie können viele Aktionen in einer Regel definieren, und Sie können die Reihenfolge wählen, in der sie ausgeführt werden (siehe unten). Die folgenden Aktionen können mithilfe von Automatisierungsregeln definiert werden, ohne dass die erweiterte Funktionalität eines Playbookserforderlich ist:
Hinzufügen einer Aufgabe zu einem Vorfall – Sie können eine Checkliste mit Aufgaben für Analysten erstellen, welche die Analysten bei der Analyse, Untersuchung und Behebung des Vorfalls befolgen sollen, damit keine kritischen Schritte übersehen werden.
Ändern des Status eines Incidents, sodass der Workflow auf dem neuesten Stand bleibt.
- Wenn Sie zu „geschlossen“ wechseln, wird der Schließungsgrund angegeben und ein Kommentar hinzugefügt. Dies hilft Ihnen dabei, ihre Leistung und Effektivität zu überwachen und eine Feinabstimmung durchführen, um False Positives zu reduzieren.
Ändern des Schweregrades eines Incidents: Basierend auf dem Vorhandensein, der Abwesenheit, den Werten oder den Attributen der am Incident beteiligten Entitäten können Sie eine Neubewertung und Neupriorisierung vornehmen.
Zuweisung eines Incidents zu einem Besitzer: Dies hilft Ihnen, Incidenttypen an die Mitarbeiter*innen weiterzuleiten, die am besten geeignet sind, sie zu bearbeiten, oder aber an das am schnellsten verfügbare Personal.
Hinzufügen eines Tags zu einem Incident: Dies ist hilfreich bei der Klassifizierung von Incidents nach Betreff, Angreifer oder nach einem anderen gemeinsamen Nenner.
Außerdem können Sie eine Aktion zum Ausführen eines Playbooks definieren, um komplexere Antwortaktionen zu erstellen, die auch externe Systeme involvieren können. Die Playbooks, die in einer Automatisierungsregel verwendet werden können, hängen vom Auslöser ab, auf dem die Playbooks und die Automatisierungsregel basieren: Nur Vorfallauslöser-Playbooks können von Regeln zur Automatisierung von Vorfällen ausgeführt werden, und nur Warnungstrigger-Playbooks können von Warnungstriggerautomatisierungsregeln ausgeführt werden. Sie können mehrere Aktionen definieren, die Playbooks oder Kombinationen von Playbooks und anderen Aktionen aufrufen. Aktionen werden in der Reihenfolge ausgeführt, in der sie in der Regel aufgeführt sind.
Playbooks, die eine der Versionen von Azure Logic Apps (Standard oder Verbrauch) verwenden, stehen zur Ausführung aufgrund von Automatisierungsregeln zur Verfügung.
Ablaufdatum
Sie können ein Ablaufdatum für eine Automatisierungsregel definieren. Die Regel wird nach Ablauf dieses Datums deaktiviert. Dies ist nützlich für die Behandlung (d. h. das Schließen) von "Rausch"-Incidents, die durch geplante, zeitlich begrenzte Aktivitäten wie Penetrationstests verursacht werden.
Auftrag
Sie können die Reihenfolge definieren, in der die Automatisierungsregeln ausgeführt werden. Spätere Automatisierungsregeln bewerten die Bedingungen des Vorfalls entsprechend seines Zustands, nachdem sie von vorherigen Automatisierungsregeln beeinflusst wurden.
Wenn z. B. die „Erste Automatisierungsregel“ den Schweregrad eines Vorfalls von „Mittel“ auf „Niedrig“ gesetzt hat und die "Zweite Automatisierungsregel" so definiert ist, dass sie nur bei Vorfällen mit mittlerem oder höherem Schweregrad ausgeführt wird, wird sie bei diesem Vorfall nicht ausgeführt.
Die Reihenfolge der Automatisierungsregeln, die Incidentaufgaben hinzufügen, bestimmt die Reihenfolge, in der die Aufgaben in einem bestimmten Incident angezeigt werden.
Regeln, die auf dem Update-Trigger basieren, besitzen eine eigene separate Reihenfolgenwarteschlange. Wenn solche Regeln ausgelöst werden, um für einen gerade erstellten Vorfall (durch eine von einer anderen Automatisierungsregel vorgenommene Änderung) ausgeführt zu werden, werden sie erst ausgeführt, nachdem alle anwendbaren Regeln, die auf dem Erstellen-Trigger basieren, fertig ausgeführt wurden.
Hinweise zur Ausführungsreihenfolge und Priorität
- Durch das Festlegen der Nummer für die Reihenfolge in Automatisierungsregeln wird die Ausführungsreihenfolge bestimmt.
- Jeder Triggertyp hat eine eigene Warteschlange.
- Bei Regeln, die im Azure-Portal erstellt wurden, wird das Feld Reihenfolge automatisch mit der Nummer aufgefüllt, die auf die höchste Nummer folgt, die von vorhandenen Regeln desselben Triggertyps verwendet wird.
- Bei Regeln, die auf andere Weise (Befehlszeile, API usw.) erstellt wurden, muss die Nummer für die Reihenfolge manuell zugewiesen werden.
- Es gibt keinen Überprüfungsmechanismus, der verhindert, dass mehrere Regeln dieselbe Nummer für die Reihenfolge haben, auch innerhalb desselben Triggertyps.
- Sie können zulassen, dass zwei oder mehr Regeln desselben Triggertyps die gleiche Nummer für die Reihenfolge aufweisen, wenn die Reihenfolge bei der Ausführung keine Rolle spielt.
- Bei Regeln desselben Triggertyps mit derselben Nummer für die Reihenfolge wählt die Ausführungs-Engine nach dem Zufallsprinzip aus, welche Regeln in welcher Reihenfolge ausgeführt werden.
- Bei Regeln unterschiedlicher Incidenttriggertypen werden alle anwendbaren Regeln mit dem Triggertyp Incidenterstellung zuerst ausgeführt (gemäß den Nummern für die Reihenfolge) und erst dann die Regeln mit dem Triggertyp Incidentaktualisierung (gemäß ihrer Nummer für die Reihenfolge).
- Regeln werden immer sequenziell, niemals parallel ausgeführt.
Hinweis
Nach dem Onboarding in das Defender-Portal wird für den Fall, dass in einem Zeitraum von fünf bis zehn Minuten mehrere Änderungen an demselben Incident vorgenommen wurden, lediglich ein einzelnes Update mit ausschließlich der letzten Änderung an Microsoft Sentinel übermittelt.
Gängige Anwendungsfälle und -szenarien
Incidentaufgaben
Automatisierungsregeln ermöglichen eine Standardisierung und Formalisierung der erforderlichen Schritte für Sichtung, Untersuchung und Behebung von Incidents, indem Aufgaben erstellt werden, die abhängig von den Bedingungen, die Sie in der Automatisierungsregel und der Bedrohungserkennungslogik in den zugrunde liegenden Analyseregeln festgelegt haben, auf einen einzelnen Incident, bestimmte Gruppen von Incidents oder auf alle Incidents angewendet werden können. Die auf einen Incident angewendeten Aufgaben werden auf der Seite des Incidents angezeigt, sodass Analysten über eine vollständige Liste der Aktionen, die sie ausführen müssen, direkt vor ihnen verfügen, damit sie keine wichtigen Schritte verpassen.
Vorfall- und Warnungsautomatisierung
Automatisierungsregeln können durch die Erstellung oder Aktualisierung von Vorfällen und auch durch die Erstellung von Warnungen ausgelöst werden. Diese Vorkommnisse können alle automatisierten Antwortketten auslösen, die Playbooks enthalten können (spezielle Berechtigungen sind erforderlich).
Playbooks für Microsoft-Anbieter auslösen
Automatisierungsregeln bieten eine Möglichkeit, die Behandlung von Microsoft-Sicherheitswarnungen zu automatisieren, indem diese Regeln auf Incidents angewendet werden, die aus den Warnmeldungen erstellt wurden. Die Automatisierungsregeln können Playbooks aufrufen (spezielle Berechtigungen sind erforderlich) und die Vorfälle mit allen Details, einschließlich Alarmen und Entitäten, an diese übergeben. Im Allgemeinen schreiben die bewährten Methoden von Microsoft Sentinel die Verwendung der Warteschlange für Vorfälle als Schwerpunkt von Sicherheitsmaßnahmen vor.
Microsoft-Sicherheitswarnungen umfassen Folgendes:
- Microsoft Entra ID-Schutz
- Microsoft Defender für Cloud
- Microsoft Defender for Cloud Apps
- Microsoft Defender für Office 365
- Microsoft Defender für den Endpunkt
- Microsoft Defender for Identity
- Microsoft Defender für IoT
Mehrere sequenzierte Playbooks/Aktionen in einer einzigen Regel
Sie haben jetzt die Möglichkeit, die Ausführungsreihenfolge von Aktionen und Playbooks in einer einzigen Automatisierungsregel nahezu vollständig zu steuern. Außerdem steuern Sie die Reihenfolge der Ausführung der Automatisierungsregeln selbst. So können Sie Ihre Playbooks stark vereinfachen, indem Sie sie auf eine einzelne Aufgabe oder eine kleine, überschaubare Abfolge von Aufgaben reduzieren und diese kleinen Playbooks in verschiedenen Kombinationen in unterschiedlichen Automatisierungsregeln kombinieren.
Gleichzeitiges Zuweisen eines Playbooks zu mehreren Analyse-Regeln
Wenn Sie eine Aufgabe haben, die Sie für alle Ihre Analyseregeln automatisieren möchten, z. B. die Erstellung eines Support-Tickets in einem externen Ticketing-System, können Sie ein einziges Playbook auf alle Ihre Analyseregeln – einschließlich aller zukünftigen Regeln – in einem Zug anwenden. Das macht einfache, aber immer wiederkehrende Wartungs- und Housekeeping-Aufgaben deutlich weniger mühsam.
Automatische Zuweisung von Incidents
Sie können Incidents automatisch dem richtigen Besitzer zuweisen. Wenn es in Ihrem SOC einen Analysten gibt, der auf eine bestimmte Plattform spezialisiert ist, können alle Incidents, die sich auf diese Plattform beziehen, automatisch diesem Analysten zugewiesen werden.
Incidentunterdrückung anwenden
Sie können Regeln zur automatischen Behebung von Incidents mit bekannten falsch/gutartigen Positivmeldungen ohne Verwendung von Playbooks anwenden. Bei der Durchführung von Penetrationstests, geplanten Wartungen oder Upgrades oder beim Testen von Automatisierungsverfahren können beispielsweise viele False Positive-Incidents erzeugt werden, die das SOC ignorieren sollte. Eine zeitlich begrenzte Automatisierungsregel kann diese Vorfälle automatisch schließen, wenn sie erstellt werden, und sie gleichzeitig mit einem Deskriptor für die Ursache ihrer Erstellung versehen.
Zeitlich begrenzte Automatisierung
Sie können Ihren Automatisierungsregeln Ablaufdaten hinzufügen. Es kann auch andere Fälle als die Incidentunterdrückung geben, die eine zeitlich begrenzte Automatisierung erfordern. Vielleicht möchten Sie einen bestimmten Incidenttyp einem bestimmten Benutzerkonto (z. B. von einem Praktikanten/einer Praktikantin oder einer Beratungsfirma) für einen bestimmten Zeitraum zuweisen. Wenn der Zeitrahmen im Voraus bekannt ist, können Sie effektiv bewirken, dass die Regel am Ende ihrer Relevanz deaktiviert wird, ohne dass Sie daran denken müssen.
Vorfälle automatisch taggen
Sie können automatisch Freitext-Tags zu Ereignissen hinzufügen, um sie nach beliebigen Kriterien zu gruppieren oder zu klassifizieren.
Durch Aktualisierungsauslöser hinzugefügte Anwendungsfälle
Jetzt, da durch Änderungen an Vorfällen Automatisierungsregeln ausgelöst werden können, können weitere Szenarien automatisiert werden.
Erweitern der Automatisierung beim der Weiterentwicklung von Vorfällen
Sie können mithilfe des Aktualisierungsauslösers viele der oben genannten Anwendungsfälle auf Vorfälle anwenden, während ihre Untersuchung Fortschritte macht und Analysten Warnungen, Kommentare und Tags hinzufügen. Steuern Sie die Warnungsgruppierungen in Vorfällen.
Aktualisieren der Orchestrierung und Benachrichtigung
Benachrichtigen Sie Ihre verschiedenen Teams und andere Mitarbeiter, wenn Änderungen an Vorfällen vorgenommen werden, sodass sie keine kritischen Updates verpassen. Eskalieren Sie Vorfälle, indem Sie sie neuen Besitzern zuweisen und die neuen Besitzer über die Zuweisung informieren. Steuern Sie, wann und wie Vorfälle erneut geöffnet werden.
Verwalten der Synchronisierung mit externen Systemen
Wenn Sie Playbooks verwendet haben, um beim Erstellen von Vorfällen Tickets in externen Systemen zu erstellen, können Sie mit einer Regel zur Automatisierung von Aktualisierungsauslösern ein Playbook aufrufen, mit dem diese Tickets aktualisiert werden.
Ausführung von Automatisierungsregeln
Automatisierungsregeln werden sequenziell ausgeführt, entsprechend der von Ihnen festgelegtenReihenfolge. Jede Automatisierungsregel wird ausgeführt, nachdem die vorhergehende ihre Ausführung beendet hat. Innerhalb einer Automatisierungsregel werden alle Aktionen nacheinander in der Reihenfolge ausgeführt, in der sie definiert sind.
Playbookaktionen innerhalb einer Automatisierungsregel können unter bestimmten Umständen gemäß den folgenden Kriterien unterschiedlich behandelt werden:
| Playbooklaufzeit | Automatisierungsregel geht zur nächsten Aktion über... |
|---|---|
| Weniger als eine Sekunde | Unmittelbar nach Abschluss des Playbooks |
| Weniger als zwei Minuten | Bis zu zwei Minuten nach Beginn der Ausführung des Playbooks, aber nicht mehr als 10 Sekunden nach Abschluss des Playbooks |
| Mehr als zwei Minuten | Zwei Minuten nach Beginn der Ausführung des Playbooks, unabhängig davon, ob sie abgeschlossen wurde oder nicht |
Berechtigungen für Automatisierungsregeln zum Ausführen von Playbooks
Wenn eine Microsoft Sentinel-Automatisierungsregel ein Playbook ausführt, verwendet sie ein spezielles Microsoft Sentinel-Dienstkonto, das speziell für diese Aktion autorisiert ist. Die Verwendung dieses Kontos (im Gegensatz zu Ihrem Benutzerkonto) erhöht die Sicherheitsstufe des Diensts.
Damit eine Automatisierungsregel ein Playbook ausführen kann, muss diesem Konto explizit die Berechtigung für die Ressourcengruppe erteilt werden, in der sich das Playbook befindet. An diesem Punkt kann jede Automatisierungsregel jedes beliebige Playbook in dieser Ressourcengruppe ausführen.
Wenn Sie eine Automatisierungsregel konfigurieren und eine Aktion Playbook ausführen hinzufügen, wird eine Dropdown Liste mit Playbooks angezeigt. Playbooks, für die Microsoft Sentinel nicht über Berechtigungen verfügt, werden als nicht verfügbar angezeigt ("abgeblendet"). Sie können Microsoft Sentinel Berechtigungen für die Ressourcengruppen der Playbooks direkt erteilen, indem Sie den Link Playbook Berechtigungen verwalten auswählen. Um diese Berechtigungen zu erteilen, benötigen Sie Besitzerberechtigungen für diese Ressourcengruppen. Weitere Informationen finden Sie in den vollständigen Berechtigungsanforderungen.
Berechtigungen in einer mehrinstanzenfähigen Architektur
Automatisierungsregeln unterstützen arbeitsbereichsübergreifende und mehrinstanzenfähige Bereitstellungen vollständig (im Falle von mehrinstanzenfähige Bereitstellungen unter Verwendung von Azure Lighthouse).
Wenn Ihre Microsoft Sentinel-Bereitstellung eine mehr mehrinstanzenfähige Architektur verwendet, können Sie daher eine Automatisierungsregel in einem Mandanten verwendet, die ein Playbook in einem anderen Mandanten ausführt. Aber die Berechtigungen für Sentinel zum Ausführen der Playbooks müssen in dem Mandanten definiert werden, in dem sich die Playbooks befinden, und nicht in dem Mandanten, in dem die Automatisierungsregeln definiert sind.
Im speziellen Fall eines Managed Security Service Provider (MSSP), bei dem ein Dienstanbieter-Mandant einen Microsoft Sentinel-Arbeitsbereich in einem Kundenmandanten verwaltet, gibt es zwei bestimmte Szenarien, die Ihre Aufmerksamkeit rechtfertigen:
Eine Automatisierungsregel, die im Kunden-Mandanten erstellt wurde, ist so konfiguriert, dass ein Playbook ausgeführt wird, das sich im Mandanten des Dienstanbieters befindet.
Dieser Ansatz dient normalerweise zum Schutz geistigen Eigentums im Playbook. Dies ist ohne Weiteres umsetzbar. Wenn Sie eine Playbookaktion in Ihrer Automatisierungsregel definieren und zu der Phase kommen, in der Sie Microsoft Sentinel-Berechtigungen für die relevante Ressourcengruppe erteilen, in der sich das Playbook befindet (über den Bereich Playbook-Berechtigungen verwalten), können Sie die Ressourcengruppen sehen, die zum Mandanten des Dienstanbieters gehören, unter den Ressourcengruppen, aus denen Sie auswählen können. Sehen Sie sich hier eine Beschreibung des gesamten Ablaufs an.
Eine Automatisierungsregel, die (angemeldet beim Mandanten des Dienstanbieters) im Arbeitsbereich des Kunden erstellt wurde, ist so konfiguriert, dass ein Playbook ausgeführt wird, das sich im Mandanten des Kunden befindet.
Diese Konfiguration wird verwendet, wenn keine Notwendigkeit besteht, geistiges Eigentum zu schützen. Damit dieses Szenario funktioniert, müssen Microsoft Sentinel in beiden Mandanten Berechtigungen zum Ausführen des Playbooks 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 eine zusätzliche Azure Lighthouse-Delegierung hinzufügen, die Zugriffsrechte für die Azure Security Insights-App mit der Rolle Mitwirkender an Microsoft Sentinel Automation für die Ressourcengruppe gewährt, in der sich das Playbook befindet.
Das Szenario sieht folgendermaßen aus:
Informationen zum Einrichten finden Sie in unseren Anweisungen.
Erstellen und Verwalten von Automatisierungsregeln
Sie können je nach Bedarf und Anwendungsfall Automatisierungsregeln aus verschiedenen Bereichen in Microsoft Sentinel oder Defender-Portal erstellen und verwalten.
Seite „Automatisierung“
Automatisierungsregeln können zentral auf der Seite Automatisierung auf der Registerkarte Automatisierungsregeln verwaltet werden. Von dort aus können Sie neue Automatisierungsregeln erstellen und die vorhandenen Regeln bearbeiten. Sie können auch Automatisierungsregeln verschieben, um die Reihenfolge der Ausführung zu ändern, und sie aktivieren oder deaktivieren.
Auf der Seite Automatisierung werden alle Regeln angezeigt, die im Arbeitsbereich definiert sind, zusammen mit Ihrem Status (aktiviert/deaktiviert) und den Analyseregeln, auf die sie angewandt werden.
Wenn Sie eine Automatisierungsregel benötigen, die für Vorfälle von Microsoft Defender XDR gilt, oder die aus vielen Analyseregeln in Microsoft Sentinel erstellt wird, erstellen Sie sie direkt auf der Seite Automatisierung.
Analyseregel-Assistent
Auf der Registerkarte Automatisierte Antwort des Analyseregel-Assistenten von Microsoft Sentinel können Sie unter Automatisierungsregeln Automatisierungsregeln, die für bestimmte im Assistenten erstellte oder bearbeitete Analyseregeln gelten, anzeigen, bearbeiten und erstellen.
Wenn Sie die Automatisierungsregel von hier aus im Bedienfeld Neue Automatisierungsregel erstellen erstellen, wird die Bedingung für die Analyseregel als nicht verfügbar angezeigt, da diese Regel bereits so eingestellt ist, dass sie nur für die Analyseregel gilt, die Sie im Assistenten bearbeiten. Alle anderen Konfigurationsoptionen sind weiterhin verfügbar.
Seite „Incidents“
Sie können auch eine Automatisierungsregel auf der Seite Incidents erstellen, um auf einen einzelnen, wiederkehrenden Incident zu reagieren. Dies ist hilfreich beim Erstellen einer Unterdrückungsregel zum automatischen Schließen „lauter“ Vorfälle.
Wenn Sie im Bereich Neue Automatisierungsregel erstellen eine neue Automatisierungsregel erstellen, werden in alle Felder Werte aus dem Vorfall eingegeben. Sie benennt die Regel mit demselben Namen wie den Vorfall, wendet sie auf die Analyseregel an, die den Vorfall erzeugt hat, und verwendet alle verfügbaren Entitäten im Incident als Bedingungen der Regel. Außerdem wird standardmäßig eine Unterdrückungsaktion (Schließen) vorgeschlagen, und es wird ein Ablaufdatum für die Regel vorgeschlagen. Sie können Bedingungen und Aktionen hinzufügen oder entfernen und das Ablaufdatum ändern, wie Sie möchten.
Exportieren und Importieren von Automatisierungsregeln
Exportieren Sie jetzt Ihre Automatisierungsregeln in Azure Resource Manager (ARM)-Vorlagendateien und importieren Sie die Regeln aus diesen Dateien, um Ihre Microsoft Sentinel-Bereitstellungen als Code zu verwalten und zu steuern. Die Exportaktion erstellt eine JSON-Datei am Downloadspeicherort Ihres Browsers, die Sie dann umbenennen, verschieben und auch sonst wie jede andere Datei behandeln können.
Die exportierte JSON-Datei ist arbeitsbereichsunabhängig, sodass sie in andere Arbeitsbereiche und sogar andere Mandanten importiert werden kann. Als Code kann sie außerdem versionskontrolliert, aktualisiert und in einem verwalteten CI/CD-Framework bereitgestellt werden.
Die Datei enthält alle Parameter, die in der Automatisierungsregel definiert sind. Es können Regeln beliebiger Triggertypen in eine JSON-Datei exportiert werden.
Anweisungen zum Exportieren und Importieren von Automatisierungsregeln finden Sie unter Exportieren und Importieren von Microsoft Sentinel-Automatisierungsregeln.
Nächste Schritte
In diesem Dokument haben Sie gelernt, wie Sie mithilfe von Automatisierungsregeln die Reaktionsautomatisierung für Microsoft Sentinel-Vorfälle und -Warnungen zentral verwalten.
- Erstellen und verwenden Sie Microsoft Sentinel-Automatisierungsregeln zum Verwalten von Vorfällen.
- Erstellen von Aufgabenlisten für Analysten mithilfe von Automatisierungsregeln.
- Weitere Informationen zu den erweiterten Automatisierungsoptionen finden Sie unter Automatisieren der Bedrohungsabwehr mit Playbooks in Microsoft Sentinel.
- Hilfe zum Implementieren von Playbooks finden Sie im Tutorial: Verwenden von Playbooks zum Automatisieren von Reaktionen auf Bedrohungen in Microsoft Sentinel.