Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Microsoft Sentinel ist im Microsoft Defender-Portal mit Microsoft Defender XDR oder eigenständig verfügbar. Es bietet eine einheitliche Erfahrung in SIEM und XDR für eine schnellere, genauere Bedrohungserkennung und -reaktion, einfachere Workflows und eine bessere betriebliche Effizienz.
In diesem Artikel wird erläutert, wie Sie Ihre Microsoft Sentinel Erfahrung vom Azure-Portal in das Defender-Portal umstellen. Wenn Sie Microsoft Sentinel im Azure-Portal verwenden, wechseln Sie zu Microsoft Defender für einheitliche Sicherheitsvorgänge und die neuesten Features. Bevor Sie beginnen, prüfen Sie die Voraussetzungen für den Übergang zum Defender-Portal-Abschnitt für den erforderlichen Zugang und die Vorbereitungsschritte. Weitere Informationen finden Sie unter Microsoft Sentinel im Microsoft Defender-Portal oder sehen Sie sich unsere Microsoft Sentinel-in-the Defender-Portal-Video-Playlist an.
Hinweis
Der Übergang zum Defender-Portal, auch für Nicht-E5-Kunden, hat keine zusätzlichen Kosten für den Kunden. Dem Kunden wird weiterhin wie gewohnt nur sein Verbrauch über Sentinel in Rechnung gestellt.
Voraussetzungen
Bevor Sie beginnen, beachten Sie Folgendes:
Dieser Artikel richtet sich an Kunden mit einem vorhandenen Arbeitsbereich, der für Microsoft Sentinel aktiviert ist, die ihre Microsoft Sentinel Erfahrung auf das Defender-Portal umstellen möchten. Wenn Sie ein neuer Kunde sind, der mit den Berechtigungen eines Abonnementinhabers (Azure-integrierte Rolle) oder eines Benutzerzugriffsadministrators (Azure-integrierte Rolle) eingegangen ist, werden Ihre Arbeitsbereiche automatisch ins Defender-Portal eingebunden. Weitere Informationen finden Sie unter Quickstart: An Bord zum Defender-Portal.
Einige Microsoft Sentinel Features verfügen über neue Speicherorte im Defender-Portal. Weitere Informationen finden Sie unter Schnellreferenz für Microsoft Sentinel-Featurepositionen im Defender-Portal.
Falls relevant, finden Sie ausführliche Voraussetzungen in den verknüpften Artikeln für jeden Schritt.
Planen und Einrichten Ihrer Übergangsumgebung
Zielgruppe: Sicherheitsarchitekten
Videos:
- Einbinden eines Microsoft Sentinel-Arbeitsbereichs in Microsoft Defender
- Verwalten von einheitlicher RBAC in Microsoft Defender
Überprüfen Sie die Planungsanleitung, erfüllen Sie die Voraussetzungen, und führen Sie das Onboarding durch.
Lesen Sie alle Planungsleitfäden, und schließen Sie alle Voraussetzungen ab, bevor Sie das Onboarding Ihres Arbeitsbereichs in das Defender-Portal durchführen. Weitere Informationen finden Sie in den folgenden Artikeln:
Planen Sie einheitliche Sicherheitsvorgänge im Defender-Portal. Nach dem Onboarding im Defender-Portal wird die Rolle Microsoft Sentinel Contributor den Apps Microsoft Threat Protection und WindowsDefenderATP in Ihrem Abonnement zugewiesen.
Verwalten sie Microsoft Sentinel- und Defender XDR-Berechtigungen im Defender-Portal. Im Blogbeitrag „Verwalten der Berechtigungen für Microsoft Sentinel und Defender XDR im Defender-Portal“ wird erläutert, wie die Berechtigungen für Microsoft Sentinel und Defender XDR im einheitlichen Defender-Portal funktionieren, was Sie während des Übergangs erwartet und es wird eine Einführung in die neue einheitliche rollenbasierte Zugriffssteuerung (URBAC) gegeben. Weitere Informationen zu URBAC finden Sie unter Zuordnen von einheitlichen RBAC-Berechtigungen in Microsoft Defender XDR zu vorhandenen RBAC-Berechtigungen.
Bereitstellen von vereinheitlichten Sicherheitsabläufen im Defender-Portal. Dieser Artikel richtet sich zwar an neue Kunden, die noch keinen Arbeitsbereich für Microsoft Sentinel oder andere Dienste haben, die in das Defender-Portal integriert wurden. Verwenden Sie ihn als Referenz, wenn Sie zum Defender-Portal wechseln.
Verbinden Sie Microsoft Sentinel mit dem Defender-Portal. Im Artikel "Connect Microsoft Sentinel to the Defender portal" sind die Voraussetzungen für das Onboarding Ihres Arbeitsbereichs im Defender-Portal aufgeführt. Wenn Sie Microsoft Sentinel ohne Defender XDR verwenden möchten, müssen Sie einen zusätzlichen Schritt ausführen, um die Verbindung zwischen Microsoft Sentinel und dem Defender-Portal auszulösen.
Überprüfen der Unterschiede in Bezug auf Datenspeicherung und Datenschutz
Wenn Sie die Azure-Portal verwenden, gelten die Microsoft Sentinel Richtlinien für Datenspeicherung, -verarbeitung, -aufbewahrung und -freigabe. Wenn Sie das Defender-Portal verwenden, gelten stattdessen die Microsoft Defender XDR Richtlinien, auch wenn Sie mit Microsoft Sentinel Daten arbeiten.
Die folgende Tabelle enthält zusätzliche Details und Links, damit Sie die Erfahrungen in den Azure- und Defender-Portalen vergleichen können.
| Supportbereich | Azure-Portal | Defender-Portal |
|---|---|---|
| Geschäftskontinuität und Notfallwiederherstellung (BCDR) | Kunden sind für die Replikation ihrer Daten verantwortlich | Microsoft Defender verwendet Automatisierung für das BCDR in den Steuerungsebenen. |
| Datenspeicherung und -verarbeitung |
-
Datenspeicherort - Unterstützte Regionen |
Datenspeicherort |
| Datenaufbewahrung | Datenaufbewahrung | Datenaufbewahrung |
| Datenfreigabe | Datenfreigabe | Datenfreigabe |
Weitere Informationen zu Datenspeicherungs- und Datenschutzrichtlinien finden Sie unter Geografische Verfügbarkeit und Datenaufbewahrung in Microsoft Sentinel und Datensicherheit und Aufbewahrung in Microsoft Defender XDR.
Einführung in das Defender-Portal mit kundenseitig verwalteten Schlüsseln (CMK)
Wichtig
Die CMK-Verschlüsselung wird für Daten, die im Microsoft Sentinel Data Lake gespeichert sind, nicht vollständig unterstützt. Alle im Data Lake erfassten Daten , z. B. benutzerdefinierte Tabellen oder transformierte Daten, werden mit von Microsoft verwalteten Schlüsseln verschlüsselt.
Wenn Sie cmk vor dem Onboarding aktiviert haben, werden beim Onboarding Ihres Microsoft Sentinel-fähigen Arbeitsbereichs im Defender-Portal weiterhin alle Protokolldaten in Ihrem Arbeitsbereich mit CMK verschlüsselt , einschließlich der zuvor erfassten und neu erfassten Daten.
Analyseregeln und andere Sentinel Inhalte, z. B. Automatisierungsregeln, werden ebenfalls weiterhin CMK-verschlüsselt. Warnungen und Incidents werden jedoch nach dem Onboarding nicht mehr CMK-verschlüsselt.
Weitere Informationen zu CMK finden Sie unter Einrichten eines kundenseitig verwalteten Schlüssels des Microsoft Sentinel.
Multi-Workspace‑ und Mandantenverwaltung konfigurieren
Defender unterstützt einen oder mehrere Arbeitsbereiche über mehrere Tenants hinweg über das Microsoft Defender Multitenant-Portal, das als zentraler Ort dient, um Vorfälle und Warnungen zu verwalten, Bedrohungen zwischen Tenants zu suchen und Managed Security Service Partners (MSSPs) Kunden zu ermöglichen.
In Szenarien mit mehreren Arbeitsbereichen können Sie über das mehrinstanzenfähige Portal einen primären und mehrere sekundäre Arbeitsbereiche pro Mandant verbinden. Integrieren Sie jeden Arbeitsbereich separat für jeden Mandanten in das Defender-Portal, genau wie beim Onboarding für einen einzelnen Mandanten.
Weitere Informationen zur Konfiguration für mehrere Mandanten und mehrere Arbeitsbereiche finden Sie unter:
Azure Lighthouse-Dokumentation. Mit Azure Lighthouse können Sie Microsoft Sentinel-Daten aus anderen Mandanten in den eingebundenen Arbeitsbereichen verwenden. Beispielsweise können Sie arbeitsbereichsübergreifende Abfragen mit dem
workspace()Operator unter Erweiterte Such- und Analyseregeln ausführen.Microsoft Entra B2B. Mit Microsoft Entra B2B können Sie mandantenübergreifend auf Daten zugreifen. Granulare delegierte Administratorrechte (GDAP) für Microsoft Sentinel sind als Vorschau verfügbar.
Konfigurieren und Überprüfen Ihrer Einstellungen und Inhalte
Zielgruppe: Sicherheitstechniker
Video: Verwalten von Connectors in Microsoft Defender
Bestätigen und Konfigurieren der Datensammlung
Wenn Microsoft Sentinel in Microsoft Defender integriert ist, bleibt die grundlegende Architektur der Datensammlung und des Telemetrieflusses erhalten. Vorhandene Nicht-Microsoft-Datenkonnektoren arbeiten weiterhin ohne Unterbrechung. Die Warnungserfassung für Microsoft-Sicherheitsprodukte ändert sich jedoch nach dem Onboarding in das Defender-Portal mit Microsoft Defender XDR. Warnungen von Microsoft-Sicherheitsprodukten werden über den Microsoft Defender XDR-Konnektor statt über separate Warnungskonnektoren für Microsoft-Sicherheitsprodukte weitergeleitet.
In Umgebungen mit mehreren Arbeitsbereichen ist der Microsoft Defender XDR Connector nur mit dem primären Arbeitsbereich verbunden. Um doppelte mandantenbasierte Warnungen arbeitsbereichsübergreifend zu verhindern, werden eigenständige Datenkonnektoren für Microsoft Defender for Office 365, Microsoft Entra ID Protection, Microsoft Defender for Cloud Apps, Microsoft Defender for Endpoint und Microsoft Defender for Identity während des Onboardings in sekundären Arbeitsbereichen automatisch getrennt. Daher stehen mandantenbasierte Warnungen aus diesen Microsoft Sicherheitsprodukten nur im primären Arbeitsbereich zur Verfügung.
Aus der Perspektive von Log Analytics ändert die Integration von Microsoft Sentinel in Microsoft Defender nicht, wie Microsoft Sentinel Protokolldaten in Log Analytics speichert. Trotz der Front-End-Vereinheitlichung bleibt das Microsoft Sentinel-Back-End für die Datenspeicherung, Suche und Korrelation vollständig in Log Analytics integriert.
Warnungen im Zusammenhang mit Defender Produkten werden direkt vom Microsoft Defender Connector gestreamt, um die Konsistenz sicherzustellen. Stellen Sie sicher, dass Vorfälle und Warnungen von diesem Konnektor in Ihrem Arbeitsbereich aktiviert sind. Nachdem Sie diesen Datenkonnektor in Ihrem Arbeitsbereich konfiguriert haben, trennt das Offboarding des Arbeitsbereichs von Microsoft Defender auch den Microsoft Defender XDR-Konnektor.
Hinweis
Diese Änderung des Connector-Routings führt bei einigen Warnungen zu Schema-Unterschieden. Einen detaillierten Vergleich finden Sie unter Warnungsschemaunterschiede: Eigenständiger und Microsoft Defender XDR Connector.
Informationen zum Migrieren von Einstellungen für die Erstellung von Analyseregeln und Warnungsgruppierung finden Sie unter Microsoft Sentinel-Regeln zur Erstellung von Vorfällen und Warnungsgruppierungseinstellungen zu Defender XDR migrieren.
Weitere Informationen finden Sie unter Verbinden von Daten von Microsoft Defender zu Microsoft Sentinel.
Mit Microsoft Defender for Cloud integrieren
Überprüfen Sie die folgenden connectorspezifischen Aktionen, um doppelte Ereignisse bei der Integration von Microsoft Defender for Cloud in das Defender-Portal zu vermeiden:
- Wenn Sie den mandantenbasierten Datenconnector für Defender für Cloud verwenden, stellen Sie sicher, dass Sie Maßnahmen ergreifen, um doppelte Ereignisse und Warnungen zu verhindern.
- Wenn Sie stattdessen den abonnementbasierten Legacyconnector verwenden, stellen Sie sicher, dass Sie die Synchronisierung von Incidents und Warnungen an Microsoft Defender deaktivieren.
Weitere Informationen finden Sie unter Warnungen und Vorfälle in Microsoft Defender.
Sichtbarkeit des Datenkonnektors im Defender-Portal
Nach der Einbindung Ihres Arbeitsbereichs in Defender werden die folgenden Datenkonnektoren für vereinheitlichte Sicherheitsvorgänge verwendet und auf der Seite Datenkonnektoren im Defender-Portal nicht angezeigt:
- Microsoft Defender für Cloud-Apps
- Microsoft Defender für Endpunkt
- Microsoft Defender for Identity
- Microsoft Defender für Office 365 (Vorschau)
- Microsoft Defender XDR
- Abonnementbasiertes Microsoft Defender for Cloud (Legacy)
- Mandantenbasierter Microsoft Defender for Cloud (Vorschau)
Diese Datenkonnektoren werden weiterhin in Microsoft Sentinel im Azure-Portal aufgeführt.
Konfigurieren Ihres Ökosystems
Obwohl der Arbeitsbereichs-Manager von Microsoft Sentinel im Defender-Portal nicht verfügbar ist, verwenden Sie eine der folgenden alternativen Funktionen zum Verteilen von Inhalten als Code über Arbeitsbereiche hinweg:
Stellen Sie Inhalte als Code aus Ihrem Repository (öffentliche Vorschau) bereit. Verwenden Sie YAML- oder JSON-Dateien in GitHub oder Azure DevOps, um Konfigurationen in Microsoft Sentinel und Defender mithilfe einheitlicher CI/CD-Workflows zu verwalten und bereitzustellen.
Mehrinstanzenfähiges Portal. Das Microsoft Defender-Portal für mehrere Mandanten unterstützt die mandantenübergreifende Verwaltung und Verteilung von Inhalten.
Andernfalls können Sie weiterhin Lösungspakete bereitstellen, die verschiedene Arten von Sicherheitsinhalten aus dem Inhaltshub im Defender-Portal enthalten. Weitere Informationen finden Sie unter Entdecken und Verwalten sofort einsatzbereiter Inhalte in Microsoft Sentinel.
Konfigurieren von Analyseregeln
Microsoft Sentinel-Analyseregeln sind im Defender-Portal für Erkennung, Konfiguration und Verwaltung verfügbar. Weitere Informationen finden Sie unter Microsoft Sentinel-Konfiguration im Defender-Portal. Die Funktionen von Analyseregeln bleiben unverändert, einschließlich Erstellung, Aktualisierung und Verwaltung über den Assistenten, Repositorys und die Microsoft Sentinel-API. Die Incidentkorrelation und die mehrstufige Angriffserkennung funktionieren auch weiterhin im Defender-Portal. Die Warnungskorrelationsfunktion, die von der Fusion-Analyseregel im Azure-Portal verwaltet wird, wird von der Defender XDR-Engine im Defender-Portal verarbeitet, die alle Signale an einem Ort konsolidiert.
Wenn Sie zum Defender-Portal wechseln, sind die folgenden Änderungen wichtig:
| Funktion | Beschreibung |
|---|---|
| Regeln für die benutzerdefinierte Erkennung | Wenn Sie Erkennungsszenarien haben, die sowohl Defender XDR- als auch Microsoft Sentinel-Daten umfassen und bei denen Sie Defender XDR-Daten nicht länger als 30 Tage aufbewahren müssen, empfehlen wir, benutzerdefinierte Erkennungsregeln zu erstellen, die Daten aus den Tabellen von Microsoft Sentinel und Defender XDR abfragen. Das Erstellen benutzerdefinierter Erkennungsregeln, die beide Quellen abfragen, wird unterstützt, ohne dass Defender XDR-Daten in Microsoft Sentinel eingespäst werden müssen. Weitere Informationen finden Sie unter Verwenden Microsoft Sentinel benutzerdefinierter Funktionen bei der erweiterten Suche in Microsoft Defender. |
| Warnungskorrelation | Im Defender-Portal werden Korrelationen unabhängig vom Warnungsszenario automatisch auf Warnungen angewendet – und zwar sowohl anhand von Microsoft Defender-Daten als auch von in Microsoft Sentinel aufgenommenen Daten von Drittanbietern. Die Kriterien, die zum Korrelieren von Warnungen in einem einzelnen Incident verwendet werden, sind Teil der proprietären internen Korrelationslogik des Defender-Portals. Weitere Informationen finden Sie unter Warnungskorrelation und Incidentzusammenführung im Defender-Portal. |
| Warnungsgruppierung und Zusammenführung von Vorfällen | Während die Konfiguration der Warnungsgruppierung weiterhin in Analyseregeln angezeigt wird, steuert das Defender XDR Korrelationsmodul die Warnungsgruppierung und das Zusammenführen von Vorfällen bei Bedarf im Defender-Portal vollständig. Dadurch wird eine umfassende Übersicht über die gesamte Angriffsgeschichte sichergestellt, indem relevante Warnungen für mehrstufige Angriffe zusammengefügt werden. Zum Beispiel können mehrere einzelne Analyseregeln, die so konfiguriert sind, dass je Warnung ein Vorfall erstellt wird, zu zusammengeführten Vorfällen führen, wenn sie mit der Korrelationslogik von Defender XDR übereinstimmen. |
| Sichtbarkeit von Warnungen | Wenn Sie Microsoft Sentinel-Analyseregeln so konfiguriert haben, dass sie nur Warnungen auslösen (siehe Einstellungen für die Vorfallerstellung konfigurieren), und die Vorfallerstellung deaktiviert ist, sind diese Warnungen im Defender-Portal nicht sichtbar. |
| Optimierung von Warnmeldungen | Sobald Ihr Microsoft Sentinel-Arbeitsbereich in Defender integriert wurde, werden alle Vorfälle, einschließlich derjenigen aus Ihren Microsoft Sentinel-Analyseregeln, von der Defender XDR-Engine generiert. Daher können die Warnungsoptimierungsfunktionen im Defender-Portal, die bisher nur für Defender XDR Warnungen verfügbar waren, jetzt auf Warnungen von Microsoft Sentinel angewendet werden. Alert Tuning ermöglicht es Ihnen, die Reaktion auf Vorfälle zu optimieren, indem Sie die Auflösung häufiger Alarme automatisieren, Fehlalarme reduzieren und Rauschen minimieren, sodass Analysten bedeutende Sicherheitsvorfälle priorisieren können. |
| Fusion: Erweiterte Erkennung von Angriffen in mehreren Zuständen | Die Fusion-Analyseregel, die im Azure-Portal Incidents basierend auf Warnungskorrelationen erstellt, die von der Fusion-Korrelations-Engine erstellt werden, ist deaktiviert, wenn Sie Microsoft Sentinel in das Defender-Portal integrieren. Sie verlieren die Funktion zur Warnungskorrelation nicht, da das Defender-Portal die Funktionen von Microsoft Defender XDR zur Erstellung und Korrelation von Sicherheitsvorfällen als Ersatz für die der Fusion-Engine verwendet. Weitere Informationen finden Sie unter Erweiterte Erkennung von mehrstufigen Angriffen in Microsoft Sentinel |
Automatisierungsregeln und Playbooks konfigurieren
In Microsoft Sentinel basieren Playbooks auf Workflows, die in Azure Logic Apps erstellt werden, einem Clouddienst, mit dem Sie Aufgaben und Workflows systemübergreifend im gesamten Unternehmen planen, automatisieren und orchestrieren können.
Die folgenden Einschränkungen gelten für Microsoft Sentinel-Automatisierungsregeln und Playbooks beim Arbeiten im Defender-Portal. Möglicherweise müssen Sie einige Änderungen an Ihrer Umgebung vornehmen, wenn Sie den Übergang vornehmen.
| Funktionalität | Beschreibung |
|---|---|
| Automatisierungsregeln mit Warnungstriggern | Im Microsoft Defender-Portal gelten Automatisierungsregeln, die durch Warnungen ausgelöst werden, nur für Microsoft Sentinel-Warnungen. Verwenden Sie zum Automatisieren von Antworten auf Defender XDR Warnungen auch den erweiterten Warnungsauslöser. Weitere Informationen finden Sie unter Trigger zum Erstellen von Warnungen. |
| Automatisierungsregeln mit Incident-Auslösern | Sowohl im Azure-Portal als auch im Defender-Portal wird die Bedingungseigenschaft Incidentanbieter entfernt, da für alle Incidents Microsoft XDR als Incidentanbieter verwendet wird (der Wert im Feld ProviderName). An diesem Punkt werden alle vorhandenen Automatisierungsregeln sowohl für Microsoft Sentinel- als auch für Microsoft Defender XDR-Vorfälle ausgeführt, einschließlich solcher, bei denen die Incidentanbieterbedingung nur auf Microsoft Sentinel oder Microsoft 365 Defender festgelegt ist. Automatisierungsregeln, die einen bestimmten Analyseregelnamen angeben, werden jedoch nur für Incidents ausgeführt, die Warnungen enthalten, die von der angegebenen Analyseregel erstellt wurden. Dies bedeutet, dass Sie die Eigenschaft "Name der Analyseregel" für eine Analyseregel definieren können, die nur in Microsoft Sentinel vorhanden ist, um die Ausführung Ihrer Regel auf Incidents nur in Microsoft Sentinel zu beschränken. Außerdem enthält die Tabelle SecurityIncident nach dem Onboarding im Defender-Portal kein Beschreibungsfeld mehr. Daher: – Wenn Sie dieses Beschreibungsfeld als Bedingung für eine Automatisierungsregel mit einem Trigger für die Incidenterstellung verwenden, funktioniert diese Automatisierungsregel nach dem Onboarding im Defender-Portal nicht mehr. Stellen Sie in solchen Fällen sicher, dass Sie die Konfiguration entsprechend aktualisieren. Weitere Informationen finden Sie unter Bedingungen zum Auslösen von Incidents. – Wenn Sie eine Integration mit einem externen Ticketsystem wie ServiceNow konfiguriert haben, fehlt die Incidentbeschreibung. |
| Latenz bei Playbook-Triggern | Es kann bis zu 5 Minuten dauern, bis Microsoft Defender Vorfälle in Microsoft Sentinel angezeigt werden. Wenn diese Verzögerung vorliegt, wird auch das Auslösen des Playbooks verzögert. |
| Automatisierungsbatchfenster | Wenn in einem Zeitraum von 5 bis 10 Minuten mehrere Änderungen an demselben Vorfall vorgenommen werden, wird ein einzelnes Update an Microsoft Sentinel gesendet, wobei nur die letzte Änderung vorhanden ist. Zwischenaktualisierungen gehen verloren, was sich auf Workflows auswirken kann, die von der Verarbeitung sequenzieller Vorfallstatusänderungen abhängen. Weitere Informationen finden Sie unter Auslöser für Incidentaktualisierungen. |
| Änderungen an vorhandenen Incidentnamen | Das Defender-Portal verwendet eine eindeutige Engine, um Incidents und Warnungen zu korrelieren. Bei der Integration Ihres Arbeitsbereichs in das Defender-Portal können die Namen vorhandener Incidents geändert werden, wenn die Korrelation angewendet wird. Um sicherzustellen, dass Ihre Automatisierungsregeln immer ordnungsgemäß ausgeführt werden, sollten Sie daher die Verwendung von Incidenttiteln als Bedingungskriterien in Ihren Automatisierungsregeln vermeiden und stattdessen vorschlagen, den Namen aller Analyseregeln zu verwenden, die im Incident enthaltene Warnungen erstellt haben, und Tags, wenn mehr Spezifität erforderlich ist. |
| Aktualisiert von-Feld | Nach dem Onboarding Ihres Arbeitsbereichs enthält das Feld Aktualisiert von eine neue Gruppe unterstützter Werte, zu denen Microsoft 365 Defender nicht mehr gehört. In vorhandenen Automatisierungsregeln wird Microsoft 365 Defender nach dem Onboarding Ihres Arbeitsbereichs durch den Wert Andere ersetzt. |
| Erstellen von Automatisierungsregeln direkt aus einem Incident | Das Erstellen von Automatisierungsregeln direkt aus einem Incident wird nur im Azure-Portal unterstützt. Wenn Sie im Defender-Portal arbeiten, erstellen Sie Ihre Automatisierungsregeln von Grund auf auf der Seite Automatisierung . |
| Regeln für die Erstellung von Microsoft-Incidents | Microsoft-Regeln zur Vorfallerstellung werden im Defender-Portal nicht unterstützt. Weitere Informationen finden Sie unter Microsoft Defender XDR-Vorfälle und Regeln zum Erstellen von Microsoft-Vorfällen. |
| Ausführen von Automatisierungsregeln über das Defender-Portal | Es kann bis zu 10 Minuten dauern, ab dem Zeitpunkt, zu dem eine Warnung ausgelöst und ein Incident im Defender-Portal erstellt oder aktualisiert wird, bis zu dem Zeitpunkt, zu dem eine Automatisierungsregel ausgeführt wird. Diese Verzögerung liegt daran, dass der Incident im Defender-Portal erstellt und dann an Microsoft Sentinel für die Automatisierungsregel weitergeleitet wird. |
| Registerkarte „Aktive Playbooks“ | Nach dem Onboarding in das Defender-Portal wird auf der Registerkarte Aktive Playbooks standardmäßig ein vordefinierter Filter mit dem Abonnement des integrierten Arbeitsbereichs angezeigt. Fügen Sie im Azure-Portal Mithilfe des Abonnementfilters Daten für andere Abonnements hinzu. Weitere Informationen finden Sie unter Erstellen und Anpassen Microsoft Sentinel Playbooks aus Vorlagen. |
| Manuelles Ausführen von Playbooks bei Bedarf | Die folgenden Verfahren werden derzeit im Defender-Portal nicht unterstützt: |
| Das Ausführen von Playbooks nach Incidents erfordert die Microsoft Sentinel-Synchronisierung | Wenn Sie versuchen, ein Playbook für einen Incident über das Defender-Portal auszuführen und die Meldung "Kann nicht auf Daten im Zusammenhang mit dieser Aktion zugreifen. Aktualisieren Sie den Bildschirm in einigen Minuten." angezeigt wird, bedeutet dies, dass der Incident noch nicht mit Microsoft Sentinel synchronisiert wurde. Aktualisieren Sie die Incidentseite, nachdem der Vorfall synchronisiert wurde, um das Playbook erfolgreich auszuführen. |
|
Vorfälle: Hinzufügen von Warnmeldungen zu Vorfällen / Entfernen von Warnungen aus Vorfällen |
Da das Hinzufügen von Warnungen zu Vorfällen oder das Entfernen von Warnungen aus Vorfällen nicht unterstützt wird, nachdem Ihr Arbeitsbereich in das Defender-Portal integriert wurde, werden diese Aktionen auch aus Playbooks heraus nicht unterstützt. Weitere Informationen finden Sie unter Verstehen, wie Warnungen korreliert und Incidents im Defender-Portal zusammengeführt werden. |
| Microsoft Defender XDR-Integration in mehreren Arbeitsbereichen | Wenn Sie XDR-Daten mit mehr als einem Arbeitsbereich in einem einzelnen Mandanten integriert haben, werden die Daten jetzt nur noch im primären Arbeitsbereich im Defender-Portal erfasst. Übertragen Sie Automatisierungsregeln in den relevanten Arbeitsbereich, damit sie weiterhin ausgeführt werden. |
| Automatisierung und die Korrelations-Engine | Die Korrelations-Engine kann Warnungen von mehreren Signalen in einem einzelnen Incident kombinieren, was dazu führen kann, dass die Automatisierung Daten empfängt, die Sie nicht erwartet haben. Es wird empfohlen, Ihre Automatisierungsregeln zu überprüfen, um sicherzustellen, dass die erwarteten Ergebnisse angezeigt werden. |
Konfigurieren von APIs
Die einheitliche Benutzererfahrung im Defender-Portal bringt deutliche Änderungen bei Vorfällen und Warnungen aus APIs mit sich. Es unterstützt API-Aufrufe, die auf der Microsoft Graph-REST-API v1.0 basieren, die für die Automatisierung im Zusammenhang mit Warnungen, Incidents, der erweiterten Suche und mehr verwendet werden kann.
Die Microsoft Sentinel-API unterstützt weiterhin Aktionen für Microsoft-Sentinel-Ressourcen, wie zum Beispiel Analyseregeln, Automatisierungsregeln und vieles mehr. Für die Interaktion mit einheitlichen Incidents und Warnungen wird empfohlen, die Microsoft Graph-REST-API zu verwenden.
Wenn Sie die Microsoft Sentinel-API SecurityInsights zur Interaktion mit Microsoft Sentinel-Vorfällen verwenden, müssen Sie aufgrund von Änderungen im Antwortkörper möglicherweise Ihre Automatisierungsbedingungen und Auslösekriterien aktualisieren.
In der folgenden Tabelle sind Felder aufgeführt, die in den Antwortausschnitten wichtig sind, und sie werden in den Azure- und Defender-Portalen verglichen:
| Funktionalität | Azure-Portal | Defender-Portal |
|---|---|---|
| Link zum Incident |
incidentUrl: Die direkte URL zum Incident im Microsoft Sentinel-Portal |
providerIncidentUrl: Dieses zusätzliche Feld stellt einen direkten Link zum Incident bereit, der verwendet werden kann, um diese Informationen mit einem Ticketsystem eines Drittanbieters wie ServiceNow zu synchronisieren. incidentUrlist weiterhin verfügbar, verweist aber auf das Microsoft Sentinel-Portal. |
| Die Quellen, die die Erkennung ausgelöst und die Warnung veröffentlicht haben | alertProductNames |
alertProductNames: Erfordert das Hinzufügen ?$expand=alerts zu GET. Beispiel: https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts |
| Der Name des Warnungsanbieters |
providerName= "Azure Sentinel" |
providerName= "Microsoft XDR" |
| Der Dienst oder das Produkt, das die Warnung erstellt hat | Ist im Azure-Portal nicht vorhanden | serviceSource Beispiel: "microsoftDefenderForCloudApps" |
| Die Erkennungstechnologie oder der Sensor, die die relevante Komponente oder Aktivität identifiziert hat | Ist im Azure-Portal nicht vorhanden |
detectionSource Beispiel: "cloudAppSecurity" |
| Der Name des Produkts, das diese Warnung veröffentlicht hat. | Ist im Azure-Portal nicht vorhanden |
productNameBeispiel: "Microsoft Defender for Cloud Apps" |
Ausführen von Vorgängen im Defender-Portal
Zielgruppe: Sicherheitsanalysten
Videos:
- Ermitteln und Verwalten von Microsoft Sentinel Inhalten und Threat Intelligence in Microsoft Defender
- Erstellen von Automatisierung und Arbeitsmappen in Microsoft Defender
- Warnungskorrelation in Microsoft Defender
- Untersuchung von Vorfällen in Microsoft Defender
- Fallverwaltung in Microsoft Defender
- Erweiterte Suche in Microsoft Defender
- SOC-Optimierungen in Microsoft Defender
Aktualisieren Sie die Triageprozesse für Vorfälle im Defender-Portal
Wenn Sie Microsoft Sentinel im Azure-Portal verwendet haben, werden Sie im Defender-Portal erhebliche Verbesserungen an der Benutzerfreundlichkeit feststellen. Während Sie SOC-Prozesse aktualisieren und Ihre Analysten neu trainieren müssen, konsolidiert das Design alle relevanten Informationen an einem zentralen Ort, um optimierte und effizientere Workflows bereitzustellen.
Die einheitliche Incidentwarteschlange im Defender-Portal konsolidiert alle Incidents produktübergreifend in einer einzigen Ansicht und wirkt sich darauf aus, wie Analysten Vorfälle selektieren, die jetzt mehrere sicherheitsübergreifende Domänenwarnungen enthalten. Zum Beispiel:
- In der Regel selektieren Analysten Incidents basierend auf bestimmten Sicherheitsdomänen oder Fachkenntnissen und behandeln häufig Tickets pro Entität, z. B. einen Benutzer oder Host. Dieser Ansatz kann blinde Flecken erzeugen, die mit der einheitlichen Erfahrung angegangen werden sollen.
- Wenn sich ein Angreifer seitlich bewegt, können verwandte Warnungen aufgrund verschiedener Sicherheitsdomänen in separaten Vorfällen enden. Die einheitliche Benutzeroberfläche beseitigt dieses Problem, indem eine umfassende Ansicht bereitgestellt wird, die sicherstellt, dass alle zugehörigen Warnungen korreliert und kohäsiv verwaltet werden.
Analysten können auch Erkennungsquellen und Produktnamen im Defender-Portal anzeigen und Filter anwenden und freigeben, um eine effizientere Selektierung von Vorfällen und Warnungen zu ermöglichen.
Der einheitliche Selektierungsprozess kann dazu beitragen, die Workloads von Analysten zu reduzieren und sogar die Rollen von Analysten der Ebene 1 und Der Ebene 2 zu kombinieren. Der einheitliche Selektierungsprozess kann jedoch auch umfassendere und tiefergehende Analystenkenntnisse erfordern. Es wird empfohlen, auf der neuen Portaloberfläche zu trainieren, um einen reibungslosen Übergang zu gewährleisten.
Das Defender-Portal bietet auch Untersuchungsfunktionen, die im Azure-Portal nicht verfügbar sind, einschließlich der Angriffsstory und des Vorfalldiagramms zur Visualisierung des gesamten Umfangs eines Angriffs und einer Explosionsradiusanalyse, um Analysten dabei zu helfen, mögliche Verteilungspfade zu visualisieren, geschäftliche Auswirkungen zu bewerten und Eindämmungsaktionen zu priorisieren.
Weitere Informationen finden Sie unter Incidents und Warnungen im Microsoft Defender-Portal.
Verstehen, wie Warnungen korreliert und Incidents im Defender-Portal zusammengeführt werden
Die Korrelations-Engine von Defender führt Incidents zusammen, wenn allgemeine Elemente zwischen Warnungen in separaten Vorfällen erkannt werden. Wenn eine neue Warnung Korrelationskriterien erfüllt, aggregiert Microsoft Defender und korreliert sie mit anderen zugehörigen Warnungen aus allen Erkennungsquellen zu einem neuen Incident. Nach der Einbindung von Microsoft Sentinel in das Defender-Portal macht die einheitliche Warteschlange für Incidents einen umfassenderen Angriff sichtbar, wodurch Analysten effizienter arbeiten können und eine vollständige Darstellung des Angriffs erhalten.
In Szenarien mit mehreren Arbeitsbereichen werden nur Warnungen aus einem primären Arbeitsbereich mit Microsoft Defender XDR Daten korreliert. Es gibt auch bestimmte Szenarien, in denen Incidents nicht zusammengeführt werden.
Nach dem Onboarding Microsoft Sentinel in das Defender-Portal gelten die folgenden Änderungen für Incidents und Warnungen:
| Funktion | Beschreibung |
|---|---|
| Verzögerung direkt nach dem Onboarding Ihres Arbeitsbereichs | Es kann bis zu 5 Minuten dauern, bis Microsoft Defender Incidents vollständig in Microsoft Sentinel integriert sind. Dies wirkt sich nicht auf Features aus, die direkt von Microsoft Defender bereitgestellt werden, z. B. automatische Angriffsunterbrechungen. |
| Regeln zur Erstellung von Sicherheitsvorfällen | Alle aktiven Regeln für die Erstellung von Microsoft-Sicherheitsvorfällen werden deaktiviert, um doppelte Vorfälle zu vermeiden. Die Einstellungen für die Incidenterstellung in anderen Arten von Analyseregeln bleiben unverändert und können im Defender-Portal konfiguriert werden. |
| Name des Incidentanbieters | Im Defender-Portal lautet der Name des Incidentanbieters immer Microsoft XDR. |
| Hinzufügen/Entfernen von Warnungen zu Incidents | Das Hinzufügen oder Entfernen von Microsoft Sentinel-Warnungen zu Vorfällen oder aus Vorfällen wird nur im Defender-Portal unterstützt. Um eine Warnung aus einem Incident im Defender-Portal zu entfernen, müssen Sie die Warnung einem anderen Incident hinzufügen. |
| Bearbeiten von Kommentaren | Hinzufügen von Kommentaren zu Incidents in Defender oder Azure-Portal, aber das Bearbeiten vorhandener Kommentare wird im Defender-Portal nicht unterstützt. Änderungen an Kommentaren im Azure-Portal werden nicht mit dem Defender-Portal synchronisiert. |
| Programmgesteuerte und manuelle Erstellung von Incidents | Incidents, die in Microsoft Sentinel über die API, durch ein Logik-App-Playbook oder manuell aus dem Azure-Portal erstellt wurden, werden nicht mit dem Defender-Portal synchronisiert. Diese Vorfälle werden weiterhin im Azure-Portal und in der API unterstützt. Weitere Informationen finden Sie unter Manuelles Erstellen eigener Incidents in Microsoft Sentinel. |
| Erneutes Öffnen geschlossener Vorfälle | Im Defender-Portal können Sie die Warnungsgruppierung für Analyseregeln in Microsoft Sentinel nicht so konfigurieren, dass geschlossene Vorfälle wieder geöffnet werden, wenn neue Warnungen hinzugefügt werden. Geschlossene Vorfälle werden in diesem Fall nicht erneut geöffnet, und neue Warnungen lösen neue Vorfälle aus. |
Weitere Informationen finden Sie unter Incidents und Warnungen im Microsoft Defender-Portal und Warnungskorrelation und Incidentzusammenführung im Microsoft Defender-Portal.
Änderungen für Untersuchungen mit Advanced hunting beachten
Nach dem Onboarding von Microsoft Sentinel im Defender-Portal können Sie auf der Seite Erweiterte Suche auf alle Ihre vorhandenen Protokolltabellen, Kusto Query Language (KQL)-Abfragen und Funktionen zugreifen und diese verwenden. Alle Microsoft Sentinel-Warnungen, die an Vorfälle gebunden sind, werden in der Tabelle AlertInfo erfasst, auf die über die Seite Erweitertes Hunting zugegriffen werden kann.
Lesezeichen sind in Advanced hunting nicht verfügbar. Advanced hunting bietet eine einheitliche Abfrageoberfläche für Daten aus Microsoft Defender und Microsoft Sentinel. Lesezeichen sind jedoch weiterhin in Microsoft Sentinel>Bedrohungsverwaltung>Hunting verfügbar, wodurch die Microsoft Sentinel-spezifische Hunting-Erfahrung bereitgestellt wird. Sie können auch Alternativen wie Vorfalltags, gespeicherte Abfragen oder benutzerdefinierte Suchtabellen verwenden, um den Untersuchungskontext beizubehalten und nachzuverfolgen.
Weitere Informationen finden Sie unter "Erweiterte Suche" mit Microsoft Sentinel Daten in Microsoft Defender, insbesondere in der Liste der bekannten Probleme für die erweiterte Suche mit Microsoft Sentinel Daten und nachverfolgen von Daten während der Suche mit Microsoft Sentinel.
Mit Entitäten im Defender-Portal untersuchen
Im Microsoft Defender-Portal sind Entitäten im Allgemeinen entweder Ressourcen wie Konten, Hosts oder Postfächer oder Nachweise wie IP-Adressen, Dateien oder URLs.
Nach dem Onboarding von Microsoft Sentinel in das Defender-Portal werden Entitätsseiten für Benutzerentitäten, Geräteentitäten und IP-Adressen in einer einzigen Ansicht zusammengeführt, die eine umfassende Ansicht der Aktivität und des Kontexts und der Daten der Entität aus Microsoft Sentinel und Microsoft Defender XDR.
Das Defender-Portal stellt außerdem eine globale Suchleiste bereit, die die Ergebnisse aller Entitäten zentral bündelt, sodass Sie SIEM- und XDR-übergreifend suchen können.
Weitere Informationen finden Sie unter Entitätsseiten in Microsoft Sentinel.
Mit UEBA im Defender-Portal ermitteln
Die meisten Funktionen der Benutzer- und Entitätsverhaltensanalyse (UEBA) bleiben im Defender Portal identisch wie im Azure-Portal, mit Ausnahmen zum Hinzufügen von Entitäten zur Bedrohungserkennung und für IdentityInfo Tabellenschemaunterschiede:
Das Hinzufügen von Entitäten zu Threat Intelligence aus Incidents wird nur im Azure-Portal unterstützt. Weitere Informationen finden Sie unter Hinzufügen einer Entität zu Bedrohungsindikatoren.
Wenn Sie Microsoft Sentinel in das Microsoft Defender-Portal integrieren, ist die
IdentityInfoTabelle sowohl in der Microsoft Defender Erweiterten Suche als auch in Ihrem Sentinel Log Analytics-Arbeitsbereich verfügbar. Die in Advanced Hunting verwendete TabelleIdentityInfoenthält vereinheitlichte Felder aus Defender XDR und Microsoft Sentinel. Einige Felder, die in der Arbeitsbereichstabelle von Sentinel Log Analytics vorhanden sind, wurden entweder umbenannt oder werden in der Advanced Hunting-Tabelle nicht unterstützt. Achten Sie darauf, alle Abfragen zu überprüfen und zu aktualisieren, die in Microsoft Defender ausgeführt werden, z. B. Abfragen der erweiterten Suche oder benutzerdefinierte Erkennungen. Microsoft Sentinel Analyseregeln, Arbeitsmappen und andere Sentinel Abfragen verwenden weiterhin dieIdentityInfoTabelle im Log Analytics-Arbeitsbereich und sind nicht betroffen. Weitere Informationen sowie einen Vergleich der Tabellenschemas in der Advanced-Hunting-Erfahrung und in Log Analytics finden Sie unter IdentityInfo-Tabelle.
Wichtig
Wenn Sie zum Defender-Portal wechseln, wird die IdentityInfo Tabelle zu einer nativen Defender-Tabelle, die die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) auf Tabellenebene nicht unterstützt. Wenn Ihr organization RBAC auf Tabellenebene verwendet, um den Zugriff auf die IdentityInfo Tabelle im Azure-Portal einzuschränken, ist diese Zugriffssteuerung nach dem Übergang zum Defender-Portal nicht mehr verfügbar.
Aktualisieren von Untersuchungsprozessen zur Verwendung Microsoft Defender Threat Intelligence
Für Microsoft Sentinel Kunden, die vom Azure-Portal zum Defender-Portal wechseln, werden die vertrauten Threat Intelligence-Features im Defender-Portal unter Intel-Verwaltung beibehalten und mit anderen Threat Intelligence-Features erweitert, die im Defender-Portal verfügbar sind. Unterstützte Features hängen von den Lizenzen ab, über die Sie verfügen, z. B.:
| Funktion | Beschreibung |
|---|---|
| Bedrohungsanalyse | Unterstützt für Microsoft Defender XDR Kunden. Eine produktinterne Lösung, die von Microsoft-Sicherheitsexperten bereitgestellt wird und Sicherheitsteams hilft, indem sie Einblicke in neue Bedrohungen, aktive Bedrohungen und deren Auswirkungen bietet. Die Daten werden in einer intuitiven Dashboard mit Karten, Datenzeilen, Filtern und mehr dargestellt. |
| Intel-Profile | Unterstützt für Microsoft Defender Threat Intelligence Kunden. Kategorisieren sie Bedrohungen und Verhaltensweisen nach einem Bedrohungsakteurprofil, sodass sie leichter nachverfolgt und korreliert werden können. Diese Profile enthalten alle Indikatoren der Kompromittierung (Indicators of Compromise, IoC), die sich auf Taktiken, Techniken und Tools beziehen, die bei Angriffen verwendet werden. |
| Intel Explorer | Unterstützt für Microsoft Defender Threat Intelligence Kunden. Konsolidiert verfügbare IoCs und stellt bedrohungsbezogene Artikel bereit, sobald sie veröffentlicht werden, sodass Sicherheitsteams über neue Bedrohungen auf dem Laufenden bleiben können. |
| Intel-Projekte | Deprecated. Um Bedrohungsindikatoren zu organisieren und zu untersuchen, verknüpfen Sie Indikatoren mit einem Fall. |
Verwenden Sie im Defender-Portal ThreatIntelOjbects und ThreatIntelIndicators zusammen mit Kompromittierungsindikatoren für die Bedrohungssuche, die Reaktion auf Vorfälle, Copilot, Berichte und zum Erstellen von Beziehungsdiagrammen, die Verbindungen zwischen Indikatoren und Entitäten zeigen.
Für Kunden, die den MDTI-Feed (Microsoft Defender Threat Intelligence) verwenden, ist eine kostenlose Version über den Datenconnector von Microsoft Sentinel für MDTI verfügbar. Benutzer mit MDTI-Lizenzen können auch MDTI-Daten erfassen und Security Copilot für die Bedrohungsanalyse, aktive Bedrohungsüberprüfung und Bedrohungsakteurforschung verwenden.
Weitere Informationen zum Bedrohungsmanagement, zur Bedrohungsanalyse, zu Intelligence-Projekten und zur Bedrohungserkennung in Microsoft Sentinel finden Sie unter:
- Bedrohungsverwaltung
- Bedrohungsanalyse in Microsoft Defender XDR
- Verknüpfungsindikatoren zu einem Fall
- Bedrohungsinformationen in Microsoft Sentinel
Verwenden von Arbeitsmappen zum Visualisieren und Melden von Microsoft Defender Daten
Azure Arbeitsmappen sind weiterhin das primäre Tool für die Datenvisualisierung und -interaktion im Defender-Portal und funktionieren wie im Azure-Portal.
Um Arbeitsmappen mit Daten aus Advanced Hunting zu verwenden, stellen Sie sicher, dass Sie Protokolle in Microsoft Sentinel aufnehmen.
Weitere Informationen finden Sie unter Visualisieren und Überwachen Ihrer Daten mithilfe von Arbeitsmappen in Microsoft Sentinel.
Ähnliche Vorfälle (Vorschau) werden im Defender-Portal nicht unterstützt.
Die Microsoft Sentinel-Funktion „Ähnliche Vorfälle bei Fallermittlungen“ befindet sich in der Vorschau und wird im Defender-Portal nicht unterstützt. Da diese Funktion im Defender-Portal nicht unterstützt wird, ist der Tab "Ähnliche Vorfälle" nicht verfügbar, wenn man eine Seite mit Vorfalldetails aufruft.
Verwandte Inhalte
Verwenden Sie die folgenden Ressourcen, um mehr über den Übergang von Microsoft Sentinel zum Defender Portal zu erfahren:
- Das Beste von Microsoft Sentinel - jetzt in Microsoft Defender (Blog)
- Sehen Sie sich das Webinar An: Übergang zur einheitlichen SOC-Plattform: Deep Dive und Interactive Q&A für SOC-Experten.
- Häufig gestellte Fragen finden Sie im TechCommunity-Blog oder im Microsoft Community Hub.
- Überprüfen Sie die Unterschiede im Alertschema zwischen eigenständigen Konnektoren und Microsoft Defender XDR-Konnektoren