NIS2-Anforderungen auf Sentinel-Detektionen mappen
Praxisleitfaden zum Mapping der NIS2-Risikomanagementmaßnahmen auf Microsoft-Sentinel-Detektionen, KQL-Analysen und SOC-Nachweise nach NIS2UmsG.
NIS2 wird oft als Governance- und Dokumentationsübung verstanden. Das ist es nicht. Im deutschen NIS2UmsG, das seit dem 6. Dezember 2025 ohne Übergangsfrist gilt, steckt eine harte operative Forderung: Sie müssen einen erheblichen Sicherheitsvorfall erkennen, ihn als erheblich einstufen und ihn innerhalb von 24 Stunden nach Kenntnisnahme an das BSI melden können. Das ist zuerst ein Problem der Detection Engineering und erst danach ein Compliance-Problem. Dieser Beitrag ist das Mapping, mit dem wir bei Mandanten die NIS2-Vorgaben in konkrete Microsoft-Sentinel-Detektionen übersetzen, samt prüffestem Nachweispfad.
TL;DR / Die wichtigsten Punkte
- NIS2 nennt kein Produkt, doch die Fristen für die 24-Stunden-Frühwarnung und die 72-Stunden-Meldung sind im Unternehmensmaßstab ohne zentrales SIEM wie Microsoft Sentinel praktisch nicht einzuhalten.
- Die stärksten NIS2-Microsoft-Sentinel-Mappings sind Incident Handling, Erkennung und Meldung erheblicher Vorfälle, Protokollierung und Monitoring, Anomalieerkennung in der Lieferkette und Wirksamkeitsbewertung.
- Bauen Sie eine lebendige NIS2-SIEM-Mapping-Matrix: jede Maßnahme zu ihren Analyseregeln zu ihren Datenquellen, ausgerichtet an MITRE ATT&CK — das ist Ihr Auditnachweis.
- Die automatischen Zeitstempel von Sentinel machen die Kenntnisnahme belastbar und starten die gesetzliche Frist im Moment des Auslösens einer Regel für erhebliche Vorfälle.
- Sentinel ist nicht das gesamte Programm. Es ist die Maßnahme, die belegt, dass Ihre übrigen NIS2-Maßnahmen tatsächlich wirken.
Warum NIS2 zum Detektionsproblem wird
Der größte Teil des NIS2-Maßnahmenkatalogs beschreibt Zustände, die Sie herstellen müssen: Zugriffskontrolle, Kryptografie, Geschäftskontinuität, Lieferkettensicherheit. Das Melderegime beschreibt dagegen ein Ereignis, das Sie im Geschehen abfangen müssen. Die einschlägigen Pflichten verlangen eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme eines erheblichen Vorfalls, eine ausführlichere Meldung binnen 72 Stunden und eine Abschlussmeldung binnen eines Monats. Auslöser ist die Kenntnisnahme, und Kenntnisnahme ist eine Funktion der Erkennung.
Genau hier scheitern viele Organisationen still an den eigenen Maßnahmen. Sie betreiben ein SIEM, dessen Regeln aber auf generisches Threat Hunting getrimmt sind und nicht auf die spezifische NIS2-Frage: Ist ein erheblicher Vorfall bei einem wesentlichen oder wichtigen Dienst eingetreten? Der Abstand zwischen „Wir haben Alarme" und „Wir können unsere 24-Stunden-Zeitleiste gegenüber dem BSI verteidigen" ist genau die Lücke, die dieses Mapping schließt. (Falls Sie noch nicht sicher sind, ob Sie überhaupt betroffen sind, beginnen Sie mit unserem NIS2-Scope-Test nach NIS2UmsG.)
NIS2-Maßnahmen auf Sentinel-Fähigkeiten mappen
Die NIS2-Risikomanagementmaßnahmen sind bewusst technologieneutral. Die Aufgabe des Praktikers ist es, jede einzelne an etwas Konkretes und Beobachtbares zu binden. Die folgende Tabelle ist der Kern unseres NIS2-SIEM-Mapping-Ansatzes. Sie ist nicht abschließend, deckt aber die Maßnahmen ab, bei denen ein SIEM die Hauptarbeit leistet.
| NIS2-Risikomanagementmaßnahme | Sentinel-Fähigkeit als Nachweis | Beispielhafter Erkennungsfokus |
|---|---|---|
| Incident Handling | Vorfälle, Automatisierungsregeln, Entity-Zeitleisten | Mehrstufiger Angriff als ein nachverfolgter Vorfall |
| Erkennung & Meldung erheblicher Vorfälle | Geplante & NRT-Analyseregeln, Watchlists | Ransomware-Staging, Massenabfluss, Identitätskompromittierung |
| Protokollierung & Monitoring | Datenkonnektoren, Log-Analytics-Aufbewahrung | Abdeckung von Identität, Endpunkt, Steuerungsebene, Netzwerk |
| Zugriffskontrolle & MFA (Überwachung) | Entra-ID-Anmelde-/Audit-Analysen | MFA-Fatigue, unmögliche Reisen, privilegierte Rollenaktivierung |
| Kryptografie & Schlüsselverwaltung (Überwachung) | Key-Vault-Auditprotokoll-Analysen | Anomaler Geheimniszugriff, Schlüssellöschung, Richtlinienänderung |
| Lieferkettensicherheit | Cross-Tenant-/Drittparteien-Telemetrie | Anomales Verhalten von Lieferanten- oder Partneridentitäten |
| Geschäftskontinuität & Backup-Integrität | Backup- und Recovery-Log-Analysen | Backup-Löschung, Manipulation des Recovery Vault |
| Wirksamkeitsbewertung der Maßnahmen | Workbooks, Regelanalysen, Content-Hub-Abdeckung | Erkennungsabdeckung und Fehlalarmtrend im Zeitverlauf |
Der Punkt der Tabelle ist nicht, dass Sentinel „NIS2 erledigt". Der Punkt ist, dass Sie für jede Pflicht auf ein konkretes, abfragbares Artefakt verweisen können. Fragt das BSI oder ein ISO-27001-Auditor, woran Sie es bemerkt hätten, antworten Sie mit einem Regelnamen und einer Datenquelle, nicht mit einer Folie.
Die Detektionsebene, die die Frist tatsächlich startet
Die wichtigsten Detektionen sind jene, die die Erheblichkeitsfrage beantworten. Wir implementieren typischerweise einen kleinen Satz hochkonfidenter Analyseregeln für „Kandidaten erheblicher Vorfälle" — etwa bestätigte Datenexfiltration oberhalb eines Schwellenwerts, Ransomware-Verhalten auf einem produktiven Dienst oder die Kompromittierung einer privilegierten Identität, die einen wesentlichen Dienst steuert. Diese Regeln sind bewusst konservativ und treffsicher, denn sie sind direkt mit dem Meldeprozess aus unserem NIS2-Runbook für die 24/72-Stunden-Meldung verdrahtet.
In einem Projekt für einen neu betroffenen mittelständischen Logistikbetreiber fanden wir ein SOC mit über 200 aktivierten Regeln vor — doch keine bildete sauber den Fall „ein Vorfall, den eine Geschäftsleitung melden müsste" ab. Wir lieferten acht eng gefasste Regeln für erhebliche Vorfälle, jede mit der bedienten NIS2-Maßnahme und einer MITRE-ATT&CK-Technik versehen. Nicht die Zahl der Regeln, sondern die reduzierte Mehrdeutigkeit machte die 24-Stunden-Zeitleiste verteidigungsfähig.
Ein KQL-Beispiel: Kompromittierung privilegierter Identitäten
NIS2 legt überproportionalen Wert auf Identität, denn die Kompromittierung einer Identität ist der schnellste Weg zu einem erheblichen Vorfall bei einem wesentlichen Dienst. Eine vereinfachte, aber repräsentative Detektion für anomale Aktivierung privilegierter Rollen in Microsoft Entra ID:
AuditLogs
| where OperationName == "Add member to role"
| where TargetResources has_any ("Global Administrator", "Privileged Role Administrator", "Security Administrator")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| join kind=leftouter (
SigninLogs
| summarize KnownCountries = make_set(LocationDetails.countryOrRegion) by UserPrincipalName
) on $left.Actor == $right.UserPrincipalName
| extend ActivationCountry = tostring(parse_json(AdditionalDetails)[0].value)
| where ActivationCountry !in (KnownCountries)
| project TimeGenerated, Actor, OperationName, ActivationCountry, KnownCountriesDas ist illustrativ, nicht produktionsreif — echte Regeln müssen gegen Ihre Baseline und Ihr Privileged-Access-Modell abgestimmt werden (siehe Zero-Trust-Leistungen zu unserem Vorgehen bei den zugrunde liegenden Identitätskontrollen). Doch das Prinzip wird deutlich: Die Regel ist benannt, einer NIS2-Maßnahme zugeordnet und erzeugt ein zeitgestempeltes Artefakt, das Sie als Nachweis vorlegen können.
Nicht alles aufnehmen: die Kosten-Abdeckung-Entscheidung
Ein wiederkehrender Fehler ist, NIS2 als Auftrag zu verstehen, alles zu protokollieren. Das ist es nicht. Gefordert sind geeignete und verhältnismäßige Maßnahmen. Telemetrie aufzunehmen, auf der Sie nie erkennen, ist reiner Kostenfaktor. Beim Zuschnitt einer NIS2-konformen Sentinel-Umgebung nutzen wir eine einfache Stufung:
| Datenstufe | Inhalt | NIS2-Begründung |
|---|---|---|
| Stufe 1 — essenziell | Entra ID, Defender XDR, Azure Activity, M365-Audit | Direkter Nachweis für die wahrscheinlichsten erheblichen Vorfälle |
| Stufe 2 — hoher Wert | Endpunkt-Rohdaten, Firewall, DNS, Flow-Logs, Key Vault | Ermöglicht Netzwerk- und Lateral-Movement-Erkennung |
| Stufe 3 — kontextuell | On-Prem-/OT-Syslog/CEF, Threat Intel, App-Logs | Im Anwendungsbereich bei wesentlichen oder wichtigen Diensten |
Die Leitregel: Referenziert eine Datenquelle keine Analyseregel und keine Hunting-Abfrage und trägt sie keine Nachweispflicht, zahlen Sie für Speicher, nicht für Sicherheit.
Den Kreis schließen: Registrierung, Nachweise, Überprüfung
Erkennungsabdeckung ist nur dann glaubwürdig, wenn sie dokumentiert und überprüft wird. Drei Gewohnheiten machen den Unterschied:
- Halten Sie die Mappingmatrix lebendig. Jede neue Analyseregel erfasst die bediente NIS2-Maßnahme und die abgedeckte MITRE-Technik. Jede stillgelegte Regel wird auf die entstehende Lücke geprüft.
- Machen Sie Abdeckung sichtbar. Ein Sentinel-Workbook mit aktivierten Regeln, Datenquellen-Gesundheit und Abdeckungslücken ist das Artefakt, das Sie einem Auditor übergeben — und das die Aufsicht der Geschäftsleitung real statt nominell macht.
- Prüfen Sie die Wirksamkeit im Takt. NIS2 erwartet, dass Sie bewerten, ob Maßnahmen wirken. Erkennungszeit, Fehlalarmquote und Abdeckungstrend belegen kontinuierliche Verbesserung.
Falls Sie sich noch nicht beim BSI registriert haben, sollte die Monitoring-Story parallel aufgebaut werden — unsere Anleitung zur BSI-Registrierung erläutert den Portalprozess, und die Registrierung bleibt auch nach Ablauf der Frist vom 6. März 2026 erforderlich.
Ein abschließender Rahmen für die Geschäftsleitung: NIS2 macht die Geschäftsleitung persönlich haftbar für Aufsicht und Billigung der Risikomanagementmaßnahmen, mit Bußgeldern bis zu 10 Millionen Euro oder 2 % des weltweiten Umsatzes für besonders wichtige Einrichtungen. Eine sauber gemappte Sentinel-Umgebung ist eines der wenigen Artefakte, mit denen ein CISO nachweisbar zeigen kann, dass diese Maßnahmen existieren und wirken. Das ist ihr eigentlicher Wert unter NIS2 — nicht Erkennung um ihrer selbst willen, sondern verteidigungsfähige Rechenschaft.
FAQ
Verlangt NIS2 ein SIEM wie Microsoft Sentinel? NIS2 nennt kein Produkt. Gefordert sind geeignete und verhältnismäßige Risikomanagementmaßnahmen, einschließlich Incident Handling, Protokollierung, Monitoring und der Fähigkeit, erhebliche Sicherheitsvorfälle innerhalb enger Fristen zu erkennen und zu melden. In der Praxis sind die 24-Stunden-Frühwarnung und die 72-Stunden-Meldung für mittlere und größere Unternehmen ohne zentrales SIEM kaum einzuhalten. Microsoft Sentinel ist eine belastbare Möglichkeit, die Anforderungen an Erkennung, Korrelation und Nachweisführung zu erfüllen, besonders in Microsoft-geprägten Umgebungen.
Welche NIS2-Risikomanagementmaßnahmen lassen sich auf Sentinel mappen? Am klarsten abbildbar sind Incident Handling, die Erkennung und Meldung erheblicher Sicherheitsvorfälle, Protokollierung und Monitoring, die Anomalieerkennung in der Lieferkette sowie die Wirksamkeitsbewertung der Maßnahmen. Sentinel deckt dies über Datenkonnektoren, Analyseregeln, Automatisierungs-Playbooks und Workbooks ab. Zugriffskontrolle und Kryptografie werden überwiegend an anderer Stelle durchgesetzt, doch Sentinel liefert weiterhin den Monitoring-Nachweis, dass diese Maßnahmen wirken.
Wie unterstützt Sentinel die Einhaltung der 24- und 72-Stunden-Fristen? Sentinel versieht Erkennung, Vorfallserstellung und Analystenaktionen automatisch mit Zeitstempeln und liefert so einen belastbaren Nachweis darüber, wann die Kenntnisnahme erfolgt ist. Automatisierungsregeln können einen nachverfolgten Fall eröffnen, die Rufbereitschaft alarmieren und die Meldefrist in dem Moment starten, in dem eine Regel für einen erheblichen Vorfall auslöst. So wird aus einer gesetzlichen Frist ein operativer Arbeitsablauf statt einer nachträglichen Rekonstruktion.
Reicht Microsoft Sentinel allein für die NIS2-Konformität? Nein. NIS2 umfasst Governance, Risikomanagement, Lieferkettensicherheit, Geschäftskontinuität und die Verantwortung der Geschäftsleitung. Sentinel adressiert die Ebene der Erkennung, des Monitorings und der Vorfallsnachweise. Sie benötigen weiterhin Richtlinien, ein Risikoregister, Lieferantenbewertungen, getestete Wiederherstellung und eine dokumentierte Aufsicht durch die Geschäftsleitung. Betrachten Sie Sentinel als die Maßnahme, die belegt, dass Ihre übrigen Maßnahmen wirken, nicht als das gesamte Programm.
Welche Logs sollten wir für das NIS2-Monitoring in Sentinel aufnehmen? Priorisieren Sie Identität (Entra-ID-Anmelde- und Auditprotokolle), Microsoft-Defender-XDR-Vorfälle, Azure Activity, Microsoft-365-Auditprotokolle sowie Netzwerktelemetrie wie Firewall-, DNS- und Flow-Logs. Ergänzen Sie On-Premises- sowie OT- oder branchenspezifische Systeme über Syslog oder CEF, soweit sie im Anwendungsbereich liegen. Der Grundsatz: Nehmen Sie nur auf, worauf Sie tatsächlich erkennen oder untersuchen, denn ungenutzte Daten sind Kosten, keine Sicherheit.
Wie weisen wir dem BSI oder einem Auditor die NIS2-Detektionsabdeckung nach? Pflegen Sie ein lebendiges Mapping zwischen jeder NIS2-Maßnahme, den zugehörigen Sentinel-Analyseregeln und den speisenden Datenquellen, idealerweise an MITRE ATT&CK ausgerichtet. Nutzen Sie Sentinel-Workbooks und den Content Hub, um aktivierte Regeln, Abdeckungslücken und die Regelwirksamkeit im Zeitverlauf darzustellen. Zusammen mit den Vorfallszeitleisten ergibt das für das BSI ein klares, nachweisbasiertes Bild statt bloßer Behauptungen.
NIS2-Monitoring ist eine Disziplin der Detection Engineering, und der Unterschied zwischen einem lauten und einem verteidigungsfähigen SOC liegt im Mapping. Wenn Sie ein zweites, erfahrenes Augenpaar darauf werfen lassen möchten, wie Ihre Sentinel-Umgebung auf NIS2 abbildet — und wo die Lücken sind — sprechen Sie mit unserem Team für Zero Trust und Security Operations. Wir haben dies für Einrichtungen umgesetzt, die neu in den Anwendungsbereich des NIS2UmsG fallen, und beginnen gern mit einer fokussierten Abdeckungsprüfung.
Themen