Automatisieren der Bedrohungsabwehr in Microsoft Sentinel mit Automatisierungsregeln

In diesem Artikel wird erläutert, was Microsoft Sentinel-Automatisierungsregeln sind und wie Sie sie verwenden, um Ihre SOAR-Vorgänge (Security Orchestration, Automation and Response) zu implementieren, wodurch die Effektivität Ihres SOC erhöht und Zeit und Ressourcen gespart werden.

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 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 Vorfall 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, mit denen definiert wird, welche Art von Vorfällen dazu führt, dass die Regel ausgeführt wird, vorausgesetzt, dass...
  • Bedingungen, durch die die genauen Umstände bestimmt werden, unter denen die Regel aus- und durchgeführt wird...
  • Aktionen, durch die der Vorfall auf irgendeine Weise geändert oder ein Playbook aufgerufen wird.

Auslöser

Automatisierungsregeln werden ausgelöst, wenn ein Incident erstellt oder aktualisiert wird bzw. wenn eine Warnung erstellt wird. Denken Sie daran, dass Incidents Warnungen einschließen und dass sowohl Warnungen als auch Incidents durch Analyseregeln erstellt werden, von denen es mehrere Typen gibt. Erläuterungen finden Sie unter Erkennen von Bedrohungen mit integrierten Analyseregeln 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 Einheitliche Security Operations-Plattform in Microsoft Defender:
  • Im Microsoft Defender-Portal wird ein neuer Incident erstellt.

    Microsoft Sentinel ist nicht in die einheitliche Plattform integriert:
  • Ein neuer Incident wird durch eine Analyseregel erstellt.
  • Ein Incident wird von Microsoft Defender XDR erfasst.
  • Ein neuer Incident wird manuell erstellt.
  • Wenn der Vorfall aktualisiert wird
  • Der Status eines Incidents wird geändert (geschlossen/erneut geöffnet/selektiert).
  • Der Besitzer eines Incidents wird zugewiesen oder geändert.
  • Der Schweregrad eines Incidents wird herauf- oder heruntergestuft.
  • Einem Incident werden Warnungen hinzugefügt.
  • Einem Incident werden Kommentare, Tags oder Taktiken hinzugefügt.
  • Wann wird eine Warnung erstellt?
  • Eine Warnung wird von einer Microsoft Sentinel-Analyseregel vom Typ geplant oder NRT erstellt.
  • Vorfallbasierte oder warnungsbasierte Automatisierung?

    Da sowohl die Automatisierung von Vorfällen als auch die Warnungsautomatisierung zentral von Automatisierungsregeln sowie Playbooks behandelt werden, wie sollten Sie entscheiden, wann sie welche verwenden?

    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 Incidents erstellen (d. h., wenn die Erstellung von Incidents auf der Registerkarte Incidenteinstellungen des Assistenten für Analyseregelndeaktiviert wurde).

    Dieser Grund ist besonders relevant, wenn Ihr Microsoft Sentinel-Arbeitsbereich in die einheitliche Security Operations-Plattform integriert ist, da die gesamt Incidenterstellung in Microsoft Defender XDR erfolgt und daher die Regeln zur Erstellung von Integrierts in Microsoft Sentinel deaktiviert werden müssen.

    Auch ohne Onboarding im einheitlichen Portal können Sie entscheiden, eine Automatisierung mit Warnungstriggern zu verwenden, wenn Sie andere externe Logik anwenden möchten, um zu ermitteln, ob und wie Incidents aus Warnungen erstellt werden und ob und wie Warnungen in Incidents gruppiert werden. Zum Beispiel:

    • Ein Playbook kann durch eine Warnung ausgelöst werden, die keinen zugehörigen Vorfall hat, die Warnung mit Informationen aus anderen Quellen bereichern und basierend auf einer externen Logik entscheiden, ob ein Vorfall erstellt werden soll oder nicht.

    • Ein Playbook kann durch eine Warnung ausgelöst werden, und anstatt einen Vorfall zu erstellen, suchen Sie nach einem geeigneten vorhandenen Vorfall, um die Warnung hinzuzufügen. Erfahren Sie mehr über die Erweiterung von Vorfällen.

    • Ein Playbook kann durch eine Warnung ausgelöst und SOC-Mitarbeiter der Warnung benachrichtigt werden, sodass das Team entscheiden kann, ob ein Vorfall erstellt werden soll.

    • Ein Playbook kann durch eine Warnung ausgelöst und an ein externes Ticketingsystem für die Erstellung und Verwaltung von Vorfällen gesendet werden, um ein neues Ticket für jede Warnung zu erstellen.

    Hinweis

    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:

    Wert einer Vorfalleigenschaft

    • 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.

    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 mit der einheitlichen Security Operations-Plattform 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 unabhängig vom Typ der definierten Bedingung immer gleich.

    Warnungserstellungsauslöser

    Derzeit ist die einzige Bedingung, die für den Warnungserstellungstrigger konfiguriert werden kann, der Satz von Analyseregeln, für die 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 diesem Datum 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 Incidents 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, 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 auf die einheitliche Security Operations-Plattform 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), sehen Sie die Ressourcengruppen, 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:

      Regelarchitektur der mehrinstanzfähigen Automatisierung

      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 der einheitlichen Security Operations-Plattform 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 Incidents 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.

      Sie werden feststellen, dass beim Erstellen der Automatisierungsregel von hier aus im Bedienfeld Neue Automatisierungsregel erstellen die Bedingung für die Analyseregel als nicht verfügbar angezeigt wird, 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.

      Sie werden feststellen, dass im Bereich Neue Automatisierungsregel erstellen in alle Felder Werte aus dem Vorfall eingegeben wurden. 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.

    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.