Sicherheitsprotokollierung und Überwachung (SIEM, SOC, MDR) als Nachweis

Ein praktischer Leitfaden zu Sicherheitsprotokollierung, SIEM und SOC- oder MDR-Diensten: was protokolliert werden soll, Aufbewahrung, Erkennungsanwendungsfälle, Alert-Triage und wie Sie Aufsichtsbehörden nachweisen, dass die Erkennung funktioniert.

Dieser Leitfaden richtet sich an IT- und Sicherheitsmanager, CISOs und die MSPs oder vCISOs, die sie beraten und die Sicherheitsprotokollierung und -überwachung so einrichten oder aufräumen müssen, dass sie einer NIS2-, CyFun- oder DORA-Überprüfung standhalten. Er behandelt, was protokolliert werden muss, wie lange es aufbewahrt werden muss, welche Erkennungen zuerst aufgebaut werden müssen, wie Warnungen behandelt werden sollten und wie zwischen einem internen SOC, einem ausgelagerten SOC und Managed Detection and Response (MDR) gewählt wird. Am Ende haben Sie ein Register und eine Möglichkeit, nachzuweisen, dass die Erkennung funktioniert.

Bevor Sie beginnen

Sie benötigen drei Eingaben: eine Liste kritischer Dienste und der Systeme, die diese unterstützen (aus Ihrem Asset-Verzeichnis oder einer Geschäftsauswirkungsanalyse), Ihre aktuelle Risikobewertung und einen Überblick über das, was Sie bereits erfassen. Beziehen Sie den Datenschutzbeauftragten frühzeitig ein. Sicherheitsprotokolle enthalten personenbezogene Daten, daher müssen Zweck, Minimierung, Zugriff und Aufbewahrung gemäß der DSGVO dokumentiert werden.^[7].

Schritt 1: Verstehen Sie, was die Regeln tatsächlich erfordern

NIS2 Artikel 21 Absatz 2 Buchstabe b verlangt Maßnahmen zur Behandlung von Vorfällen, und Sie können nicht behandeln, was Sie nicht erkennen^[1]. Für digitale Infrastruktur und Anbieter digitaler Dienste ist die Durchführungsverordnung 2024/2690 spezifisch. Anhang Punkt 3.2 fordert Einrichtungen auf, Aktivitäten zu überwachen und zu protokollieren, um Ereignisse zu erkennen, die Vorfälle sein könnten; zu protokollieren, soweit angemessen, Netzwerkverkehr, Konto- und Authentifizierungsereignisse, privilegierte Aktivitäten, Änderungen an kritischen Konfigurationen und Sicherungsdateien sowie Ereignisse von Sicherheitswerkzeugen; die Überwachung, soweit machbar, zu automatisieren und abzustimmen, um falsch positive und falsch negative Ergebnisse zu begrenzen; Protokolle für einen vordefinierten Zeitraum aufzubewahren und zu schützen; Zeitquellen zu synchronisieren; die Protokollierung redundant zu gestalten; und die Einrichtung in regelmäßigen Abständen und nach erheblichen Vorfällen zu überprüfen^[2]. Die Durchführungsverordnung gilt formal nur für diese Anbietertypen, ist aber ein praktischer Maßstab für jede Einrichtung, und die technische Anleitung der ENISA erläutert jeden Punkt.^[5].

Für Finanzeinrichtungen verlangt DORA Artikel 10 Mechanismen zur zeitnahen Erkennung anomaler Aktivitäten, mehrschichtige Kontrollen, Schwellenwerte für Warnungen, die eine Vorfallreaktion auslösen, und regelmäßige Tests der Erkennung^[3]. Die Delegierte Verordnung 2024/1774 ergänzt dies: Protokollierungsverfahren, die Ereignisse, Aufbewahrung und Schutz definieren (Artikel 12), Zeitsynchronisierung mit einer dokumentierten zuverlässigen Zeitquelle und Warnungen bei anomalen Aktivitäten mindestens für Vermögenswerte, die kritische oder wichtige Funktionen unterstützen, bearbeitet sowohl während als auch außerhalb der Arbeitszeiten (Artikel 23).^[4].

Schritt 2: Definieren Sie zuerst die Erkennungsfälle

Ein Erkennungsfall ist etwas Spezifisches, das Sie erkennen möchten, mit einer definierten Reaktion. Beginnen Sie mit zehn bis fünfzehn Fällen, die Ihren Risiken entsprechen; Ransomware-Vorboten, Kontoübernahme und Missbrauch privilegierter Zugriffe sind sinnvolle Ausgangspunkte.

• Anmeldung aus einem ungewöhnlichen Land oder unmögliche Reisebewegung bei einem privilegierten Konto.
• MFA-Ermüdung (wiederholte Push-Ablehnungen) oder MFA-Methode geändert, gefolgt von einer Anmeldung.
• Neue Postfach-Weiterleitungsregel zu einer externen Adresse.
• Mitglied zu einer privilegierten Gruppe hinzugefügt (Domain-Administratoren, globale Administratoren).
• Endpunktschutz deaktiviert oder manipuliert; Ransomware-Verhalten erkannt.
• Löschung oder Änderung von Sicherungsaufträgen, Snapshots oder Sicherungsrepositorys.
• Massendownload oder -upload zu unbekanntem Cloud-Speicher.
• Ausgehende Verbindungen zu bekannter bösartiger Infrastruktur (Threat-Intelligence-Treffer).
• Audit-Protokollierung auf einem kritischen System deaktiviert.

Ordnen Sie jeden Use-Case den erforderlichen Protokollquellen zu und dokumentieren Sie, welche Sie heute bereits erkennen können. Diese Lückenanalyse ist Ihr wertvollstes Dokument.

Schritt 3: Protokollquellen priorisieren

Arbeiten Sie in Ebenen. Tier-1-Quellen sind dort, wo die meisten Angriffe sichtbar werden, und sind in der Regel kostengünstig zu erfassen. Tier-2-Quellen bieten zusätzliche Tiefe für kritische Dienste.

Bereich	Tier 1 (hier beginnen)	Tier 2 (für kritische Dienste hinzufügen)
Identität	Entra ID oder andere IdP-Anmeldungen und Audit-Protokolle, Active-Directory-Sicherheitsereignisse, MFA-Ereignisse	Sitzungen der privilegierten Zugriffsverwaltung, Dienstkontennutzung
Endpunkte und Server	EDR-Warnungen und Telemetrie, Windows-Sicherheits- und PowerShell-Protokolle auf Servern	Sysmon oder gleichwertige detaillierte Telemetrie, Linux-Audit-Protokolle
Cloud und SaaS	Microsoft-365- oder Google-Workspace-Audit-Protokolle, Cloud-Control-Plane-Protokolle (AWS CloudTrail, Azure Activity, GCP Audit)	Speicherzugriffsprotokolle, Key-Vault-Zugriff, SaaS-Admin-Protokolle für geschäftskritische Apps
Netzwerk	Firewall-Zulassungs- und Ablehnungsprotokolle, VPN und Fernzugriff, DNS-Abfragen	Proxy-Protokolle, NetFlow, Netzwerkerkennung und -reaktion, OT-Netzwerküberwachung
Kritische Anwendungen	Admin-Aktionen, Authentifizierung, Konfigurationsänderungen	Geschäftstransaktionen mit Betrugsbezug, Datenbankaudit
Sicherheits- und Sicherungswerkzeuge	Änderungen und Fehler in der Backup-Konsole, E-Mail-Sicherheitswarnungen, Feststellungen des Schwachstellenscanners	Datenverlustprävention, Täuschungswerkzeuge

Schritt 4: Aufbewahrung, Integrität und Zeitsynchronisierung festlegen

Weder NIS2 noch die Durchführungsverordnung legen eine bestimmte Anzahl von Monaten für die Protokollaufbewahrung fest. Die Anforderung ist ein vordefinierter, begründeter Zeitraum. Stützen Sie ihn darauf, wie lange Angreifer in Ihrer Umgebung typischerweise unentdeckt bleiben, auf Aufbewahrungspflichten und Ermittlungsbedarfe sowie auf branchenspezifische Regeln. Ein gängiges Konzept ist ein „heißer" Zeitraum, der schnell durchsucht werden kann, und ein kostengünstigeres Archiv für den Rest des Zeitraums. Dokumentieren Sie die Begründung.

• Schützen Sie Protokolle vor Änderung und Löschung: separate Speicherung, eingeschränkte Admin-Rechte, Unveränderbarkeit, wo verfügbar.
• Überwachen Sie die Protokollierungspipeline selbst: Warnung, wenn eine Quelle verstummt.
• Synchronisieren Sie alle Systeme mit einer dokumentierten zuverlässigen Zeitquelle (NTP von einer vertrauenswürdigen internen oder nationalen Quelle) und protokollieren Sie in UTC oder mit Zeitzoneninformationen.

Schritt 5: Wählen Sie Ihr Betriebsmodell: In-House, SOC-Service oder MDR

Die Frage ist, wer die Warnmeldungen um 3 Uhr morgens überwacht und wer die Befugnis zum Handeln hat.

Modell	Was Sie erhalten	Geeignet für	Achten Sie auf
In-House-SOC	Vollständige Kontrolle, tiefes Verständnis Ihrer Umgebung	Große Organisationen mit Budget für 24/7-Besetzung	Eine 24/7-Schicht erfordert mehrere Analysten; Schlüsselpersonenrisiko
Ausgelagertes SOC / verwaltetes SIEM	Der Anbieter überwacht Ihr SIEM und eskaliert Warnmeldungen	Organisationen, die die Plattform und Daten selbst besitzen möchten	Eskalation ohne Reaktion: Jemand im Haus muss dennoch handeln
MDR	Der Anbieter überwacht hauptsächlich EDR- und Identity-Telemetrie und kann Maßnahmen einleiten (einen Host isolieren, ein Konto deaktivieren)	Kleine und mittlere Organisationen	Umfang begrenzt auf die Tools des Anbieters; bestätigen Sie, welche Protokolle abgedeckt sind und wer über die Eindämmung entscheidet
Hybrid	MDR für 24/7-Abdeckung, In-House-Team für Anwendungsfälle und Untersuchungen	Wachsende Organisationen	Klare Aufgabenteilung in einer RACI

Unabhängig von Ihrer Wahl ist der Anbieter ein IKT-Lieferant und unterliegt Ihren Supply-Chain-Maßnahmen. Verträge sollten Service-Level für Triage und Eskalation, Eindämmungsbefugnis, Dateneigentum und Rückgabe bei Beendigung, Datenspeicherort und Unterstützung für Ihre Meldungsfristen für Vorfälle abdecken.

Schritt 6: EU-Datenspeicherort und Mitarbeiterüberwachung adressieren

Sicherheitsprotokolle enthalten Benutzernamen, IP-Adressen, Gerätebezeichner und manchmal Nachrichtenmetadaten, daher gilt die DSGVO vollständig. Nach Kapitel V der DSGVO erfordern Übermittlungen von personenbezogenen Daten außerhalb des EWR eine Rechtsgrundlage wie einen Angemessenheitsbeschluss oder angemessene Garantien^[7]. Der Fernzugriff auf in der EU gespeicherte Protokolle durch Analysten in einem Drittland kann auch eine Übermittlung darstellen.

• Fragen Sie, wo Protokolle gespeichert, verarbeitet und gesichert werden und wo SOC-Analysten arbeiten.
• Bevorzugen Sie eine EU-Region für das SIEM und die Analysetools des Anbieters, und überprüfen Sie die Unterauftragsverarbeiter des Anbieters.
• Dokumentieren Sie eine Datenschutz-Folgenabschätzung, wenn die Überwachung umfangreich oder systematisch ist.
• Beachten Sie nationale Regeln zur Mitarbeiterüberwachung: In Belgien das Kollektivarbeitsabkommen Nr. 81 zur Überwachung elektronischer Online-Kommunikation; in den Niederlanden das Zustimmungsrecht des Betriebsrats nach Artikel 27 des Betriebsrätegesetzes (Wet op de ondernemingsraden); in Luxemburg die Arbeitsgesetzbuchbestimmungen zur Arbeitsplatzüberwachung.

Schritt 7: Definieren Sie Warnmeldungs-Triage und Eskalation

Ein Alert, den niemand bearbeitet, ist ein Nachweis gegen Sie. Definieren Sie Schweregrade, Reaktionszeiten und Zuständigkeiten, und verknüpfen Sie hochkritische Alerts mit Ihrem Incident-Response-Plan und Ihrer NIS2-Meldungsentscheidung.

• Schweregrade mit Zielzeiten für Bestätigung und Eskalation (beispielsweise kritische Alerts innerhalb von 30 Minuten bestätigt, 24/7).
• Triage-Schritte pro Anwendungsfall: was zu prüfen ist, wann als Fehlalarm zu schließen ist, wann zu eskalieren ist.
• Eskalationskette mit benannten Personen und Vertretern, auch außerhalb der Geschäftszeiten.
• Ein klarer Punkt, an dem ein Alert zu einem Vorfall wird und die 24-Stunden-Frist für die Frühwarnung gemäß Artikel 23 NIS2 beginnen kann^[1].

Schritt 8: Nachweis, dass die Erkennung funktioniert

Hier scheitern die meisten Organisationen. Ein bescheidenes, getestetes und sich verbesserndes System ist überzeugender als ein teures, das niemand erklären kann. Das CyFun 2025-Rahmenwerk ist mit dem NIST CSF 2.0 abgestimmt und folgt dessen Struktur, einschließlich der Detect-Funktion^[6].

• Testen Sie jeden prioritären Anwendungsfall mindestens jährlich mit einer sicheren Simulation (erstellen Sie eine Test-Weiterleitungsregel, fügen Sie ein Test-Konto zu einer Admin-Gruppe hinzu, führen Sie ein ungefährliches Angriffssimulations-Tool aus) und dokumentieren Sie, ob der Alert ausgelöst wurde und rechtzeitig bearbeitet wurde.
• Abdeckungsbericht: Prozentsatz kritischer Systeme, die Logs senden, Prozentsatz prioritärer Anwendungsfälle, die in den letzten 12 Monaten getestet wurden, durchschnittliche Zeit bis Bestätigung und Eskalation.
• Beziehen Sie die Erkennung in Ihre Tabletop-Übungen ein; der Handlungsleitfaden für Tabletop-Übungen zeigt wie.

In Secrato können das Log-Quellen-Register und das Anwendungsfall-Register als Nachweise an die Monitoring-Kontrollen in der Compliance Engine angehängt werden, sodass ein einzelnes Testergebnis gleichzeitig NIS2, CyFun, ISO/IEC 27001 und DORA unterstützt.

Die Begleitvorlage enthält ein Log-Quellen-Register, ein Erkennungs-Anwendungsfall-Register mit 30 vorausgefüllten Anwendungsfällen und ein Erkennungs-Testprotokoll.

Wie dies mit anderen Rahmenwerken verbunden ist

ISO/IEC 27001:2022 Anhang A behandelt Logging (8.15), Überwachungsaktivitäten (8.16) und Zeitsynchronisation (8.17); dasselbe Register dokumentiert alle drei. In NIST CSF 2.0 und CyFun liegt diese Arbeit in der Detect-Funktion. Nach DORA machen Artikel 10 und die Delegierte Verordnung Erkennungstests explizit. Das Register, das Sie einmal aufbauen, dient allen.

Häufig gestellte Fragen

Benötigen wir ein SIEM, um NIS2-konform zu sein?

Kein Gesetz nennt ein bestimmtes Produkt. Sie müssen relevante Logs erfassen, verdächtige Aktivitäten erkennen und zeitnah reagieren. Eine kleine Organisation kann das mit einem MDR-Service auf Endpunkten und Identität plus zentralisierten Cloud-Audit-Logs erfüllen. Größere oder komplexere Unternehmen benötigen normalerweise ein SIEM, um Quellen zu korrelieren.

Wie lange sollten wir Sicherheitslogs aufbewahren?

Es gibt keine einheitliche EU-weite Vorgabe unter NIS2. Wählen Sie einen Zeitraum, der es Ihnen ermöglicht, spät entdeckte Vorfälle zu untersuchen, begründen Sie ihn schriftlich und prüfen Sie Sektorregeln und Verträge. Bewahren Sie personenbezogene Daten nicht länger auf, als dieser Zweck erfordert.

Ist 24/7-Überwachung verpflichtend?

NIS2 sieht dies nicht explizit vor. Die Delegierte Verordnung von DORA verlangt, dass Warnungen für kritische oder wichtige Funktionen während und außerhalb der Arbeitszeiten bearbeitet werden. Für Unternehmen mit kritischen Diensten ist eine Abdeckung außerhalb der Geschäftszeiten eine praktische Notwendigkeit.