Was wirklich auf Ihren Systemen läuft: warum die CMDB keine Messung ist

Die Frage, mit der jede Prüfung anfängt

DORA Artikel 8 und NIS2 Artikel 21 sind unterschiedlich geschrieben und adressieren unterschiedliche Sektoren. Sie beginnen trotzdem an derselben Stelle: Kennen Sie alle Ihre IT-Assets, und können Sie das belegen?

Das ist die unbequemste Anforderung im ganzen Regelwerk, weil sie sich im Termin nicht nachbessern lässt. Alles Weitere setzt sie voraus. Eine risikobasierte Priorisierung ist nur so belastbar wie die Menge, auf der sie arbeitet. Eine Frist gilt nur für die Systeme, die jemand kennt. Ein Asset, von dem die Sicherheitsverantwortlichen nichts wissen, ist ein Prüfungsbefund, der nur noch nicht aufgeschrieben wurde.

Von Dokumenten zu Daten

Dass diese Frage so schwer zu beantworten ist, hat einen strukturellen Grund, und der ist inzwischen bis in die Prüfungshäuser hinein präzise beschrieben. KPMG-Partner Michael Falk skizziert in einem aktuellen Beitrag zur Cyber Governance ein Missverhältnis, das viele Sicherheitsverantwortliche wiedererkennen werden: Unternehmen steuern Produktion, Logistik und Vertrieb längst datengesteuert, während die Informationssicherheit auf manuellen Prozessen ruht. Nachweise liegen als PDF im Ablageordner, Statusberichte entstehen von Hand, und die Entscheidungsgrundlage ist so aktuell wie ihr letzter Bearbeitungsstand. Transparenz über die eigene IT-Landschaft nennt er die "Voraussetzung für moderne Cyber Governance": welche Systeme existieren, welche Anwendungen laufen, wo kritische Daten liegen.

Wir teilen diese Diagnose ohne Einschränkung. Dieser Artikel handelt von der Stelle, an der sie konkret wird: Woher kommt diese Transparenz, wenn ihre bisherige Quelle das Dokument ist, das gerade zum Problem erklärt wurde?

Die CMDB ist eine Annahme, keine Messung

Fast jedes Haus hat eine CMDB, eine Asset-Datenbank oder mindestens eine gepflegte Tabelle. Diese Bestände sind selten falsch angelegt. Sie waren zum Zeitpunkt ihrer Pflege korrekt und driften danach, still und zuverlässig.

Die Gründe dafür sind über Branchen hinweg erstaunlich gleichförmig:

• übernommene Tochtergesellschaften, deren Netzsegmente nie vollständig übertragen wurden
• Testsysteme, die für zwei Wochen aufgesetzt wurden und seit drei Jahren laufen
• Netzbereiche, die dem Scanner nie mitgegeben wurden, weil sie bei der Einrichtung niemandem zugeordnet waren
• Systeme aus einem Projekt, dessen Verantwortlicher das Haus längst verlassen hat
• Geräte, die jemand aus gutem Grund angeschlossen und danach nie wieder erwähnt hat

Der übliche Einwand lautet: Dafür haben wir doch einen Scanner. Ein Scanner prüft die Bereiche, die Sie ihm gegeben haben. Schatten-Infrastruktur steht per Definition außerhalb dieser Bereiche. Ein Werkzeug, das die bekannte Liste abarbeitet, kann die Liste nicht korrigieren. Deshalb bestätigt der nächste Scan meistens das, was Sie ohnehin schon geglaubt haben.

Ist-Wahrheit von innen

Die Alternative ist ein Inventar, das nicht von außen geschätzt, sondern auf dem Asset selbst erhoben wird. Unsere Plattform erfasst dafür pro Asset:

• installierte Pakete mit Versionsständen
• eine Software-Stückliste im CycloneDX-Format (SBOM)
• laufende Dienste
• Container
• lokale Benutzerkonten

Das ist First-Party-Information: nicht der Export einer Datenbank, sondern der Zustand der Maschine zum Zeitpunkt der Erhebung. Und sie ist von der ersten Sekunde an maschinenlesbar: Ein CycloneDX-SBOM ist ein strukturiertes Datenformat, kein Dokument, und lässt sich in jede zentrale Sicherheitsdatenhaltung übernehmen, die Ihre Datenstrategie vorsieht.

Der zweite Teil ist der interessantere. Dort, wo die Plattform ausgerollt ist, sieht sie auch die Nachbarsysteme ohne Agent im selben Netzsegment. Diese erscheinen im Inventar als unverwaltete Assets, mit MAC-Adresse, Hersteller und Zeitpunkt der ersten Sichtung. Verwaltet, unverwaltet und von außen erreichbar stehen damit nebeneinander in einem Bestand, und unverwaltete, exponierte Assets rutschen in der Risikobetrachtung nach oben. Für die Außensicht kommen Certificate Transparency und passives DNS dazu: die vergessenen, aus dem Internet erreichbaren Assets, die in keiner internen Liste stehen.

Wichtig ist, was das nicht ist. Es ist kein Ersatz für Ihre CMDB. Eigentümer, Kritikalität, Vertragsbezug und Servicezuordnung sind Ihre Metadaten und bleiben es; kein Werkzeug liest sie aus dem Netz ab. Was ein First-Party-Inventar liefert, ist die Ist-Wahrheit, gegen die Sie Ihre CMDB prüfen.

Und die Daten bleiben, wo sie hingehören. Die Telemetrie landet ausschließlich in Ihrer eigenen Installation. Unsere Cloud-Intelligence-Engine kennt die globale Bedrohungslage, hält aber keine Asset-Daten von Kunden. Betreiben Sie die Plattform innerhalb Ihrer eigenen Grenze, verlassen Ihre Asset-Daten das Haus nicht; Managed Hosting bleibt EU-ansässig.

Vollständigkeit vor Priorität

Erst wenn die Grundgesamtheit steht, wird Priorisierung ehrlich. Der Weg von der Gesamtmenge zu einer Handlungsliste hat vier Stufen:

Ein CVSS-Score misst theoretische Schwere unter Modellannahmen. Er misst nicht, ob eine Lücke draußen gerade ausgenutzt wird, und er weiß nichts darüber, ob das betroffene Paket bei Ihnen installiert und in Ihrer Umgebung exponiert ist. Beides zusammen entscheidet über die Reihenfolge, nicht die Zahl allein.

Und weil jede zurückgestellte Schwachstelle irgendwann erklärt werden muss: Ein behobener Punkt wird bei uns durch den Vergleich zweier Inventarstände dokumentiert, also durch das Vorher und das Nachher desselben Assets. Nicht durch einen erneuten Scan, nicht durch einen Screenshot und nicht durch ein PDF im Ablageordner. Das ist die Sorte Nachweis, in deren Richtung auch neue Standards wie OSCAL und der modernisierte IT-Grundschutz des BSI (Grundschutz++) zeigen: Kontrollen und Belege als strukturierte, maschinenlesbare Daten statt als Dokumentation.

Was bei Ihnen bleibt

Kein Werkzeug macht Sie DORA- oder NIS2-konform, und wer das anders verkauft, verkauft Ihnen zu viel. Bei Ihnen bleiben:

• das Informationsregister und die zugehörige Vertragsdokumentation
• die Meldewege und die Meldung selbst
• die Ausführung von Patches und Änderungen samt Änderungsprozess
• die fachliche Bewertung, welches Asset für Ihr Geschäft kritisch ist

Das deckt sich mit einer Einschätzung, die auch Falk seinem datengesteuerten Ansatz mitgibt: Die Verantwortung für die Priorisierung bleibt beim Menschen. Genau so verstehen wir unsere Reihenfolge-Empfehlung: als Evidenzlage, nicht als Entmündigung. Was verschoben wird und welches Risiko das Haus trägt, entscheidet Ihr Team.

In denselben Absatz gehören die Produktgrenzen. Wir sind kein Scanner: Scanner erzeugen das Rauschen, wir reduzieren es. Wir sind kein Patch-Werkzeug: Wir sagen Ihnen, was zu beheben ist, in welcher Reihenfolge und wie, und dokumentieren, dass es behoben wurde. Der automatisierte Abgleich gegen Ihre CMDB steht auf der Roadmap; heute liefern wir den Bestand, gegen den Sie prüfen. Plattformen sind Linux und Windows, und das ist die ganze Liste.

Die Frage, die bleibt

Vollständigkeit ist unspektakulär. Sie ist der Höhepunkt keiner Produktdemo und lässt sich schlecht auf eine Folie schreiben. Sie entscheidet trotzdem darüber, ob Ihre Priorisierung eine Aussage ist oder eine Vermutung.

Wann wurde Ihr Inventar zuletzt gegen die Realität geprüft, und nicht gegen die letzte Version seiner selbst?