Warum die Unternehmenswerte in Ihrem ISMS keine Kopie Ihrer CMDB sind

Fast jede Organisation, die mit einem ISMS beginnt, landet an demselben Punkt. Es gibt bereits eine CMDB mit Tausenden Konfigurationselementen, sauber gepflegt vom Betriebsteam, und die Frage liegt auf der Hand. Übernehmen wir diese Liste in das ISMS? Die Antwort lautet nein. Wer es dennoch tut, sitzt binnen einer Woche auf einem Register, das niemand pflegt, und auf einer Klassifizierungsspalte, die leer bleibt. Den Unterschied zwischen den beiden Registern zu verstehen spart Ihnen Monate an Arbeit. Für Finanzunternehmen unter DORA ist das Bild differenzierter, und darauf kommen wir weiter unten gesondert zurück.

Ein Wort, zwei Bedeutungen

Das Wort „Asset“ trägt in der IT zwei Bedeutungen, die sich zufällig denselben Begriff teilen.

In der Betriebswelt, also in ITIL und ISO/IEC 20000, ist ein Konfigurationselement alles, was Sie kennen müssen, um einen Dienst erbringen und ändern zu können: Server, virtuelle Maschinen, Netzkomponenten, Lizenzen und Schnittstellen. Das Register existiert, um Änderungen, Störungen und Kapazität beherrschen zu können. Vollständigkeit und Aktualität sind dabei die wichtigsten Qualitätsanforderungen.

In der Sicherheitswelt, also in ISO/IEC 27001 und in der IT-Grundschutz-Methodik des BSI, ist ein Unternehmenswert etwas, zu dem ein Eigentümer gehört, der darüber entscheiden kann. Die Maßnahme 5.9 verlangt ein Inventar der Informationen und anderen damit verbundenen Werte, mit einem Eigentümer je Eintrag. Diese Eigentümeranforderung ist nicht administrativ gemeint, denn ohne Eigentümer gibt es niemanden, der das Restrisiko akzeptieren kann.

Die beiden Register beantworten also verschiedene Fragen. Ihre CMDB beantwortet die Frage, was vorhanden ist und wie es zusammenhängt. Ihr ISMS-Register beantwortet die Frage, was Sie schützen müssen, wie stark, und wer darüber entscheidet. Das sind keine zwei Fassungen derselben Liste, sondern zwei Listen auf unterschiedlichen Abstraktionsebenen.

Die Forschung hat früh darauf hingewiesen. Oppenheim, Stenson und Wilson zeigten in ihren Arbeiten über Information als Unternehmenswert, dass Information sich anders verhält als ein klassischer Vermögenswert: Sie nutzt sich nicht ab, sie kann an mehreren Orten zugleich existieren, und sie bezieht ihren Wert aus dem Kontext, in dem sie verwendet wird. Eine buchhalterische oder technische Inventarlogik passt dazu schlecht.

Die vier Ebenen

Es hilft, Unternehmenswerte in vier Ebenen zu ordnen. Jede Ebene hat ihre eigene Art von Eigentümer und ihre eigene Art von Frage.

1. Der Geschäftsprozess, etwa Gehaltsabrechnung, Einschreibung oder Auftragsabwicklung. Eigentümer ist der Prozessverantwortliche, und der kann sagen, wie lange der Prozess stillstehen darf, bevor echter Schaden entsteht.
2. Die Information oder Datensammlung, die in diesem Prozess umgeht, etwa Personalakten, Prüfungsergebnisse oder Kundenverträge. Hier setzt die Schutzbedarfsfeststellung an, und Eigentümer ist der Verantwortliche für diese Daten.
3. Die Anwendung oder der Dienst, der den Prozess unterstützt. Sie erbt ihre Einstufung von der am höchsten eingestuften Information, die darin verarbeitet wird.
4. Die zugrunde liegende Technik: Server, Speicher, Netzkomponenten und Schnittstellen. Das ist das Gebiet Ihrer CMDB.

Ein ISMS arbeitet auf den Ebenen 1 bis 3. Ihre CMDB arbeitet auf Ebene 4 und manchmal auf Ebene 3, denn dort berühren sich die beiden Register. Genau an dieser Schnittstelle legen Sie die Verknüpfung an, und nirgendwo sonst.

Den Schutzbedarf bewerten Sie an der Information, nicht am Blech

Ein Datenbankserver ist nicht vertraulich. Die Daten, die darauf liegen, sind es sehr wohl. Das klingt nach Wortklauberei, aber es ist der ganze Unterschied zwischen einer Klassifizierung, die wirkt, und einer Klassifizierung, die Papier bleibt.

Die Bewertung von Verfügbarkeit, Integrität und Vertraulichkeit ist kein Etikett um seiner selbst willen, sondern ein Schalter. Eine Einstufung ist erst dann sinnvoll, wenn etwas aus ihr folgt. Denken Sie an Konsequenzen wie diese:

• Welche Maßnahmen der Basisabsicherung verpflichtend sind und welche ergänzenden Maßnahmen hinzukommen.
• Welche Wiederanlaufzeit und welcher maximale Datenverlust gelten, also RTO und RPO aus Ihrer Kontinuitätsanalyse.
• Wie streng Zugriffsverwaltung, Protokollierung und Aufbewahrungsfristen sein müssen.
• Ob eine gesonderte Risikoanalyse oder eine Datenschutz-Folgenabschätzung nötig ist, bevor die Verarbeitung starten darf.

Bewerten Sie auf Ebene 4, dann bewerten Sie Hardware, und der Hardware lässt sich kein sinnvolles Geschäftsinteresse zuordnen. Ein Server braucht erst dann ein Schutzniveau, wenn Sie wissen, welche Information darauf liegt.

Die amerikanische Behördennorm arbeitet genauso. FIPS 199 kategorisiert entlang derselben drei Schutzziele, mit den Stufen niedrig, mittel und hoch, und wendet dabei das Prinzip des höchsten Werts an, im Englischen als high water mark bekannt; im IT-Grundschutz heißt derselbe Gedanke Maximumprinzip. Die Kategorie eines Systems entspricht der höchsten Einstufung aller Informationsarten, die das System verarbeitet. NIST SP 800-60 arbeitet das in Tabellen aus, die Informationsarten mit Kategorien verknüpfen. Es ist dieselbe Vererbung, die Sie in Kantyra von der Information zur Anwendung laufen sehen.

Dieses Prinzip hat auch eine Kehrseite, die Sie kennen sollten. Wer das Maximumprinzip unbesehen anwendet, bringt ganze Umgebungen unter das schwerste Regime, weil eine einzige sensible Datensammlung darin mitläuft. Genau deshalb lässt NIST in SP 800-53 Raum für das Anpassen des Maßnahmensatzes, und genau deshalb ist die Trennung von Umgebungen oft günstiger, als alles auf die höchste Stufe zu heben. Wenn eine einzige Anwendung Ihre gesamte Umgebung auf die Stufe kritisch zieht, lautet die Frage nicht, wie Sie das bezahlen, sondern ob diese Anwendung dort überhaupt hingehört.

Achten Sie außerdem auf den Kumulationseffekt. Einzelne Daten können für sich genommen niedrig eingestuft sein, während die Sammlung als Ganzes sensibel wird. Eine Liste nur mit Postleitzahlen ist harmlos, aber dieselbe Liste, verknüpft mit einer Abwesenheitserfassung, ist es nicht mehr.

Was die Forschung über scheiternde Klassifizierung zeigt

Die Informationsklassifizierung ist eines der wenigen Themen der Informationssicherheit, zu dem ernsthafte empirische Forschung vorliegt, vor allem aus schwedischen Untersuchungen öffentlicher Organisationen. Die Befunde kehren auffallend konsistent wieder, und sie erklären, warum so viele Klassifizierungsvorhaben stranden.

Organisationen klassifizieren in der Praxis Systeme statt Informationen, weil Systeme greifbar sind und in einer Liste stehen. Damit verschwindet die Verbindung zum Geschäftsinteresse, und übrig bleibt ein technisches Inventar. Die Klassifizierungsschemata sind zudem oft zu feingliedrig, mit zu vielen Stufen und zu vielen Dimensionen, sodass die Menschen, die sie anwenden sollen, aussteigen. Die Arbeit erledigt danach doch der Sicherheitsbeauftragte oder die IT-Abteilung statt der Eigentümer, und gerade das untergräbt den Zweck, denn eine Einstufung ist eine Aussage über das Geschäftsinteresse und nicht über die Technik. Schließlich wird Klassifizierung als einmalige Übung für den Auditor behandelt, während Prozesse und Datenflüsse sich jährlich ändern.

Der rote Faden dieser Befunde ist, dass Klassifizierung scheitert, sobald sie von den Menschen entkoppelt wird, die das Interesse kennen, und von den Maßnahmen, die aus ihr folgen. Das ist zugleich die wichtigste Entwurfsanforderung für jedes ISMS-Register, denn jeder Eintrag braucht einen Eigentümer mit Namen, und jede Einstufung muss nachweisbar etwas daran ändern, was zu geschehen hat.

Das passt auch zu den üblichen Governance-Strukturen. Der CISO ist nicht der Risikoeigentümer. Der Prozess- oder Systemverantwortliche trägt das Risiko und akzeptiert das Restrisiko, und die Leitung ist am Ende rechenschaftspflichtig. Eine Einstufung, die die Sicherheitsabteilung selbst ausgefüllt hat, hält also ein Urteil fest, das diese Abteilung gar nicht fällen darf.

Mit der CMDB verknüpfen oder nicht

Der praktische Rat lautet, keine Synchronisierung zu bauen, wohl aber einen Verweis anzulegen. Es gibt drei Varianten, aufsteigend in Kosten und Pflegeaufwand.

Bei der einfachsten Variante halten Sie in Ihrem ISMS je Anwendung die CI-Nummer aus der CMDB als einfaches Feld fest. Ein Auditor kann diesem Verweis folgen, Sie brauchen dafür keine Technik, und Sie sind an einem Nachmittag fertig. Für die meisten Organisationen reicht das.

Bei der zweiten Variante führen Sie einen einmaligen Import einer Teilmenge durch. Sie exportieren aus der CMDB nur die Konfigurationselemente vom Typ Anwendung oder Geschäftsdienst und verwenden sie als Startliste. Danach pflegen Sie beide Register getrennt, denn sie ändern sich aus verschiedenen Gründen.

Die dritte Variante ist eine periodische Kopplung, und die lohnt sich nur, wenn Ihre CMDB nachweislich aktuell ist und je Konfigurationselement ein klarer Eigentümer eingetragen ist. Bei den meisten Organisationen ist das nicht der Fall, und dann importieren Sie vor allem Datenmüll.

Wichtiger als die Technik ist die Richtung des Verkehrs, denn er läuft in beide Richtungen. Nach unten geht die Einstufung. Wenn eine Anwendung hoch auf Verfügbarkeit eingestuft ist, müssen die Server darunter das zugehörige Backup-, Patch- und Überwachungsregime erhalten, und das ist der Grund, warum Sie die Verknüpfung überhaupt anlegen. Nach oben gehen die technischen Fakten: welche Komponenten diese Anwendung tragen, wo sie stehen und wie ihr Patchstand ist. Die erste Richtung ist die wertvolle, denn dann steuert Ihre Einstufung den Betrieb, statt eine Papierübung zu bleiben.

Diese drei Varianten genügen für Organisationen, die von ISO/IEC 27001, dem IT-Grundschutz oder NIS2 ausgehen. Fallen Sie unter DORA, dann ist die erste Variante zu leicht, und das erläutern wir im nächsten Abschnitt.

Vier Rahmenwerke, ein Thema

Die geschichtete Logik trägt durch alle Rahmenwerke, aber die Achse, entlang derer Sie klassifizieren, unterscheidet sich je Rahmenwerk. Genau dort geht es oft schief, denn Organisationen bauen dann drei Register nebeneinander, obwohl das Thema dasselbe ist.

Die ersten drei Zeilen behandeln dasselbe Thema, nur mit einer anderen juristischen Brille. Die vierte Zeile behandelt etwas anderes.

NIS2 setzt am Dienst an

NIS2 arbeitet auf der Ebene des Dienstes. Ob Sie unter die Richtlinie fallen, hängt von Ihrem Sektor und von dem Dienst ab, den Sie erbringen, und nicht von Ihren Systemen. Die Sorgfaltspflicht verlangt geeignete und verhältnismäßige Maßnahmen auf der Grundlage einer Risikobewertung, wobei das Management der Unternehmenswerte und die Zugriffskonzepte ausdrücklich in den Maßnahmenkategorien des Artikels 21 stehen. Die deutsche Umsetzung fügt eigene Einzelheiten hinzu; prüfen Sie deshalb den aktuellen Stand der nationalen Regelung.

Das Wort „verhältnismäßig“ leistet dabei die Arbeit. Verhältnismäßigkeit können Sie nur begründen, wenn Sie wissen, welches Geschäftsinteresse hinter einem System steht, und genau das hält eine Schutzbedarfsfeststellung fest. Ohne Einstufung haben Sie keine belastbare Antwort auf die Frage, warum Sie für das eine System einen zweiten Ausweichstandort eingerichtet haben und für das andere nicht. Die Meldepflicht funktioniert genauso, denn die Schwelle hängt von den Folgen für Ihre Diensterbringung ab, und die beurteilen Sie auf Prozessebene.

Die Leitungsseite verstärkt den Punkt zum Eigentum. Die Geschäftsleitung muss die Maßnahmen billigen und ihre Umsetzung überwachen, und sie ist dafür rechenschaftspflichtig. Eine Einstufung, die die Sicherheitsabteilung selbst ausgefüllt hat, hält dann ein Urteil fest, das die Leitung tragen müsste.

DORA verlangt beide Register zugleich

DORA ist die Ausnahme von der These, mit der dieser Artikel beginnt, und es lohnt sich, sie genau zu fassen.

Wer Artikel 8 liest, sieht in Absatz 4 und Absatz 6 etwas, das funktional schlicht Konfigurationsmanagement ist. Sie müssen alle Informationsassets und IKT-Assets identifizieren, auch die an externen Standorten, einschließlich Netzressourcen und Geräten, und Sie müssen die Konfiguration sowie die Verbindungen und Abhängigkeiten untereinander erfassen und diese Inventare aktuell halten. Das ist erheblich konkreter als ISO/IEC 27001, denn die Maßnahme 5.9 sagt nichts über Konfigurationen oder Abhängigkeiten. Wer daraus schließt, dass DORA vor allem eine CMDB vorschreibt, hat also einen Punkt.

Doch das ist es nicht, und die Verordnung macht das in ihren Begriffsbestimmungen selbst deutlich. DORA unterscheidet das IKT-Asset, also ein Software- oder Hardware-Asset in den Netzwerk- und Informationssystemen, vom Informationsasset, also einer Sammlung von Informationen, die es zu schützen lohnt. Das ist exakt die oben beschriebene Trennung der Ebenen, und der Gesetzgeber hat sie in den Begriffsbestimmungen verankert, statt beides in einen Topf zu werfen.

Absatz 1 ist zudem keine Inventarfrage. Dort steht, dass Sie die IKT-gestützten Geschäftsfunktionen identifizieren, klassifizieren und dokumentieren müssen, samt Rollen und Verantwortlichkeiten und samt den Informationsassets und IKT-Assets, die diese Funktionen unterstützen, jeweils in Beziehung zum IKT-Risiko. Eine durchschnittliche CMDB liefert das nicht, denn ihr fehlt das Folgende:

• Es steht allenfalls ein technischer Administrator darin, nicht ein Eigentümer, der das Restrisiko akzeptieren kann.
• Die Verbindung von einer Komponente zur Geschäftsfunktion, die sie unterstützt, fehlt, und damit auch der Grund, warum diese Komponente von Bedeutung ist.
• Das Urteil über die Kritikalität ergibt sich nicht aus ihr, denn dieses Urteil folgt aus der Geschäftsfunktion und nicht aus der Technik.
• Es gibt keine periodische Überprüfung, in der jemand bestätigt, dass die Einstufung noch stimmt, während DORA eine Aktualisierung verlangt und eine Risikobewertung bei jeder wesentlichen Änderung.
• Altsysteme und die Abhängigkeit von IKT-Drittdienstleistern erhalten keine gesonderte Aufmerksamkeit, während Artikel 8 ihnen eigene Absätze widmet.

Die scharfe Formulierung lautet deshalb, dass DORA weder eine CMDB verlangt noch ein klassisches Werteregister, sondern die Kombination aus beidem mit einer nachweisbaren Verknüpfung dazwischen. Eine CMDB allein ist zu technisch und lässt Funktion, Eigentümer und Kritikalität vermissen. Ein klassisches Register allein ist zu abstrakt und lässt Konfiguration und Abhängigkeiten vermissen. Die technischen Regulierungsstandards zur Verordnung arbeiten das mit Anforderungen daran aus, was das Inventar je Asset enthalten muss.

Praktisch bedeutet das für Finanzunternehmen, dass ein einzelnes Verweisfeld mit der CI-Nummer nicht genügt. Sie brauchen eine gepflegte Verknüpfung, in der die Kritikalität von oben nach unten auf die technischen Komponenten vererbt wird und in der die Abhängigkeiten sichtbar bleiben. Rechnen Sie außerdem mit einem dritten Register, das mit den ersten beiden nichts zu tun hat, nämlich dem Informationsregister über die vertraglichen Vereinbarungen mit IKT-Dienstleistern. Es hat ein vorgeschriebenes Datenmodell mit festen Vorlagen und geht an die Aufsicht; wer es in dieselbe Tabelle wie seine Unternehmenswerte pressen will, fährt sich fest.

Ein Register, mehrere Merkmale

Das praktische Ergebnis ist, dass Sie ein einziges Register auf Prozess- und Informationsebene führen, mit je Rahmenwerk einem eigenen Merkmal in derselben Zeile. Ein Prozess erhält also eine Bewertung der Schutzziele, daneben ein Merkmal, ob er unter NIS2 als wesentlicher oder wichtiger Dienst zählt, und für Finanzunternehmen ein Merkmal, ob er eine kritische oder wichtige Funktion ist.

Leiten Sie diese Merkmale nicht automatisch auseinander ab. Eine hohe Einstufung der Vertraulichkeit macht etwas noch nicht zu einer kritischen Funktion unter DORA, und eine kritische Funktion muss nicht hoch auf Vertraulichkeit eingestuft sein. Es sind juristische Qualifikationen mit eigenen Kriterien, und Software, die sie automatisch voneinander übernimmt, liefert ein falsches Bild, das lediglich ordentlich aussieht.

Wie groß das Register sein sollte

Ein arbeitsfähiges ISMS-Register zählt bei den meisten Organisationen zwischen fünfzig und hundert Unternehmenswerte. Stehen Sie bei Tausenden Zeilen, dann haben Sie Ihre CMDB kopiert.

Die Prüfung je Zeile ist einfach. Gibt es eine Person mit Namen, die für diesen Unternehmenswert das Restrisiko akzeptieren kann? Und ändert die Einstufung, die Sie ihm geben, etwas an den Maßnahmen? Beantworten Sie eine der beiden Fragen mit Nein, dann gehört die Zeile in Ihre CMDB und nicht in Ihr ISMS.

Unter DORA gilt diese Faustregel weiter für die oberen Ebenen, aber das vollständige Inventar der IKT-Assets kommt hinzu, und das ist naturgemäß umfangreicher. Der Unterschied ist, dass Sie beide getrennt halten und miteinander verbinden, statt sie zu einer einzigen Liste zu vermengen.

In sieben Schritten

1. Beginnen Sie bei den Geschäftsprozessen und nicht bei den Systemen, und beschränken Sie die Anzahl auf die Prozesse, auf die es wirklich ankommt.
2. Benennen Sie je Prozess den Eigentümer, und halten Sie diesen Namen fest, bevor Sie weitergehen.
3. Erfassen Sie je Prozess die Informationen, die darin umgehen, und bewerten Sie sie nach Verfügbarkeit, Integrität und Vertraulichkeit.
4. Verknüpfen Sie die Anwendungen mit diesen Informationen, und lassen Sie die Einstufung von der am höchsten eingestuften Datensammlung vererben.
5. Halten Sie je Anwendung den Verweis auf das Konfigurationselement in Ihrer CMDB fest, ohne die technischen Daten zu übernehmen. Fallen Sie unter DORA, dann legen Sie eine gepflegte Verknüpfung zu den zugrunde liegenden Komponenten und ihren Abhängigkeiten an.
6. Übersetzen Sie die Einstufung in konkrete Anforderungen, also in Maßnahmen, Wiederanlaufzeiten und Aufbewahrungsfristen, und geben Sie diese an den Betrieb weiter.
7. Überprüfen Sie die Bewertung jährlich und bei jeder wesentlichen Änderung, und lassen Sie den Eigentümer diese Überprüfung bestätigen.

Diese Reihenfolge ist für einen Teil der Organisationen überdies keine freie Wahl. Sowohl NIS2 als auch DORA verlangen, dass Ihre Maßnahmen im Verhältnis zum Risiko stehen, und dieses Verhältnis können Sie nur begründen, wenn Sie wissen, welches Geschäftsinteresse hinter einem System steht. Ein technisches Inventar allein liefert diese Begründung nicht, und eine Einstufung ohne Verbindung zur Technik liefert keine nachweisbare Umsetzung. Sie brauchen beides, aber als zwei Register, die Sie verbinden.

Quellen

Normative Quellen, direkt nachzuschlagen:

• ISO/IEC 27001:2022, Maßnahmen 5.9 (Inventar der Informationen und anderen damit verbundenen Werte), 5.10, 5.12 (Klassifizierung von Informationen) und 5.13 (Kennzeichnung von Informationen), mit den Erläuterungen in ISO/IEC 27002:2022.
• Die IT-Grundschutz-Methodik des BSI, insbesondere die Schutzbedarfsfeststellung mit Maximumprinzip und Kumulationseffekt.
• Richtlinie (EU) 2022/2555 (NIS2), insbesondere die Risikomanagementmaßnahmen in Artikel 21, die Leitungspflichten in Artikel 20 und die Meldepflichten in Artikel 23. Prüfen Sie den aktuellen Stand der deutschen Umsetzung, bevor Sie sich darauf berufen.
• Verordnung (EU) 2022/2554 (DORA), Artikel 3 für die Begriffsbestimmungen des IKT-Assets und des Informationsassets, und Artikel 8 für Identifizierung, Klassifizierung und Dokumentation von Geschäftsfunktionen und Assets. Übernehmen Sie die Definitionen aus Artikel 3 wörtlich, wenn Sie dazu interne Regelungen schreiben, und ziehen Sie die technischen Regulierungsstandards zur Verordnung für die Anforderungen an das Inventar heran.
• ISO/IEC 20000-1 und die ITIL-4-Praktik für das Servicekonfigurationsmanagement, für die Bedeutung des Konfigurationselements und der CMDB.
• FIPS 199 (2004) für die Kategorisierung entlang Vertraulichkeit, Integrität und Verfügbarkeit und für das Prinzip des höchsten Werts, mit der Ausarbeitung in NIST SP 800-60.
• NIST SP 800-53 Rev. 5, Maßnahme CM-8 zum Inventar der Systemkomponenten, die deutlich zeigt, dass das technische Inventar etwas anderes ist als die Kategorisierung.
• NIST Cybersecurity Framework 2.0, Kategorie ID.AM, in der die Priorisierung von Unternehmenswerten anhand von Klassifizierung und Kritikalität ausdrücklich enthalten ist.
• CIS Controls v8, Maßnahmen 1 und 2 für das Inventar von Geräten und Software, und Maßnahme 3.7 für das Datenklassifizierungsschema.

Forschungsliteratur:

• Oppenheim, Stenson und Wilson, „The attributes of information as an asset“ (New Library World, 2001) und die dreiteilige Reihe „Studies on Information as an Asset“ (Journal of Information Science, 2003–2004), darüber, warum Information sich anders verhält als ein klassischer Vermögenswert.
• Erik Bergström und Kollegen (Universität Skövde und Jönköping University) über Informationsklassifizierung im schwedischen öffentlichen Sektor, unter anderem „Developing an information classification method“ (Information & Computer Security, 2021) und „An information classification model for public sector organizations in Sweden“ (Information & Computer Security, 2022), mit Befunden zu überkomplexen Schemata, Klassifizierung durch die falsche Funktion und der fehlenden Verbindung zu Maßnahmen.