Autor: Andreas Rogge
Ihr betreibt Defender und wollt einen älteren Vorfall untersuchen. Dafür braucht ihr Telemetrie, die über den bisherigen Suchzeitraum hinausgeht. Wenn ihr diese Daten zusätzlich in Sentinel vorhaltet, stellt sich mit ISOC eine konkrete Frage: Könnte die angekündigte längere Aufbewahrung einen Teil dieser zusätzlichen Datenhaltung ersetzen?
Microsoft hat am 23. September 2026 das Integrated Security Operations Center, kurz ISOC, in Microsoft Defender vorgestellt. Es soll SIEM-Funktionen und Threat Protection enger zusammenbringen und Analysten sowie KI-Agenten eine gemeinsame Arbeitsgrundlage geben.
Wir konnten ISOC bisher noch nicht selbst ausprobieren. Dieser Artikel ordnet die öffentlichen Unterlagen ein und trennt den aktuellen Preview-Umfang von angekündigten Erweiterungen. Gerade bei Retention und Kosten lohnt sich diese Unterscheidung.
Der Einstieg hängt davon ab, ob ihr Sentinel bereits betreibt
ISOC ist laut Microsofts Produkt-FAQ ein Benefit für berechtigte bestehende Lizenzen. Es ist kein zusätzliches eigenständiges Produkt. Daraus folgt allerdings keine pauschale Kostenfreiheit für alle Datenquellen und Nutzungsarten.
Die Learn-Übersicht nennt Microsoft Defender Suite, Microsoft 365 E5 und Microsoft 365 E7 als berechtigte Lizenzen. Die aktuelle Preview-Phase richtet sich an Kunden ohne aktiven Sentinel-Workspace. Microsoft weist ausdrücklich darauf hin, dass ein produktiver Workspace nicht getrennt werden soll, um an der Preview teilzunehmen.
Bestehende Sentinel-Kunden sollen laut Produkt-FAQ ab dem 15. November 2026 die Wahl erhalten, zu ISOC zu wechseln, sofern die Lizenzvoraussetzungen erfüllt sind. Das bestehende Sentinel-Angebot bleibt bestehen. Für berechtigte E5- und E7-Kunden nennt die FAQ keine Mindestanzahl an Seats.
Damit unterscheiden sich die nächsten Schritte. Ein Defender-Team ohne Sentinel kann den Einstieg prüfen. Ein Team mit produktiver Sentinel-Umgebung sollte seine vorhandenen Abhängigkeiten erfassen und die Details eines späteren Wechsels abwarten.
Ein Teil der Funktionen kommt ohne ISOC-Workspace aus
Die Funktionsübersicht in Microsoft Learn beschreibt folgende Workspace-Abhängigkeiten für die Preview:
- Case Management: kein ISOC-Workspace erforderlich.
- Playbook-Generierung aus natürlicher Sprache: kein ISOC-Workspace erforderlich.
- Erweiterte Automatisierungsregeln: kein ISOC-Workspace erforderlich.
- Workbooks: kein ISOC-Workspace erforderlich.
- UEBA: ISOC-Workspace erforderlich.
- Content Hub: ISOC-Workspace erforderlich.
- Repository-Anbindung für CI/CD: ISOC-Workspace erforderlich.
- Threat Intelligence: ISOC-Workspace erforderlich.
- Zusätzliche Azure- und Drittanbieterdaten: ISOC-Workspace erforderlich.
Die Übersicht beschreibt die Workspace-Abhängigkeit. Berechtigungen und die Konfiguration des jeweiligen Features müssen zusätzlich passen.
Das Case Management bündelt Untersuchungskontext, Aufgaben und Bearbeitungsdokumentation im Defender-Portal. Es gibt Incident Cases, die sich in Preview befinden, und Generic Cases für weitere SecOps-Arbeit. Der verfügbare Umfang hängt unter anderem vom Case-Typ und der Tenant-Konfiguration ab.
Für einen ersten Test würden wir einen vollständigen Übergabeprozess durchspielen: Ein Analyst übernimmt einen Fall, dokumentiert seine Entscheidung und weist eine Folgeaufgabe zu. Ein zweiter muss anschließend erkennen können, was bereits geprüft wurde und was noch offen ist. Daran lässt sich der Nutzen für die eigene Arbeit besser beurteilen als an der Zahl neuer Menüpunkte.
Ein Workspace erweitert den Umfang und braucht eine Azure-Subscription
Laut Dokumentation zur Datenverarbeitung sind native Defender-Daten direkt in der Defender-Erfahrung verfügbar. Sie müssen dafür nicht separat in einen ISOC-Workspace eingespielt werden. Zusätzliche unterstützte Microsoft- und Drittanbieterdaten lassen sich über Konnektoren anbinden. Azure Activity und Office 365 Activity sind in der dokumentierten Quellenliste ausdrücklich als Datenquellen über Konnektoren aufgeführt.
Die Einrichtungsanleitung nennt eine aktive Azure-Subscription, die Entra-Rolle Security Administrator und passende Subscription-Berechtigungen. Dokumentiert sind entweder ein Owner ohne Bedingungen oder die Kombination aus User Access Administrator und Microsoft Sentinel Contributor.
Der beschriebene Pfad lautet Setup & configuration > Settings > Microsoft Sentinel > SIEM workspaces. Über Create workspace werden Subscription und Workspace-Konfiguration ausgewählt. Vor Connect sollten Region, Ressourcengruppe und Benennung geprüft werden.
Die Aussage „Ab diesem Klick kostet ISOC Geld“ wäre zu pauschal. Entscheidend sind die tatsächlich genutzten Leistungen und die geltenden Abrechnungsbedingungen. Vor der Anbindung zusätzlicher Quellen braucht es deshalb eine Abschätzung ihres Datenvolumens.
30 Tage gelten heute, 90 Tage sind für November angekündigt
Die Learn-Dokumentation nennt für die aktuelle Preview-Phase 30 Tage eingeschlossene Aufbewahrung für Defender-Daten. Der Tech-Community-Beitrag zur Einführung ergänzt den Zeitplan:
- Aktuelle Preview; 30 Tage eingeschlossene Retention für Defender-Daten
- Ab 1. Oktober 2026 angekündigt; PAYG-Ingestion für Nicht-Microsoft-Daten über mehr als 500 Konnektoren zu 2,40 USD/GB; regionale Preise und Bedingungen können abweichen
- Ab 15. November 2026 angekündigt; Erweiterung auf 90 Tage für Microsoft-Defender-Daten, Azure Activity und Office 365 Activity
Damit lässt sich die unterschiedliche Tageszahl auf Produktseite und Learn-Seite zeitlich einordnen. Die 90 Tage beschreiben eine angekündigte Erweiterung. Für einen Test zum Veröffentlichungsstand dieses Artikels sind die dokumentierten 30 Tage maßgeblich.
Für eine Euro-Kalkulation reicht der angekündigte Dollarpreis noch nicht. Dafür müssen der für die eigene Region gültige Preis und die jeweiligen Vertragsbedingungen feststehen. Die aktuelle Learn-Seite zur Abrechnung nennt keine konkrete Rate, sondern weist auf mögliche zusätzliche Ingestion-Kosten hin.
Für bestehende Sentinel-Umgebungen kann die längere Aufbewahrung interessant werden, wenn Defender-Telemetrie bisher hauptsächlich für spätere Untersuchungen zusätzlich eingespielt wird. Ob dieser Datenpfad entfallen kann, hängt aber auch davon ab, welche Regeln und Auswertungen ihn benötigen. Die Retention allein entscheidet das nicht.
Die Kostenbewertung beginnt mit euren tatsächlichen Tabellen
Vor einem möglichen Wechsel würden wir ermitteln, welche Tabellen heute das abrechenbare Ingestionsvolumen verursachen. Anschließend lässt sich für jede relevante Tabelle prüfen, warum sie vorhanden ist und welche Abhängigkeiten daran hängen.
Die folgende Abfrage ist für den Log-Analytics-Workspace der bestehenden Sentinel-Umgebung gedacht. Sie verwendet die dokumentierte Tabelle Usage und orientiert sich an Microsofts Beispielen zur Nutzungsanalyse. Sie wurde gegen das Schema geprüft, aber nicht in einem Tenant ausgeführt.
// Abrechenbares Ingestionsvolumen je Tabelle, letzte 30 abgeschlossene UTC-Tage
let WindowStart = startofday(ago(30d));
let WindowEnd = startofday(now());
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= WindowStart and EndTime <= WindowEnd
| where IsBillable == true
| summarize BillableIngestionGB = round(sum(Quantity) / 1000.0, 2) by DataType
| sort by BillableIngestionGB desc
Quantity enthält MB. Microsoft verwendet für die GB-Auswertung die Division durch 1.000. Die Zeitgrenzen beziehen sich auf die aggregierten Nutzungsintervalle; der aktuelle, noch unvollständige Tag bleibt außen vor.
Die Abfrage zeigt bewusst alle gefundenen Tabellen. Eine Auswahl allein über Präfixe wie Identity oder Device ist keine verlässliche Zuordnung zum ISOC-Datenvorteil. Ordnet die Ergebnisse den tatsächlich konfigurierten Datenquellen zu.
Das Ergebnis beschreibt Datenvolumen. Es berechnet weder die spätere ISOC-Rechnung noch eine garantierte Einsparung. Für eine belastbare Gegenüberstellung braucht ihr zusätzlich den wirksamen Tarif, mögliche Benefits sowie je Tabelle das verwendete Tier und die Retention. Kosten für längere Speicherung und zusätzliche Verarbeitung müssen separat berücksichtigt werden.
Die aktuelle Usage lässt sich stündlich prüfen
Für einen aktuellen Überblick könnt ihr im selben Log-Analytics-Workspace die letzten 24 abgeschlossenen UTC-Stunden nach Tabelle und Stunde auswerten. Damit werden kurzfristige Volumenspitzen sichtbar. Die laufende Stunde bleibt bewusst außen vor.
// Abrechenbares Ingestionsvolumen, letzte 24 abgeschlossene UTC-Stunden
let WindowEnd = bin(now(), 1h);
let WindowStart = WindowEnd - 24h;
Usage
| where TimeGenerated > ago(2d)
| where StartTime >= WindowStart and EndTime <= WindowEnd
| where IsBillable == true
| summarize BillableIngestionGB = round(sum(Quantity) / 1000.0, 3)
by HourUTC = bin(StartTime, 1h), DataType
| sort by HourUTC desc, BillableIngestionGB desc
Die Usage-Tabelle enthält stündlich aggregierte Nutzungsdaten. Das Ergebnis ist daher keine Echtzeitmessung; noch nicht gemeldete Intervalle können fehlen. Eine fehlende Zeile sollte nicht automatisch als null Ingestion gewertet werden. Die Abfrage zeigt abrechenbares Datenvolumen in GB, keinen Rechnungsbetrag. Sie wurde gegen das dokumentierte Schema geprüft, aber nicht im Tenant ausgeführt.
Was beim Data Lake feststeht und beim ISOC-Wechsel offenbleibt
Für Kunden, die nach dem 23. September 2026 onboarden, beschreibt Microsofts Sentinel-Update vom September bereits ein integriertes SIEM- und Data-Lake-Onboarding. Ein separates Data-Lake-Onboarding samt separatem Billing-Setup entfällt. Nach dem Sentinel-Onboarding und der Verbindung zum Defender-Portal lässt sich das Lake-Tier über Table management > Retention aktivieren. Wer zuvor bereits zum Sentinel Data Lake onboardet wurde, kann laut Microsoft die bisherige Dokumentation weiterverwenden.
Microsoft nennt außerdem interaktive KQL-Abfragen auf Lake-Daten in Advanced Hunting. Historische Daten lassen sich damit untersuchen, ohne sie zunächst ins Analytics-Tier zurückzuholen. Das bedeutet jedoch nicht, dass Lake-Daten dieselben Funktionen für Echtzeit-Detections wie Daten im Analytics-Tier bieten.
Das integrierte Onboarding macht die Langzeitaufbewahrung nicht pauschal kostenlos. Die Sentinel-Retention-Dokumentation unterscheidet weiterhin Kosten für Ingestion, Speicherung und Verarbeitung. Bei zusätzlichen XDR-Daten im Analytics-Tier können beispielsweise Ingestion-Kosten anfallen, obwohl die Speicherung bis 90 Tage eingeschlossen ist. Diese bestehende Sentinel-Regelung ist getrennt vom angekündigten ISOC-Retention-Benefit zu bewerten.
Für weitergehende Auswertungen beschreibt Microsoft auch die Anbindung an Fabric. Die Azure-Monitor-Mirroring-Anleitung ist als Preview gekennzeichnet und setzt Fabric-Kapazität voraus; daraus lässt sich keine pauschale Kostenfreiheit der anschließenden Auswertung ableiten.
Diese Sentinel-Neuerungen ersetzen keine vollständige Anleitung für den Wechsel zu ISOC. Für bestehende Umgebungen würden wir vor einer Entscheidung weiterhin diese Punkte klären:
- Wie werden vorhandene Analytics Rules und ihre Abhängigkeiten beim Wechsel behandelt?
- Was gilt für bestehende Commitment Tiers und die zukünftige Abrechnung?
- Wie werden die bestehenden Analytics- und Data-Lake-Retention-Einstellungen sowie die darauf aufbauenden Auswertungen bei einem späteren Wechsel zu ISOC übernommen?
- Welche bisherigen Datenpfade müssen für Hunting, Workbooks oder Automatisierung bestehen bleiben?
Dass Analytics Rules in der ISOC-Funktionstabelle nicht aufgeführt sind, belegt weder ihre Abschaffung noch einen Ersatz durch Custom Detections. Diese Vermutung wäre als Planungsgrundlage zu dünn.
Für MSSPs lohnt sich außerdem eine genauere Unterscheidung. Microsoft dokumentiert bereits Case Management über mehrere Tenants im Defender-Multitenant-Portal. Die Liste kann Tenant und Tenant ID anzeigen; Zugriffe werden auf Tenant-Ebene berücksichtigt. Die vertiefte Bearbeitung erfolgt im Portal des jeweiligen Tenants.
Wie eure konkreten Azure-Lighthouse-Delegationen und Betriebsprozesse in eine ISOC-Umgebung passen, muss separat geprüft werden. Der erfolgreiche Zugriff auf eine gemeinsame Fallliste beantwortet diese Frage noch nicht.
Automatisierung und Agents brauchen einen eigenen Funktionstest
Die KI-gestützte Playbook-Generierung führt Microsoft bereits seit Mai 2026 als allgemein verfügbar in Sentinel. Die Funktion wurde also schon vor der ISOC-Ankündigung angeboten.
Der Playbook Generator erzeugt aus einer Beschreibung zunächst einen Plan und anschließend Code. Microsoft sieht eine Prüfung und einen Test vor. Gespeicherte Playbooks sind zunächst deaktiviert.
Für einen ersten Versuch eignet sich eine kontrollierte Anreicherung mit anschließendem Kommentar am Vorgang. Dabei lässt sich prüfen, ob der richtige Fall bearbeitet wird und ob Fehler bei einem API-Aufruf nachvollziehbar bleiben.
Die dokumentierten Grenzen gehören in diesen Test: Der Generator unterstützt Python, externe Bibliotheken und verschachtelte Playbook-Aufrufe werden nicht unterstützt. Die maximale Laufzeit beträgt zehn Minuten. Ergebnisse der Automatisierungsregeln stehen im Activity Log und werden nicht in die Sentinel-Health-Tabelle geschrieben. Bestehendes Monitoring muss diesen Unterschied berücksichtigen.
Auch beim agentic SOC lohnt sich eine präzise Formulierung. Die Dokumentation zu Incident Cases beschreibt bereits Agent-Sitzungen. Dafür ist Zugriff auf Project Perception erforderlich. Die ISOC-Berechtigung allein belegt somit nicht, dass diese Funktionen im eigenen Tenant nutzbar sind.
Für Defender-Teams ohne Sentinel lohnt sich ein begrenzter Pilot
Berechtigte Teams ohne aktiven Sentinel-Workspace können einen konkreten Ablauf auswählen und prüfen, ob ISOC die Fallbearbeitung verbessert. Dabei sollte sichtbar werden, welche manuellen Schritte entfallen und welcher zusätzliche Betriebsaufwand entsteht.
Für bestehende Sentinel-Umgebungen würden wir zunächst die Ingestionszahlen und Regelabhängigkeiten aufnehmen. Die angekündigte längere Aufbewahrung ist ein guter Anlass, die bisherige Architektur zu überprüfen. Eine Änderung produktiver Datenpfade sollte auf dokumentierten Migrationsbedingungen und einem erfolgreichen Test beruhen.
Uns fehlt dafür noch die eigene Praxiserfahrung mit ISOC. Ein nachvollziehbarer Vergleich desselben Untersuchungsfalls im bisherigen Ablauf und in ISOC wäre der nächste Schritt für Die Sentinels.