SIEM für NIS2: Welche Erkennung die Richtlinie wirklich verlangt

Ein bestimmtes SIEM-Produkt ist nicht vorgeschrieben.

Daraus folgt aber keine Freiheit von technischen Anforderungen: NIS2 nennt beispielsweise kryptografische Verfahren und Mehrfaktor-Authentifizierung. In Deutschland verlangt § 31 Absatz 2 BSIG für die maßgeblichen Systeme kritischer Anlagen ausdrücklich Systeme zur Angriffserkennung. Für bestimmte digitale Dienstleister konkretisiert die Verordnung (EU) 2024/2690 die Überwachung und Protokollierung. Welche Architektur geeignet ist, hängt deshalb von Einrichtungsart, Risiken und anwendbaren Anforderungen ab. Ausnahmen nach § 28 BSIG, insbesondere für bestimmte Finanzunternehmen sowie Energie- und Telekommunikationstätigkeiten, sind vor der Zuordnung zu prüfen.

Protokolle können insbesondere die Vorfallbehandlung, die Kontrolle von Zugriffen und die Wirksamkeitsprüfung von Sicherheitsmaßnahmen unterstützen.

Artikel 21 Absatz 2 enthält jedoch kein Schema, nach dem genau sechs Maßnahmen ausschließlich durch ein zentrales SIEM nachweisbar wären. Entscheidend sind geeignete und nachvollziehbare Nachweise für die jeweilige Maßnahme. Ergänzend bleiben beispielsweise Risikobewertungen, Wiederherstellungstests, Schulungsnachweise und Managemententscheidungen erforderlich. Die konkrete Ausgestaltung richtet sich nach Risiken, Einrichtungsart und anwendbaren Regeln.

Artikel 23 Absatz 4 setzt drei Stufen.

Innerhalb von 24 Stunden nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls ist eine Frühwarnung abzugeben, in der auch anzugeben ist, ob ein Verdacht auf rechtswidrige Handlungen oder auf grenzüberschreitende Auswirkungen besteht. Innerhalb von 72 Stunden folgt die Meldung des Sicherheitsvorfalls mit einer ersten Bewertung von Schweregrad und Auswirkungen. Spätestens einen Monat nach dieser Meldung ist der Abschlussbericht vorzulegen. Dauert der Vorfall noch an, tritt zunächst ein Fortschrittsbericht an dessen Stelle. Die Meldungen sind unverzüglich abzugeben; die Stundenangaben sind Höchstfristen. Für Vertrauensdiensteanbieter sieht Artikel 23 Absatz 4 für die Vorfallmeldung eine besondere 24-Stunden-Frist vor. Maßgeblich bleiben die anwendbare nationale Umsetzung und Sonderregeln.

Nach § 33 Absatz 1 BSIG müssen sich besonders wichtige und wichtige Einrichtungen sowie Domain-Name-Registry-Dienstleister spätestens drei Monate nach erstmaliger oder erneuter Erfüllung der dort genannten Voraussetzungen registrieren.

Die Frist hängt damit vom jeweiligen Eintritt der Voraussetzungen ab. Absatz 6 regelt die Festlegung des Verfahrens durch das BSI. Eine verspätete Registrierung sollte nachgeholt werden; sie ersetzt weder die Umsetzung noch den Nachweis der Sicherheitsmaßnahmen. Für kritische Anlagen verweist Absatz 2 auf § 8 KRITIS-Dachgesetz.

NIS2 erweitert den Kreis regulierter Einrichtungen und stärkt die Anforderungen an Risikomanagement, Vorfallbehandlung und Nachweise.

Für ein SIEM-Projekt ist zuerst zu klären, welche Einrichtung und welche Systeme erfasst sind. Log-Quellen, Regeln und Eskalationswege folgen den Risiken und anwendbaren Anforderungen. Die 24-Stunden-Frist ist keine allgemeine Frist zur Erkennung jedes Angriffs: § 32 BSIG knüpft die frühe Erstmeldung an die Kenntniserlangung von einem erheblichen Sicherheitsvorfall. Ein SIEM unterstützt die Bewertung; es ersetzt weder die rechtliche Einordnung noch die organisatorische Verantwortung.

Beginnen Sie mit einem relevanten Angriffsszenario und den dafür verfügbaren Daten, nicht mit einer pauschalen Liste angeblich vorgeschriebener SIEM-Regeln. Prüfen Sie Identitätsanbieter, privilegierte Konten, Fernzugänge, Endpunkte, Netzwerkübergänge und kritische Anwendungen nach Risiko und Geschäftsrelevanz. Pro Quelle werden mindestens Herkunft, Zeitstempel, betroffene Identität bzw. Ressource, Aktion und Ergebnis benötigt, soweit die Quelle diese Daten bereitstellt. Kontrollieren Sie Parsing, Zeitbezug und ausbleibende Ereignisse.

Redaktionelles Testbeispiel, kein Kundenfall: In einer freigegebenen Testumgebung wird nach mehreren fehlgeschlagenen Anmeldungen eine erfolgreiche Anmeldung eines Test-Administrators mit anschließender Rechteänderung erzeugt. Die Regel verknüpft Identität, System und ein begründetes Zeitfenster. Eine bekannte administrative Wartung wird als Gegenprobe verwendet. Das zuständige Team bewertet den Alarm anhand von Änderungsfreigabe, Konto und betroffenem Dienst; eine Anomalie allein beweist keinen Angriff.

Der Testnachweis enthält Quellereignisse, Regelversion, erwartetes und tatsächliches Ergebnis, Alarm- und Bearbeitungszeit, Entscheidung, Verantwortlichen und offene Fehler. Fehlt der Alarm oder funktioniert die Gegenprobe nicht, wird die Regel korrigiert und erneut geprüft. Auswirkungen auf Dienste, Nutzer und Daten fließen anschließend in die Bewertung eines erheblichen Sicherheitsvorfalls ein. Ein SIEM-Score ersetzt diese Bewertung und die dokumentierte Meldeentscheidung nicht.

Lieferkettensicherheit umfasst die Zusammenarbeit mit unmittelbaren Anbietern und Dienstleistern; ein SIEM kann nur die technisch verfügbaren und zulässig erhobenen Ereignisse auswerten. Priorisieren Sie kritische Abhängigkeiten und privilegierte Lieferantenzugänge. Geeignete Quellen sind beispielsweise VPN- und Identitätsprotokolle, administrative Änderungen, API-Zugriffe und vom Cloud-Dienst bereitgestellte Audit-Logs. Prüfen Sie ungewöhnliche Anmeldezeiten, neue Berechtigungen, unerwartete Datenübertragungen und ausgefallene Log-Lieferungen.

Vereinbaren Sie mit dem Lieferanten Datenzugang, zulässige Nutzung, Aufbewahrung, Benachrichtigung und Ansprechpartner. Testen Sie einen verdächtigen Drittanbieterzugriff einschließlich Eskalation und Rückmeldung. Zertifikats- oder Zugriffsalarme sind einzelne Signale; sie belegen weder die vollständige Sicherheitslage noch die Konformität eines Lieferanten. Dafür bleiben Lieferantenbewertung, Vertragsprüfung und geeignete Nachweise erforderlich.

Ordnen Sie zuerst Einrichtung, kritische Dienste, Systeme und anwendbare Pflichten zu. Ein Asset-Verzeichnis, Bedrohungsszenarien, Schwachstellen und eine fachlich verantwortete Bewertung der Geschäftsauswirkungen bilden die Grundlage. Das SIEM liefert Ereignisse und Kontext; es erstellt weder automatisch eine vollständige Business-Impact-Analyse noch eine rechtlich abschließende Risikobewertung.

Verknüpfen Sie jedes priorisierte Risiko mit einer Erkennungsmaßnahme, einer zuständigen Rolle und einem Wirksamkeitstest. Beispiel: Ein kompromittiertes Administratorkonto wird mit Identitäts- und Änderungsprotokollen überwacht; fehlende Quellen werden als Restrisiko dokumentiert. Maßnahmen, Fristen und Risikoakzeptanz gehören in das Risikoregister. Änderungen an Diensten, Bedrohungen oder Lieferanten lösen eine erneute Prüfung aus. Regelmäßige Managemententscheidungen und nachvollziehbare Nachweise verbinden den technischen Betrieb mit der Governance.

Die wesentlichen Herausforderungen sind unklare Zuständigkeiten, zu viele Fehlalarme, fehlender Geschäftskontext und eine ungeübte Meldekette. Definieren Sie, wer Alarme prüft, Auswirkungen bewertet, Maßnahmen freigibt und gegebenenfalls meldet. Legen Sie Betriebszeiten, Vertretung und Eskalation auch außerhalb der Regelarbeitszeit risikogerecht fest.

Ein Playbook sollte vom Quellereignis über die Triage und Beweissicherung zur fachlichen Entscheidung führen. Eine automatische Benachrichtigung ist noch keine bestätigte Bearbeitung. Testen Sie deshalb auch ausbleibende Rückmeldungen, nicht erreichbare Ansprechpartner und die Übergabe an externe Dienstleister. Dokumentieren Sie Ereigniszeit, Erkennung, Kenntniserlangung eines erheblichen Vorfalls und Meldung getrennt. Automatisierte Eindämmung braucht definierte Freigaben und Rückfallmöglichkeiten, insbesondere bei kritischen Diensten. Aus Übungen und echten Vorfällen abgeleitete Verbesserungen werden nachverfolgt und erneut getestet.

Benennen Sie Verantwortliche für Maßnahmenfreigabe, SIEM-Betrieb, Vorfallbewertung, Meldung und Risikoakzeptanz. Geschäftsleitung und fachliche Verantwortliche benötigen eine verständliche Übersicht über abgedeckte Risiken, fehlende Erkennungsfähigkeiten, Testergebnisse und überfällige Maßnahmen. Das SIEM liefert dazu technische Daten; Beschlüsse und Verantwortlichkeiten werden im dafür vorgesehenen Governance-Prozess dokumentiert.

Ein Managementbericht sollte kritische Log-Ausfälle, bestätigte Vorfälle, Bearbeitungszeiten, Ergebnisse von Erkennungstests und offene Restrisiken enthalten. Erläutern Sie Definition und Grenzen jeder Kennzahl. Ein Dashboard mit grünen Anzeigen ist kein vollständiger NIS2-Nachweis. Prüfen Sie regelmäßig, ob Entscheidungen umgesetzt wurden und ob Vertretungen, Eskalationswege und Schulungen funktionieren. Ein zusätzliches Gremium oder eine bestimmte Dashboard-Technologie ist nicht allein aufgrund von NIS2 für jedes Unternehmen vorgeschrieben.

Es gibt keine universell optimale NIS2-SIEM-Architektur. Vergleichen Sie On-Premises-, Cloud- und Hybridbetrieb anhand von Datenzugang, Schutzbedarf, Betriebsfähigkeit, Integrationen und Gesamtkosten. Benötigte Bausteine sind geeignete Log-Quellen und Collector, verlässliche Übertragung, Normalisierung, Auswertung, geschützter Speicher und ein funktionierender Alarmierungsweg. Microservices, Serverless und Multi-Tenant-Design sind mögliche Architekturentscheidungen, keine allgemeinen NIS2-Pflichten.

Prüfen Sie Pufferung bei Verbindungsunterbrechungen, Uhrensynchronisierung, Zugriffsrechte, Integritätsschutz und die Überwachung der Logging-Infrastruktur selbst. Aufbewahrungsfristen werden nach Zweck, Risiko und anwendbaren rechtlichen Anforderungen festgelegt; eine pauschale Dauer gilt nicht für alle. Testen Sie Wiederauffindbarkeit, Export und Wiederherstellung relevanter Ereignisse. Ein System, das Daten empfängt, aber bei Lastspitzen Ereignisse verliert oder keine zuständige Person erreicht, hat den Erkennungsprozess noch nicht bestanden.

Trennen Sie rechtliche Einordnung und technische Sektorbesonderheiten. In Deutschland enthält § 28 BSIG Ausnahmen und Abgrenzungen, etwa für bestimmte Finanzunternehmen sowie Energie- und Telekommunikationstätigkeiten. Für die in § 28 Absatz 6 Nummer 1 genannten Finanzunternehmen gelten die dort aufgeführten BSIG-Pflichten nicht; DORA-Anforderungen sind gesondert einzuordnen. Für bestimmte digitale Dienstleister ist die Verordnung (EU) 2024/2690 maßgeblich. Ein gemeinsamer SIEM-Anwendungsfall macht die Rechtsgrundlagen nicht austauschbar.

Technisch können in Energie und Wasser OT-Fernzugriffe, Änderungen an Steuerungen und Netzwerkübergänge relevant sein; im Gesundheitswesen etwa Identitäten, sensible Daten und die Verfügbarkeit klinischer Dienste. Quellen und Tests müssen zum Betrieb passen und dürfen kritische Prozesse nicht gefährden. Umweltqualität, öffentliche Gesundheit oder regulatorische Gesamtkonformität werden nicht allein durch SIEM-Logs überwacht oder bewiesen.

Definieren Sie zunächst, welche Bedrohungen für Ihre Dienste relevant sind. Nutzen Sie passende behördliche, branchenspezifische, offene oder kommerzielle Quellen und dokumentieren Sie Herkunft, Aktualität, Vertrauensniveau und Nutzungsbedingungen. Technische Indikatoren wie IP-Adressen oder Dateihashes werden mit internen Ereignissen und dem Geschäftskontext abgeglichen.

Testen Sie, ob ein Feed tatsächlich verwertbare Erkennungen liefert. Veraltete Indikatoren, gemeinsame Cloud-Infrastruktur und unpassende Regeln können Fehlalarme erzeugen. Legen Sie Ablaufzeiten, Pflegeverantwortung und Rückmeldung aus der Triage fest. Strategische Lagebilder und technische Erkennungsregeln erfüllen unterschiedliche Zwecke. Ein Treffer ist kein gesicherter Nachweis für eine bestimmte Angreifergruppe; maschinelles Lernen oder ein kommerzieller Feed kann weder zukünftige Angriffe zuverlässig vorhersagen noch die NIS2-Konformität garantieren.

Erfassen Sie vorhandene Schnittstellen, Protokolle, Schutzbedarf und Einschränkungen jedes Legacy-Systems. Manche Geräte erlauben keinen Agenten oder liefern unvollständige Zeitstempel. Prüfen Sie verfügbare Systemprotokolle, vorgelagerte Identitäts- und Fernzugänge sowie geeignete passive Netzwerksensoren. Ein SIEM inventarisiert nicht automatisch jedes Gerät und entwickelt keine fehlenden Anwendungsschnittstellen.

Testen Sie die Erfassung unter realistischen, freigegebenen Betriebsbedingungen. Bei Produktions- oder OT-Systemen müssen Änderungen und Last durch zusätzliche Protokollierung vorab mit dem Betreiber abgestimmt werden. Dokumentieren Sie Datenlücken, ergänzende Kontrollen, Verantwortliche und Modernisierungsmaßnahmen. Pufferung, Übertragungsschutz und Parserpflege gehören zum Betrieb. Wo direkte Sichtbarkeit fehlt, sind kompensierende Kontrollen zu begründen; sie dürfen nicht als vollständige Überwachung ausgegeben werden.

Leiten Sie Wiederanlaufziele aus einer fachlich verantworteten Business-Impact-Analyse ab. Das SIEM kann Hinweise auf Backup-Fehler, ungewöhnliche administrative Änderungen oder Angriffe auf Wiederherstellungssysteme liefern, sofern entsprechende Quellen angebunden sind. Es berechnet nicht automatisch belastbare RTO/RPO-Ziele und beweist mit einer erfolgreichen Backup-Meldung keine Wiederherstellbarkeit.

Testen Sie die Wiederherstellung getrennt und dokumentieren Sie Datenstand, Dauer, Abhängigkeiten und Abweichungen. Prüfen Sie außerdem, wie Erkennung und Alarmierung bei Ausfall des SIEM, eines Collectors oder einer Verbindung weiterlaufen. Notfallkontakte, alternative Kommunikationswege und die Übergabe an das Krisenteam gehören in den Prozess. Erkenntnisse aus Übungen führen zu konkreten Maßnahmen und erneuten Tests.

Planen Sie Schulungen nach Rolle: Analysten üben Triage und Beweissicherung, Administratoren Log-Quellen und Änderungen, Verantwortliche die Bewertung und Meldung von Vorfällen. Die Geschäftsleitung benötigt das für ihre Aufgaben erforderliche Verständnis von Risiken, Maßnahmen und Nachweisen. Ein SIEM kann Übungsereignisse liefern, aber nicht automatisch die Kompetenz aller Beschäftigten feststellen.

Verwenden Sie freigegebene Testdaten und ein realistisches Szenario mit unvollständigen Informationen. Prüfen Sie, ob die Beteiligten den Alarm verstehen, Zuständigkeiten kennen, Entscheidungen dokumentieren und die Eskalation auslösen können. Halten Sie Lernziele, Teilnahme, beobachtete Schwierigkeiten und Folgemaßnahmen fest. Eine absolvierte Schulung und eine erfolgreich bearbeitete Übung sind unterschiedliche Nachweise; beides ersetzt nicht den funktionierenden Betrieb.

Pflegen Sie einen nachvollziehbaren Lebenszyklus für Quellen, Regeln und Playbooks. Änderungen an Diensten, Identitäten, Bedrohungen oder Rechtsgrundlagen können neue Anforderungen auslösen. Benennen Sie Verantwortliche für die Bewertung und dokumentieren Sie, welche Regeln angepasst, getestet oder außer Betrieb genommen werden.

Offene Schnittstellen, exportierbare Daten, versionierte Konfiguration und getestete Wiederherstellung erleichtern spätere Anpassungen. Prüfen Sie Kapazität, Supportlaufzeiten und Anbieterabhängigkeiten regelmäßig. KI, Blockchain oder immersive Trainings sind keine pauschalen NIS2-Voraussetzungen. Neue Technik wird anhand eines konkreten Nutzens und ihrer Risiken bewertet. Ein SIEM antizipiert Gesetzesänderungen nicht automatisch; die fachliche Prüfung und Freigabe müssen organisatorisch sichergestellt werden.

Nutzen Sie Kennzahlen mit klarer Definition und Datenbasis. Sinnvoll sind die Abdeckung priorisierter Log-Quellen, Datenlieferungsausfälle, Verarbeitungsverzug, Ergebnisse definierter Erkennungstests sowie Zeit bis Triage und Bearbeitung. Bei Erkennungszeiten muss bekannt sein, ab welchem Ereignis gemessen wird; der tatsächliche Angriffsbeginn ist im Echtbetrieb nicht immer bestimmbar.

Unterscheiden Sie Fehlalarme, übersehene Testereignisse und noch nicht bewertete Alarme. Zeigen Sie Fallzahl, Zeitraum, Schweregrad und offene Ausnahmen statt nur eines Durchschnitts. Für Meldungen dokumentieren Sie Kenntniserlangung, Bewertung, Freigabe und Versand. Ein automatischer NIS2-Gesamtscore oder Audit-Readiness-Index ist ohne belegte Prüfkriterien kein Konformitätsnachweis. Technische Testergebnisse, organisatorische Nachweise und rechtliche Bewertung bleiben getrennt.

Planen Sie Änderungen gemeinsam mit Systemverantwortlichen, Betrieb und Incident Response. Dokumentieren Sie Zweck, betroffene Quellen und Regeln, Risiken, Freigabe, Wartungsfenster und Rückfallplan. Rollen, Kommunikation und Schulung sind organisatorische Aufgaben; ein SIEM erkennt weder Widerstände im Unternehmen noch garantiert es einen unterbrechungsfreien Rollout.

Führen Sie Änderungen schrittweise ein und testen Sie sowohl die gewünschte Erkennung als auch bekannte unkritische Aktivitäten. Kontrollieren Sie Datenvolumen, Last, Alarmqualität und Erreichbarkeit der zuständigen Personen. Bei Fehlern muss die vorherige Konfiguration nachvollziehbar wiederherstellbar sein. Erst nach dokumentierter Abnahme und Übergabe in den Betrieb gilt die technische Änderung als abgeschlossen; ein erfolgreiches Deployment allein genügt nicht.

Vergleichen Sie die Gesamtkosten aus Lizenzen, Datenaufnahme, Speicherung, Anbindungen, Regelpflege, Analystenzeit, Bereitschaft, Schulung und Wirksamkeitstests. Messen Sie typische und maximale Datenmengen sowie benötigte Abfragegeschwindigkeit. Preisvergleiche sind nur bei vergleichbarem Umfang und Betriebsmodell sinnvoll.

Priorisieren Sie risikorelevante Quellen und Erkennungsfälle. Vermeiden Sie unnötige Duplikate und stimmen Sie Speicherebenen auf begründete Aufbewahrungs- und Zugriffsanforderungen ab. Kürzen Sie sicherheitsrelevante Daten nicht pauschal, um eine Lizenzschwelle zu unterschreiten. Automatisierung lohnt sich, wenn ein getesteter Ablauf tatsächlich Bearbeitungszeit spart und kontrollierbar bleibt. Für die Bestandsaufnahme sind vorhandene Quellen, Datenvolumen, Betriebszeiten und bekannte Lücken hilfreicher als ein unbelegter Pauschalpreis. Umfang und Aufwand werden anschließend projektspezifisch geklärt.

Ein gut betriebenes SIEM kann Untersuchungen beschleunigen, wiederkehrende Angriffsmuster sichtbar machen und die Zusammenarbeit zwischen IT, Sicherheit und Fachbereichen verbessern. Der Nutzen entsteht aus verwertbaren Daten, passenden Regeln und einer tatsächlich bearbeiteten Alarmkette, nicht aus der Installation allein.

Bewerten Sie Verbesserungen anhand vergleichbarer Erkennungstests, Bearbeitungsaufwände und dokumentierter Vorfälle. Eine neue Cloud-Anbindung kann beispielsweise früher auf Fehlkonfigurationen oder auffällige Zugriffe geprüft werden, wenn geeignete Audit-Logs vorliegen. Kundenvertrauen, neue Geschäftsmöglichkeiten und wirtschaftlicher Nutzen sind mögliche Folgewirkungen, keine garantierten SIEM-Ergebnisse. Verwenden Sie solche Aussagen nur mit passenden Nachweisen und offen gelegten Grenzen.

Bewerten Sie SIEM- und Betriebsdienstleister anhand benötigter Integrationen, Datenzugang, Support, Reaktionsabdeckung, Sicherheitsnachweisen und Wechselmöglichkeiten. Wirtschaftliche Stabilität und Vertragsrisiken werden außerhalb des SIEM geprüft. Das SIEM kann betriebliche Ereignisse liefern, aber weder finanzielle Tragfähigkeit noch vollständige regulatorische Konformität eines Anbieters automatisch bestätigen.

Vereinbaren Sie Zuständigkeiten, Eskalation, Datenverarbeitung, Unterauftragnehmer, Log-Export, Aufbewahrung und Unterstützung bei Vorfällen. Prüfen Sie Service-Level anhand vereinbarter Messpunkte und konkreter Fälle. Testen Sie die Zusammenarbeit einschließlich ausbleibender Rückmeldung und einer Datenübergabe beim Anbieterwechsel. Zertifikate und Prüfberichte müssen zum beauftragten Leistungsumfang passen; ihr Vorhandensein allein ersetzt keine Risikobewertung.

KI kann die Gruppierung ähnlicher Alarme, Verhaltensanalysen und die Zusammenfassung von Untersuchungsdaten unterstützen. Ob sie im eigenen Umfeld besser funktioniert, muss anhand geeigneter Testfälle, Fehlalarme, übersehener Ereignisse und Analystenaufwand geprüft werden. Eine plausible Zusammenfassung ist kein gesicherter Befund.

Prüfen Sie Datenzugriff, Schutz vertraulicher Logs, Nachvollziehbarkeit, Modelländerungen und menschliche Freigaben. Gerade automatische Eingriffe in kritische Systeme benötigen begrenzte Berechtigungen, getestete Rückfallwege und definierte Verantwortlichkeiten. Beginnen Sie mit klar abgegrenzten Assistenzaufgaben. KI sagt weder zukünftige Angriffe zuverlässig voraus noch bescheinigt sie NIS2-Konformität. Behalten Sie überprüfbare Regeln und einen funktionsfähigen Prozess auch für den Ausfall oder eine Fehlentscheidung des Modells bei.