Sehen, bevor man handeln kann: Warum Ihre CMDB nicht Ihre Angriffsfläche zeigt
Eine CMDB bildet den verwalteten Bestand ab, nicht den tatsächlichen. Warum Asset-Transparenz das Fundament der NIS-2-Umsetzung ist und wie sich die Lücke schließen lässt.
27. August 2026
Ein typisches Muster bei der NIS-2-Vorbereitung: Ein produzierendes Unternehmen lässt erstmals ein systematisches Asset-Discovery laufen — und das Discovery findet ein Vielfaches dessen, was die CMDB als verwaltet ausweist. Produktionsnahe Steuerungen, vergessene Testsysteme, Cloud-Dienste, die eine Fachabteilung ohne IT-Beteiligung eingerichtet hat, existieren im Netz, ohne in der CMDB aufzutauchen.
Dieser Befund ist kein Einzelfall. Er ist der Regelfall, sobald ein Unternehmen zum ersten Mal genau hinsieht.
Der Irrtum: „Wir haben eine CMDB – wir kennen unsere Assets”
Eine CMDB bildet den verwalteten Bestand ab. Sie zeigt, was irgendwann erfasst wurde und – im besten Fall – gepflegt wird. Sie zeigt nicht den tatsächlichen Bestand. Genau diese Differenz zwischen verwaltetem und realem Inventar ist der blinde Fleck, den Angreifer systematisch nutzen: Ein System, das nicht in der CMDB steht, wird nicht gepatcht, nicht überwacht und im Ernstfall nicht als Teil der eigenen Angriffsfläche erkannt. Ohne diesen blinden Fleck zu schließen, bleibt jede weitere Sicherheitsmaßnahme unvollständig, weil ihr der Gegenstand fehlt, auf den sie wirken soll. Deshalb steht Asset-Transparenz als erste von fünf technischen Dimensionen am Fundament jedes Referenzmodells für die NIS-2-Umsetzung – ohne sie bleiben Angriffserkennung, Incident Response, Identity und Supply-Chain-Monitoring auf einem unvollständigen Bild aufgebaut.
Drei Welten, eine Angriffsfläche
Die Lücke entsteht, weil ein Unternehmen technisch nicht aus einer, sondern aus drei unterschiedlich sichtbaren Welten besteht:
- IT wird verwaltet, aber unvollständig. Klassische Inventarprozesse erfassen Server und Clients, verlieren aber bei virtuellen Maschinen, Containern und kurzlebigen Testumgebungen schnell den Anschluss.
- OT ist produktionsnah und inventarfern. Steuerungsanlagen und Maschinen werden von Betriebstechnik verantwortet, nicht von der IT – und tauchen deshalb in klassischen IT-Inventaren häufig gar nicht auf.
- Cloud ist dynamisch und oft unregistriert. Ressourcen entstehen und verschwinden in Stunden, und Fachabteilungen beschaffen SaaS-Dienste direkt, ohne dass die IT davon erfährt.
Drei Ausprägungen derselben Ursache tragen die eigentliche Last: Schatten-IT, SaaS-Sprawl und temporäre Systeme, die nach Projektende nie wieder abgebaut werden. Jede für sich unscheinbar, in Summe die Erklärung dafür, warum ein systematisches Discovery so häufig ein Vielfaches dessen findet, was die CMDB kennt.
Drei Schritte zu einem belastbaren Bild
Die Schließung dieser Lücke folgt keinem einmaligen Projekt, sondern einem wiederkehrenden Prozess in drei Schritten:
- Entdecken. Aktive Scans, passives Monitoring des Netzwerkverkehrs und die Integration bestehender Quellen (Cloud-APIs, Verzeichnisdienste, Konfigurationsmanagement) zusammen ergeben ein deutlich vollständigeres Bild als jede einzelne Methode für sich.
- Normalisieren. Gefundene Assets werden in ein Kontextmodell überführt: Wem gehört das System, welche Kritikalität hat es, in welchem Netzsegment steht es. Eine Liste von IP-Adressen ist noch kein Inventar – erst der Kontext macht sie zu einer Entscheidungsgrundlage.
- Aktuell halten. Ein einmalig erhobenes Inventar veraltet in Wochen. Erst Driftdetektion – die laufende Erfassung und Bewertung von Änderungen – macht aus einer Momentaufnahme einen belastbaren, dauerhaften Nachweis.
Gerade der dritte Schritt trägt unmittelbar zur Wirksamkeit im Sinne von § 30 BSIG bei: Jede zeitnah erfasste und bewertete Änderung ist ein Beleg dafür, dass die Risikomanagementmaßnahme tatsächlich läuft – nicht nur, dass sie einmal eingerichtet wurde.
Der rechtliche Rahmen
Asset-Transparenz ist keine freiwillige Best Practice, sondern in mehreren Normebenen verankert. Auf Ebene der NIS-2-Richtlinie verlangt Art. 21 Abs. 2 lit. a Risikoanalyse und Sicherheit für Informationssysteme – beides ohne belastbares Inventar praktisch nicht durchführbar. Lit. b (Bewältigung von Sicherheitsvorfällen) und lit. d (Sicherheit der Lieferkette) setzen ebenfalls voraus, dass ein Unternehmen weiß, welche Systeme überhaupt betroffen sein können. Auf Ebene des BSIG greifen § 28 (Einordnung als besonders wichtige oder wichtige Einrichtung), § 30 (Risikomanagementmaßnahmen samt Dokumentation) und – für Betreiber kritischer Anlagen besonders relevant – § 31 Abs. 2 BSIG, der Systeme zur Angriffserkennung mit kontinuierlicher und automatischer Erfassung und Auswertung verlangt. Ohne Inventar keine Erfassung, ohne Erfassung keine Auswertung.
Für die Leitungsebene kommt eine gesellschaftsrechtliche Dimension hinzu: § 38 BSIG bündelt Umsetzungs-, Überwachungs- und Schulungsverantwortung, und die Organhaftung nach § 43 GmbHG beziehungsweise § 93 AktG greift unabhängig davon, ob operative Aufgaben delegiert wurden. Wer als Geschäftsführung ein Sicherheitskonzept freigibt, ohne zu wissen, dass die reale Angriffsfläche das Dreifache des dokumentierten Bestands umfasst, trägt dieses Risiko persönlich mit.
Von der Erkenntnis zur Architektur
Der Unterschied zwischen einer CMDB und einem wirksamen Asset-Inventar ist am Ende ein Unterschied zwischen einer statischen Liste und einem betriebenen System. In PRISM ISO ist das Asset-Management direkt mit Controls und Risiken verknüpft, nicht als separate Tabelle neben dem ISMS, sondern als Teil desselben Datenmodells. Datenquellen-Konnektoren binden externe Quellen an, und die Multi-Framework-Crosswalk-Engine sorgt dafür, dass ein einmal erfasstes und bewertetes Asset gleichzeitig für ISO 27001, C5 oder eben NIS 2 Wirkung entfaltet – Controls werden einmal erfüllt und automatisch in mehrere Normen überführt, statt für jeden Standard neu erhoben zu werden.
Wenn Sie nicht wissen, wie groß die Lücke zwischen Ihrer CMDB und Ihrer tatsächlichen Angriffsfläche ist, ist das selbst schon eine Antwort – und ein guter Anlass für ein Gespräch.
Nächster Schritt: Klären Sie im Erstgespräch, wo Ihr Asset-Inventar heute steht, oder verschaffen Sie sich einen Überblick über die NIS-2-Anforderungen unter /nis2.