Warnungskorrelation und Incidentzusammenführung im Microsoft Defender-Portal

In diesem Artikel wird erläutert, wie das Microsoft Defender-Portal die Warnungen aggregiert und korreliert, die es aus allen Quellen sammelt, die sie erzeugen und an das Portal senden. Es wird erläutert, wie Defender Incidents aus diesen Warnungen erstellt und wie es weiterhin deren Entwicklung überwacht, indem Incidents zusammengeführt werden, wenn die Situation erforderlich ist. Weitere Informationen zu Warnungen und deren Quellen und dazu, wie Incidents im Microsoft Defender-Portal mehrwerten, finden Sie unter Incidents und Warnungen im Microsoft Defender-Portal.

Incidenterstellung und Warnungskorrelation

Wenn Warnungen von den verschiedenen Erkennungsmechanismen im Microsoft Defender-Portal generiert werden, wie unter Incidents und Warnungen im Microsoft Defender-Portal beschrieben, werden sie gemäß der folgenden Logik in neue oder vorhandene Incidents eingefügt:

• Wenn die Warnung in allen Warnungsquellen innerhalb eines bestimmten Zeitraums ausreichend eindeutig ist, erstellt Defender einen neuen Incident und fügt die Warnung hinzu.
• Wenn die Warnung innerhalb eines bestimmten Zeitrahmens ausreichend mit anderen Warnungen verknüpft ist – aus derselben Quelle oder quellenübergreifend –, fügt Defender die Warnung einem vorhandenen Incident hinzu.

Die Kriterien, die vom Defender-Portal zum Korrelieren von Warnungen in einem einzelnen Incident verwendet werden, sind Teil der proprietären internen Korrelationslogik. Diese Logik ist auch dafür verantwortlich, dem neuen Incident einen geeigneten Namen zu geben.

Manuelle Korrelation von Warnungen

Obwohl Microsoft Defender bereits erweiterte Korrelationsmechanismen verwendet, möchten Sie möglicherweise anders entscheiden, ob eine bestimmte Warnung zu einem bestimmten Incident gehört oder nicht. In einem solchen Fall können Sie die Verknüpfung einer Warnung mit einem Incident aufheben und mit einem anderen verknüpfen. Jede Warnung muss zu einem Incident gehören, sodass Sie die Warnung entweder mit einem anderen vorhandenen Incident oder einem neuen Incident verknüpfen können, den Sie vor Ort erstellen.

Anweisungen finden Sie unter Verknüpfen von Warnungen mit einem anderen Incident im Microsoft Defender-Portal.

Incidentkorrelation und Zusammenführung

Die Korrelationsaktivitäten des Defender-Portals werden nicht beendet, wenn Incidents erstellt werden. Defender erkennt weiterhin Gemeinsamkeiten und Beziehungen zwischen Incidents und zwischen Warnungen über Incidents hinweg. Wenn festgestellt wird, dass zwei oder mehr Vorfälle ausreichend gleich sind, führt Defender die Vorfälle zu einem einzelnen Incident zusammen.

Kriterien für das Zusammenführen von Incidents

Die Korrelations-Engine von Defender führt Incidents zusammen, wenn allgemeine Elemente zwischen Warnungen in separaten Vorfällen erkannt werden, basierend auf ihren fundierten Kenntnissen der Daten und des Angriffsverhaltens. Einige dieser Elemente umfassen:

• Entitäten – Ressourcen wie Benutzer, Geräte, Postfächer und andere
• Artefakte – Dateien, Prozesse, E-Mail-Absender und andere
• Zeitrahmen
• Sequenzen von Ereignissen, die auf mehrstufige Angriffe verweisen, z. B. ein schädliches E-Mail-Klickereignis, das genau auf eine Phishing-E-Mail-Erkennung folgt.

Ergebnisse des Zusammenführungsprozesses

Wenn zwei oder mehr Incidents zusammengeführt werden, wird kein neuer Vorfall erstellt, um sie aufzufangen. Stattdessen werden die Inhalte eines Incidents in den anderen Incident migriert, und der Im Prozess abgebrochene Incident wird automatisch geschlossen. Der abgebrochene Incident ist im Defender-Portal nicht mehr sichtbar oder verfügbar, und alle Verweise darauf werden an den konsolidierten Incident umgeleitet. Der abgebrochene, geschlossene Vorfall bleibt in Microsoft Sentinel im Azure-Portal zugänglich. Die Inhalte der Incidents werden wie folgt behandelt:

• Warnungen, die im abgebrochenen Incident enthalten sind, werden daraus entfernt und dem konsolidierten Incident hinzugefügt.
• Alle Tags, die auf den abgebrochenen Incident angewendet werden, werden daraus entfernt und dem konsolidierten Incident hinzugefügt.
• Dem abgebrochenen Incident wird ein Redirected Tag hinzugefügt.
• Entitäten (Objekte usw.) folgen den Warnungen, mit denen sie verknüpft sind.
• Analyseregeln, die als an der Erstellung des abgebrochenen Incidents beteiligt sind, werden den regeln hinzugefügt, die im konsolidierten Incident aufgezeichnet wurden.
• Derzeit werden Kommentare und Aktivitätsprotokolleinträge im abgebrochenen Incident nicht in den konsolidierten Incident verschoben.

Um die Kommentare und den Aktivitätsverlauf des abgebrochenen Incidents anzuzeigen, öffnen Sie den Vorfall in Microsoft Sentinel im Azure-Portal. Der Aktivitätsverlauf umfasst das Schließen des Incidents sowie das Hinzufügen und Entfernen von Warnungen, Tags und anderen Elementen im Zusammenhang mit der Incidentzusammenführung. Diese Aktivitäten werden der Identitäts-Microsoft Defender XDR - Warnungskorrelation zugeordnet.

Wenn Incidents nicht zusammengeführt werden

Selbst wenn die Korrelationslogik angibt, dass zwei Incidents zusammengeführt werden sollen, führt Defender die Incidents unter den folgenden Umständen nicht zusammen:

• Einer der Vorfälle weist die status "Closed" auf. Behobene Vorfälle werden nicht erneut geöffnet.
• Die beiden zusammenführenden Vorfälle werden zwei verschiedenen Personen zugewiesen.
• Das Zusammenführen der beiden Incidents würde die Anzahl der Entitäten im zusammengeführten Incident über die zulässige Maximalanzahl von 50 Entitäten pro Incident erhöhen.
• Die beiden Incidents enthalten Geräte in unterschiedlichen Gerätegruppen, wie vom organization definiert.
  (Diese Bedingung ist nicht standardmäßig in Kraft; sie muss aktiviert sein.)

Nächste Schritte

Weitere Informationen zur Priorisierung und Verwaltung von Incidents finden Sie in den folgenden Artikeln:

• Verwalten von Incidents in Microsoft Defender

Siehe auch

• Die Leistungsfähigkeit von Vorfällen in Microsoft Defender XDR
• Inside Microsoft Defender XDR: Korrelieren und Konsolidieren von Angriffen in Incidents