NIS-2 als Architekturaufgabe (2): Asset-Transparenz als Fundament der NIS-2-Umsetzung: Sehen, bevor man handeln kann

Ein produzierendes Unternehmen mit 450 Mitarbeitern, vollständig dokumentiertem Informationssicherheits-Managementsystem (ISMS) und formal gepflegter Systemübersicht entdeckt im Zuge einer automatisierten Inventarisierung mehr als dreimal so viele Assets wie bislang angenommen.

Die Differenz besteht nicht aus Phantomgeräten, sondern aus OT-Systemen, die nie in die CMDB aufgenommen wurden, aus Cloud-Instanzen, die Fachbereiche ohne Beteiligung der IT eingerichtet haben, und aus veralteten Servern, die über VPN weiterhin erreichbar sind. Für einige dieser Systeme scheint sich längst niemand mehr verantwortlich zu fühlen, im Netzwerk vorhanden sind sie trotzdem. In vielen Organisationen ist das eher die Regel als die Ausnahme.

Die größte Schwachstelle vieler Unternehmen ist heute nicht fehlende Sicherheitstechnik, sondern fehlende Transparenz darüber, welche Systeme tatsächlich betrieben werden.

Asset-Transparenz bildet das Fundament des Referenzmodells dieser Artikelserie. Ohne ein lückenloses und dynamisches Inventar über IT, OT und Cloud bleiben auch die vier weiteren Dimensionen unvollständig: Angriffserkennung (Dimension 2), Incident Response (Dimension 3), Identity (Dimension 4) und Supply Chain (Dimension 5) setzen allesamt voraus, dass der Gegenstand ihrer Wirkung bekannt ist.

Das Ziel technischer Architektur ist nicht nur die Schutzwirkung, sondern auch die technische Nachvollziehbarkeit gegenüber Betrieb, Audit und Aufsicht. Ein Inventar, das die reale Infrastruktur nicht vollständig abbildet, macht jeden späteren Nachweis lückenhaft, noch bevor er überhaupt geführt wird.

Angreifer finden, was das eigene Inventar nicht kennt

Art. 21 Abs. 2 lit. a der NIS-2-Richtlinie – im deutschen Recht durch § 30 BSI-Gesetz (BSIG) konkretisiert – verpflichtet Unternehmen zu Risikoanalysen und Sicherheitskonzepten für ihre Informationssysteme. Die Pflichten aus § 30 BSIG gelten für Einrichtungen, die in den Anwendungsbereich des BSIG fallen, insbesondere besonders wichtige und wichtige Einrichtungen nach § 28 BSIG sowie gegebenenfalls Einrichtungen nach sektorspezifischen Sonderregelungen.

Was erst einmal nach einer Managementaufgabe klingt, hat eine handfeste technische Grundlage, denn eine Risikoanalyse setzt voraus, dass bekannt ist, was überhaupt zu schützen ist. Das klingt trivial, ist es aber nicht: Fußt die Analyse auf einer lückenhaften Asset-Basis, beschreibt sie eine Infrastruktur, die es so nicht gibt. Sie ist dann nicht falsch formuliert, sie beschreibt schlicht die falsche Realität.

Die Anforderung verknüpft sich unmittelbar mit weiteren Dimensionen des Art. 21 der NIS-2-Richtlinie: Incident Handling nach Art. 21 Abs. 2 lit. b NIS-2 sowie – für KRITIS-Betreiber – Systeme zur Angriffserkennung nach § 31 Abs. 2 BSIG benötigen ein vollständiges Bild der überwachten Infrastruktur. Lieferkettensicherheit (lit. d) beginnt damit, die eigenen Systemgrenzen und -Verknüpfungen mit externen Parteien vollständig zu kennen.

Asset-Transparenz ist damit keine isolierte Einzelanforderung. Sie ist die Grundlage, auf der alle anderen technischen Dimensionen aufbauen. Wer hier lückenhaft aufgestellt ist, schwächt damit alle nachgelagerten Maßnahmen – unabhängig davon, wie viel man in sein Security Information and Event Management (SIEM), Identity and Access Management (IAM) oder Incident Response investiert hat.

Hier zeigt sich auch die Unterscheidung zwischen Angemessenheits- und Wirksamkeitsprüfung in aller Schärfe: Während eine Angemessenheitsprüfung beurteilt, ob Maßnahmen konzipiert wurden, bewertet die Wirksamkeitsprüfung, ob diese nachweisbar den gewünschten Schutzeffekt erzielen. Ein dokumentiertes Inventarkonzept mag angemessen konzipiert sein – ob es die reale Infrastruktur tatsächlich vollständig erfasst, ist eine Frage der Wirksamkeit. Genau diese Frage stellt eine technische Prüfung.

Drei Welten, eine Angriffsfläche

Inventarlücken entstehen meist nicht aus mangelnder Sorgfalt. Verantwortlich ist die gewachsene Realität moderner Infrastrukturen: Drei Welten wachsen zusammen, jede mit eigener Verwaltungslogik, eigenen Zuständigkeiten und eigenen Sichtbarkeitsgrenzen.

• Die IT-Welt (verwaltet, aber unvollständig): IT-Infrastruktur wird von IT-Abteilungen verwaltet, erfasst und gepatcht. Sie ist in der Regel in der CMDB geführt. Die Datenqualität schwankt, die Grundlogik stimmt. Das ist die Infrastruktur, die jemand offiziell besitzt.
• Die OT-Welt (produktionsnäher, inventarferner): OT-Infrastruktur – Steuerungssysteme, Maschinenanbindungen, industrielle Netzwerksegmente – hat historisch getrennte Verantwortlichkeiten. Sie wird von Abteilungen wie Engineering oder Produktion betrieben. Die IT inventarisiert diese Bereiche selten. Technisch ist OT-Infrastruktur für Standard-Scan-Tools oft nicht zugänglich – oder zu empfindlich, um aktiv gescannt zu werden.
• Die Cloud-Welt(dynamisch, dezentral, oft unregistriert): Cloud-Ressourcen können schnell und ohne formalen Eingangsweg entstehen. Fachbereiche provisionieren Software-as-a-Service-(SaaS)-Dienste meist direkt. Entwicklungsteams erstellen gegebenenfalls Testumgebungen, die im Zweifel produktionsrelevant werden. Infrastructure-as-Code erzeugt Systeme, die im Asset-Management in der Regel nicht nachgewiesen werden müssen und daher auch keinen Eintrag haben. Was heute noch eine Sandbox ist, läuft im ungünstigsten Fall morgen im Betrieb – ohne dass es jemand formell übernommen hat, da kein Prozess definiert ist, aber auch kein Kontrollmechanismus vorhanden ist, der Alarm schlagen könnte.

Diese drei Welten sind heute vielerorts nicht mehr sauber getrennt. OT-Systeme haben Netzwerkanbindung. Cloud-Dienste verarbeiten Produktionsdaten. IT-Systeme greifen auf OT-Schnittstellen zu. Die Konvergenz erhöht die Angriffsfläche, ohne dass die Inventarprozesse mitgewachsen sind.

Die blinden Flecken

Neben der strukturellen Dreiteilung treten in der Praxis drei weitere Inventarlücken besonders häufig auf. Da ist zunächst die Schatten-IT, also Systeme außerhalb der formalen IT-Governance: kein Patching, kein Logging, keine Anbindung an zentrale Sicherheitssysteme. Als Risiko werden sie oft nicht wahrgenommen, weil sie niemand offiziell sieht.

Hinzu kommt der SaaS-Sprawl. Jede SaaS-Applikation, die ein Fachbereich direkt nutzt, ist ein potenzieller Datenabfluss, ein zusätzlicher Identitätspfad und eine neue Angriffsfläche, häufig ohne Single-Sign-on-(SSO)-Anbindung oder zentrales Identity-Management. Schließlich gibt es temporäre Systeme, etwa Test- und Projektumgebungen, die produktionsrelevant werden, ohne je formal übernommen zu werden. Sie laufen weiter, werden nicht abgebaut, erhalten keine Updates und sind dennoch netzwerkseitig erreichbar.

Allen drei Lücken ist eines gemeinsam: Es fehlt eine klare Zuständigkeit. Das rächt sich spätestens bei einer NIS-2-Prüfung oder einem Sicherheitsvorfall, wenn der Auditor fragt, wer für ein solches System eigentlich verantwortlich ist – und in ratlose Augen blickt.

Der Weg aus diesen blinden Flecken führt weg vom manuell gepflegten Inventar hin zu einer Architektur, die Assets fortlaufend selbst erfasst. Was das konkret bedeutet, zeigt die Gegenüberstellung von Ausgangszustand und Architektur in Tabelle 1.

The Stairway to Heaven

Der Weg von einem fragmentierten Inventar zu einer betreibbaren Asset-Transparenz folgt drei Schritten. Erst wenn alle drei greifen, entsteht technische Nachvollziehbarkeit – nicht als Dokument, sondern als lebendiger Systemzustand.

Schritt 1: Entdecken, was wirklich im Netzwerk hängt

Der erste Schritt ist die Bestandsaufnahme selbst. Eine manuelle Inventarisierung stößt dabei an strukturelle Grenzen, weil sich die Infrastruktur schneller verändert, als die Verantwortlichen sie erfassen können. Eine automatisierte Inventarisierung kombiniert deshalb drei Ansätze.

Die aktive Erkennung per Netzwerk-Scan findet erreichbare Systeme, offene Ports und laufende Dienste. Für OT-Umgebungen gelten dabei besondere Anforderungen, denn aktive Scans können industrielle Steuerungssysteme destabilisieren.

Passive Verfahren sind dort oft die einzig verantwortbare Wahl, da sie den Netzwerkverkehr analysieren, ohne selbst Pakete zu senden. So werden auch Systeme sichtbar, die nicht auf Scans reagieren, und die Beziehungen zwischen den Systemen lassen sich rekonstruieren. Den nötigen Kontext liefert schließlich die Quellintegration. CMDB, Active Directory, Cloud-APIs, MDM-Systeme und DHCP-Logs bringen Informationen ein, die kein Scanner allein erzeugen kann. Sie werden eingebunden, aber nicht ersetzt.

Schritt 2: Normalisieren, aus Datenfragmenten eine steuerbare Sicht erstellen

Entdeckte Assets stammen aus vielen Quellen, mit unterschiedlichen Benennungen, Attributen und einer je eigenen Granularität. Erst die Normalisierung macht aus diesen Fragmenten eine steuer- und verarbeitbare Sicht auf die Infrastruktur. Das bedeutet konkret die einheitliche Klassifikation von Asset-Typen, die Zuweisung von Kritikalitätsstufen nach Funktion und Exposition, die Klärung von Eigentümern und Verantwortlichkeiten sowie die Zusammenführung doppelter Einträge aus verschiedenen Systemen.

Was dabei entsteht, ist kein besseres Adressbuch – es ist ein Kontextmodell. Es beantwortet, was ein System ist, wem es gehört, welche Funktion es hat und mit welchen anderen Systemen es kommuniziert. Vor allem werden die Abhängigkeiten transparenter und schaffen ein gemeinsames Verständnis innerhalb der IT-Abteilung.

Dieses Verständnis der Zusammenhänge, das Bewusstsein dafür, was es zu schützen gibt, ist ein wichtiger Bestandteil der Gesamtaufgabe. Genau diese Tiefe ist die Grundlage für das SIEM in Dimension 2 – und für jedes Prüfgespräch, das die Wirksamkeit der Maßnahmen bewertet.

Schritt 3: Aktuell halten, Drift als frühes Signal

Ein einmaliger Inventarisierungsrun erzeugt jedoch nur eine Momentaufnahme. Die Infrastruktur verändert sich täglich. Was heute stimmt, kann morgen falsch sein. Diese Lücke schließt Schritt 3. Die Driftdetektion macht Abweichungen zwischen bekanntem und aktuellem Zustand automatisch und zeitnah sichtbar.

Erscheint ein neues System im Netzwerk, löst das einen Alert aus. Wird auf einem bekannten System ein unbekannter Dienst aktiv, erzeugt das einen Hinweis. Damit ist die Driftdetektion mehr als Asset-Management. Sie ist ein frühes Signal für mögliche Angriffsvorbereitung oder laterale Bewegungen.

Wer zeigen kann, dass jede Infrastrukturänderung zeitnah erfasst und bewertet wurde, hat einen wesentlichen Teil des Wirksamkeitsnachweises bereits erbracht.

Was bedeutet das für …?

Die drei Schritte beschreiben, wie Asset-Transparenz technisch entsteht. Wer sie verantwortet und wer aus ihr welche Konsequenzen ziehen muss, hängt jedoch von der Rolle ab. Für die Leitungsebene, die Sicherheitsverantwortlichen und den Betrieb stellt sich die Frage nach dem Inventar jeweils anders.

… Geschäftsführung und Vorstand. Asset-Transparenz ist keine technische Detailfrage, sondern eine Grundlage für die Risikosteuerung und damit eine Leitungsaufgabe. Eine Risikoanalyse gemäß Art. 21 Abs. 2 lit. a NIS-2-Richtlinie, die auf einem unvollständigen Inventar beruht, ist kein belastbares Steuerungsinstrument. Sie ist im Zweifel selbst eine Schwachstelle, weil falsche oder veraltete Informationen zu falschen Schlussfolgerungen und Entscheidungen führen können.

§ 38 BSIG begründet eine nicht delegierbare Verantwortung der Leitungsebene. Die Geschäftsführung muss Cybersicherheitsmaßnahmen nicht nur genehmigen, sondern deren Umsetzung aktiv überwachen (Abs. 1). Bei schuldhaft verursachtem Schaden haftet sie nach gesellschaftsrechtlichen Regeln (Abs. 2). Sie ist verpflichtet, regelmäßig an Schulungen teilzunehmen, um ein angemessenes Verständnis für IT-Sicherheitsrisiken zu entwickeln (Abs. 3).

Die Haltung mancher Manager nach dem Motto „Wofür habe ich meine Fachabteilungen?“ ist für Prüfer nicht mehr akzeptabel und für das Unternehmen nicht mehr hinnehmbar. Sie blendet aus, dass die Gesamtverantwortung für die Einhaltung gesetzlicher Pflichten bei der Geschäftsleitung verbleibt und sich nicht auf Fachabteilungen delegieren lässt.

Liegen im Schadensfall die Voraussetzungen einer Haftung vor, also Pflichtverletzung, Verschulden, Schaden und Kausalität, hat die Einrichtung einen Anspruch gegen das jeweilige Geschäftsleitungsmitglied. Grundlage sind vorrangig die gesellschaftsrechtlichen Organhaftungsregelungen (§ 43 GmbHG bzw. § 93 AktG). Weitere zivilrechtliche Anspruchsgrundlagen können im Einzelfall ergänzend hinzutreten.

Die Unkenntnis zentraler Pflichten aus § 38 BSIG wird Geschäftsleitungsmitgliedern regelmäßig nicht ohne Weiteres entlastend zugutekommen; die Einordnung als einfache oder grobe Fahrlässigkeit beziehungsweise Vorsatz bleibt jedoch eine Frage des Einzelfalls. Ein bewusstes Nichtbefolgen spricht sogar für grobe Fahrlässigkeit oder unter Umständen Vorsatz, was die Lage für das betroffene Geschäftsleitungsmitglied haftungsrechtlich besonders problematisch macht.

Die Leitungsebene muss deshalb entscheiden, ob das aktuell verfügbare Inventar ausreicht, um eine valide Risikoanalyse zu erstellen und damit die eigene Sicherheitslage belegbar zu machen. Falls nicht, braucht es einen dokumentierten Nachweis darüber, wann, mit welchem Budget und durch wen der Mangel behoben wird.

… CISO und IT-Leitung. Für den CISO stellt sich die Frage konkret: Wie groß ist die tatsächliche Angriffsfläche der Organisation heute? Steht darauf eine Antwort, die auf einer automatisierten, aktuellen Datenbasis beruht, oder nur auf einer Schätzung auf Basis manuell gepflegter Daten? Der Unterschied ist nicht akademisch. Er entscheidet darüber, ob ein SIEM vollständige Ereignisbilder erzeugen kann und ob sich eine Angemessenheitsprüfung überhaupt in eine Wirksamkeitsprüfung übersetzen lässt.

Fehlende Asset-Transparenz ist kein Konfigurationsproblem, das sich nebenbei lösen lässt. Sie ist ein Architekturproblem und erfordert eine bewusste Entscheidung.

… Technische Umsetzungsteams. Umsetzungsteams kennen die Fragilität bestehender Inventardaten aus der täglichen Arbeit. Sie wissen, welche Systeme fehlen, wo Daten veraltet sind und wo die SIEM-Abdeckung endet. Die entscheidende Frage ist, ob diese Erkenntnisse als technische Schulden behandelt werden oder als Architekturanforderungen, die explizit adressiert und belegt werden müssen.

Die Architekturentscheidungen, die hier getroffen werden, bestimmen die technische Nachvollziehbarkeit der Gesamtarchitektur und damit die Qualität aller nachgelagerten Dimensionen.

Use Case: Asset-Transparenz in einem produzierenden Unternehmen

Wie sich die drei Schritte in der Praxis auswirken, zeigt der eingangs skizzierte Fall. Ein mittelständischer Maschinenbauer mit 450 Mitarbeitern, zwei Produktionsstandorten und hybrider IT/OT-Infrastruktur führte eine CMDB mit 280 Einträgen, ausschließlich IT-Systeme. Die OT-Steuerungssysteme betrieb die Produktionsabteilung eigenständig, und Cloud-Dienste nutzten verschiedene Fachbereiche ohne zentrale Erfassung.

Nach der Einführung einer kombinierten Inventarisierungsarchitektur aus aktiven IT-Scans, passiver OT-Erkennung und Cloud-API-Integration waren es 920 Assets. 60 Systeme hatten keine aktuelle Patch-Version, 14 liefen auf abgekündigten Betriebssystemen, und 23 Cloud-Instanzen waren nicht in das zentrale Identity-Management eingebunden.

Die Reifegradmatrix aus dem Auftaktartikel dieser Serie – erschienen in Ausgabe 3 der IT-SICHERHEIT – hat den Abstand zwischen Governance-Anspruch und technischer Realität sichtbar gemacht. Die Inventarisierung macht ihn greifbar, und zwar nicht als abstraktes Risiko, sondern als konkrete Liste von Systemen mit messbarem Handlungsbedarf. Erst so ist eine Risikoanalyse möglich, die diesen Namen verdient und die einer Wirksamkeitsprüfung standhält

Relevante Rechtsgrundlagen und unterstützende Standards

• NIS-2-Richtlinie (EU) 2022/2555, Art. 21 Abs. 2 lit. a: Risikoanalysen und Sicherheitskonzepte für Informationssysteme
• Deutscher Umsetzungskontext (§ 30 BSIG): technische und organisatorische Mindestmaßnahmen; § 38 BSIG: aktive Überwachungspflicht (Abs. 1), Haftung (Abs. 2), Schulungspflicht (Abs. 3)
• ISO/IEC 27001:2022, Annex A, Control 5.9 (Bestandsverzeichnis der Informationswerte) und 5.10 (Nutzung von Informationswerten)
• BSI IT-Grundschutz (BSI-Standard 200-2), Baustein SYS.1.1 und ORP.4
• IEC 62443: Anforderungen an Inventarisierung und Netzwerksegmentierung
  in OT-Umgebungen

Visualisierungsansatz: Asset-Graph-Dashboard

Sichtbar wird dieser Zustand zum Beispiel über ein kombiniertes Dashboard aus Graph-Ebene und tabellarischer Detailansicht. Die Graph-Ebene zeigt Systeme als Knoten und Kommunikationsbeziehungen als Kanten, farbkodiert nach Kritikalität (hoch, mittel, niedrig) und Asset-Typ (IT, OT, Cloud).

Hervorgehoben werden nicht gepatchte Systeme per Farb-Highlight, neue Systeme der letzten 24 Stunden per Badge, Systeme ohne Eigentümer-Zuweisung per Warnmarkierung sowie Verbindungen zwischen IT- und OT-Segmenten als potenzielle Angriffs- und Ausbreitungspfade.

Dieses Dashboard ist kein statischer Bericht, sondern wird kontinuierlich aktualisiert. Ein Asset, das neu im Netzwerk erscheint, wird innerhalb von Minuten sichtbar. Ein System, das seine Kommunikationspartner wechselt, zeigt Drift. So entsteht ein lebendes Bild der Infrastruktur.

Fazit

Asset-Transparenz ist das Fundament, keine Option. Ohne vollständiges, dynamisches Inventar ist eine valide Risikoanalyse nach Art. 21 NIS-2 kaum möglich. Die vier weiteren Bausteine des Modells – Angriffserkennung, Incident Response, Identity und Supply Chain – wirken nur auf den Teil der bekannten Infrastruktur. Eine CMDB ändert daran wenig, denn eine manuell gepflegte Datenbank bildet die verwaltete Infrastruktur ab, nicht zwingend die reale. Genau dieser Unterschied ist der blinde Fleck, den Angreifer ausnutzen.

Damit diese Lücke verschwindet, müssen IT, OT und Cloud in einem einheitlichen Datenmodell zusammengeführt werden, denn drei getrennte Inventare erzeugen ebenso viele blinde Flecken. Die Driftdetektion hält dieses Modell aktuell und ist dabei frühe Angriffserkennung und Wirksamkeitsbeleg zugleich: Jede zeitnah erfasste und bewertete Änderung an der Systemlandschaft trägt so unmittelbar zum geforderten Nachweis bei.

Wer beim Inventar spart, entwertet die übrigen Investitionen. Ausgaben für SIEM, IAM oder Incident Response erzielen nur auf dem bekannten Teil der Infrastruktur die erwartete Wirkung. Asset-Transparenz ist damit die Grundlage dafür, dass sich Sicherheitslage und Vorfälle überhaupt technisch belegen lassen. Wer seine Infrastruktur nicht vollständig kennt, kann ihre Sicherheit weder steuern noch nachweisen.

Literatur

[1] Europäisches Parlament und Rat der EU (2022): Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames
Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). Amtsblatt der EU, L 333, 27.12.2022.
[2] Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung (NIS2-RLUG / BSIG).
[3] Bundesamt für Sicherheit in der Informationstechnik – BSI (2023): BSI-Standard 200-2: IT-Grundschutz-Methodik. Bonn: BSI.
[4] Bundesamt für Sicherheit in der Informationstechnik – BSI (2026): Handreichung Schulung für Geschäftsleitungen, Version 1.0, 17.04.2026.
[5] International Organization for Standardization (2022): ISO/IEC 27001:2022 – Informationssicherheits-Managementsysteme. Genf: ISO.
[6] IEC 62443 (2018 ff.): Security for industrial automation and control systems. Genf: IEC. ENISA – European Union Agency for Cybersecurity (2023): NIS2 Implementation – Technical Guidance for Operators of Essential and Important Services. Athen: ENISA.