Compliance und BSI-Grundschutz
Wie NODE64 seine Prüfungen den Anforderungen des BSI IT-Grundschutz und der ISO 27001 zuordnet – und wo die Grenzen liegen.
Was diese Ansicht ist #
NODE64 ordnet jede seiner Prüfungen den Anforderungen zweier Rahmenwerke zu:
- BSI IT-Grundschutz – die Bausteine des Kompendiums, etwa
SYS.1.3(Server unter Linux und Unix) oderNET.3.2(Firewall). - ISO/IEC 27001:2022, Anhang A – die Massnahmen der aktuellen Fassung, etwa
A.8.9(Konfigurationsmanagement).
Unter Security → Rahmenwerke steht dann nicht mehr nur „SSH erlaubt Passwort-Anmeldung", sondern auch, welche Anforderung davon berührt ist und wie das System insgesamt dasteht. Die Karte ist zugeklappt, bis du sie öffnest – zugeklappt steht dort ein Satz mit der Bilanz.
Der Sicherheitsbericht als PDF enthält denselben Abschnitt, geräteweise und über das ganze Konto.
Drei Zustände, nicht zwei #
Jede Anforderung steht in genau einem von drei Zuständen:
| Zustand | Bedeutung |
|---|---|
| erfüllt | Alle zugeordneten Prüfungen liefen und blieben ohne Beanstandung. |
| nicht erfüllt | Mindestens eine zugeordnete Prüfung hat einen offenen Befund erzeugt. |
| technisch nicht prüfbar | Es gibt keine zugeordnete Prüfung, oder keine davon konnte auf diesem System beurteilt werden. |
Der dritte Zustand ist der wichtigste, und er ist der Grund, warum die Zahl oben nicht „93 % Compliance" lautet.
Viele Anforderungen sind organisatorisch. OPS.1.1.2 („Ordnungsgemässe IT-Administration") verlangt Rollenkonzepte, Vertretungsregelungen und Dokumentation. Ein Werkzeug, das Konfigurationsdateien liest, kann dazu nichts sagen – und tut hier auch nicht so. Es zeigt die Anforderung an, kennzeichnet sie als nicht prüfbar und lässt sie aus der Quote heraus.
Eine Prozentzahl, die diese Anforderungen stillschweigend als erfüllt mitzählt, wäre eine Lüge. Die Quote bezieht sich deshalb ausschliesslich auf die technisch prüfbaren Anforderungen, und die Zahl der übrigen steht überall daneben, wo die Quote steht.
Dünne Datengrundlage #
Ein grüner Haken kann auf unterschiedlich festem Boden stehen. Sind einem Baustein vierzehn Prüfungen zugeordnet, davon liefen aber nur sechs – weil der Agent die betreffende Konfiguration nicht lesen konnte –, dann ist die Anforderung zwar nicht verletzt, aber eben auch nicht wirklich belegt.
Solche Fälle bekommen den Zusatz dünne Datengrundlage. Woran es genau fehlte, steht im Bericht unter „Was nicht geprüft werden konnte".
Akzeptierte Befunde #
Ein Befund, den du bewusst akzeptiert oder vertagt hast, zählt weiterhin als nicht erfüllt. Das ist Absicht: Ein akzeptiertes Risiko ist ein dokumentiertes Risiko, kein beseitigtes. Damit der Unterschied sichtbar bleibt, wird die Anforderung zusätzlich als Ausnahme dokumentiert gekennzeichnet – im Audit ist genau das die interessante Zeile.
Über mehrere Geräte #
Im Kontobericht gilt eine Anforderung nur dann als erfüllt, wenn sie auf jedem Gerät erfüllt ist. Die Spalte „Geräte" nennt die Zahl der Systeme, die aus der Reihe tanzen.
Ein Durchschnitt über alle Server würde genau den einen Host verschwinden lassen, dessentwegen man den Bericht liest.
Zuordnung auf Baustein-Ebene #
Zugeordnet wird auf der Ebene der Bausteine (SYS.1.3) beziehungsweise der Massnahmen (A.8.9), nicht auf der Ebene einzelner Anforderungsnummern wie SYS.1.3.A5.
Das hat einen einfachen Grund: Die einzelnen Anforderungstexte des BSI sind urheberrechtlich geschützt und müssen wörtlich stimmen. Eine erfundene oder verrutschte Nummer wäre in einem Audit schlimmer als gar keine. Wer das Kompendium vorliegen hat, kann die Zuordnung im Betrieb verfeinern – die Datenbank trägt die Feinzuordnung bereits.
Was das nicht ist #
Diese Übersicht ist eine Umsetzungshilfe. Sie ist keine Zertifizierung, kein Testat und kein Nachweis gegenüber einer Behörde.
Eine Zertifizierung nach BSI IT-Grundschutz oder ISO/IEC 27001 umfasst den gesamten Informationsverbund einschliesslich aller organisatorischen Anteile und wird ausschliesslich von akkreditierten Stellen durchgeführt. NODE64 kann dir dabei den technischen Teil abnehmen – die Belege sammeln, den Ist-Zustand zeigen und die Lücken benennen. Den Rest nicht.
CIS Benchmarks sind bewusst nicht enthalten. Deren Lizenzbedingungen schränken die kommerzielle Weiterverwendung ein; eine Zuordnung dagegen liesse sich nicht sauber ausliefern.