Grundschutz++ gegen die eigene Dokumentation

01 — Die Ausgangslage

Mein ISMS ist nach ISO 27001 aufgebaut. Es gibt eine Anwendbarkeitserklärung, Register für Risiken, Assets und Lieferanten und Nachweise für jede Maßnahme. Alles liegt versioniert als Markdown in einem Repository. Das Setup ist klein: ein Betrieb, eine Plattform, ein paar Kunden.

Mit Grundschutz++ stellt das BSI den IT-Grundschutz neu auf. Die Anforderungen liegen maschinenlesbar vor, in der Stand-der-Technik-Bibliothek. Die Frage war einfach. Hält mein ISMS dem stand, und wo nicht?

02 — Grundschutz++ und ISO 27001 zusammenführen

Grundschutz++ ordnet die Anforderungen nicht mehr nach Bausteinen wie IT-Grundschutz bisher. Die Anforderungen sind nach Praktiken gruppiert, zum Beispiel DET für Detektion, KONF für Konfiguration oder NOT für die Notfallplanung. Jede Anforderung hat eine Kennung, einen Text und ein Niveau. Das Niveau ist normal oder erhöht und richtet sich nach dem Schutzbedarf.

Der größte Unterschied liegt im Format. Das BSI veröffentlicht die Anforderungen in OSCAL, einem offenen Standardformat, in der Stand-der-Technik-Bibliothek. Man braucht dazu keinen eigenen Parser mehr. Ein Skript kann die Liste vollständig einlesen, und keine Anforderung geht beim Übertragen verloren.

Die Brücke zu ISO 27001

Ein ISMS nach ISO 27001 hat bereits eine Anwendbarkeitserklärung. Abschnitt 6.1.3 d verlangt sie. Sie listet die 93 Maßnahmen aus Anhang A der Fassung von 2022, jeweils mit Begründung, ob sie gelten. Die Bibliothek enthält ein Mapping von diesen Maßnahmen auf Grundschutz++.

Über dieses Mapping entsteht die Prüfliste. Jede angewandte Anhang-A-Maßnahme zieht die zugeordneten Grundschutz++-Anforderungen nach sich. In meinem Fall waren das 280. Wer sein ISMS nach ISO 27001 führt, muss also nicht bei null anfangen. Die Anwendbarkeitserklärung legt fest, was zu prüfen ist.

03 — Basis und erhöht: wo der Unterschied technisch liegt

Das normale Niveau ist die Basis für jeden Betrieb. Das erhöhte Niveau gilt dort, wo die Schutzbedarfsfeststellung einen hohen Bedarf ergibt. Welches Niveau eine Anforderung hat, steht in der Bibliothek. Ob es für den eigenen Betrieb gilt, entscheidet der eigene Schutzbedarf. Das Mapping auf ISO 27001 nimmt einem diese Entscheidung nicht ab.

Der Unterschied an Beispielen

Die folgenden Paare zeigen, wie weit die Niveaus auseinanderliegen. Es sind sinngemäße Zusammenfassungen, nicht der Wortlaut des BSI.

• Protokollierung: Auf normalem Niveau werden sicherheitsrelevante Ereignisse zentral gesammelt und aufbewahrt. Erhöht kommt der Zugriff auf einzelne Objekte dazu: Wer hat welche Sicherung gelesen, und wann? Dazu Regeln, welche Daten gar nicht erst im Log landen.
• Detektion: Normal heißt, Angriffe am Netzrand und auf den Hosts zu erkennen und zu melden. Erhöht kommen Anomalien in der Anwendung selbst dazu. Außerdem eine eigene Erkennung für Datenabfluss.
• Kapazität: Normal ist ein Alarm, wenn eine Platte vollläuft. Erhöht wird Kapazität geplant, mit Trends und Reserven, bevor ein Alarm nötig wird.
• Schwachstellen: Normal werden Schwachstellenmeldungen zu eingesetzter Software verfolgt. Erhöht kommen regelmäßige Penetrationstests dazu. Außerdem die aktive Suche in öffentlichen Quellen nach der eigenen Angriffsfläche, etwa in Zertifikats-Logs.
• Notfallvorsorge: Normal sind Sicherungen, die wiederherstellbar sind und getestet werden. Erhöht kommen eine räumlich getrennte Kopie und ein Schutz gegen Löschen dazu, der auch mit Administratorrechten nicht zu umgehen ist.

Wie ich das erhöhte Niveau behandelt habe

Die Anforderungen auf normalem Niveau habe ich vollständig beantwortet. Beim erhöhten Niveau gab es drei Klassen:

• Schon erfüllt: Die Maßnahme lief bereits, oft als Nebenprodukt einer anderen.
• Leicht erreichbar: in höchstens einem Tag umsetzbar, ohne neue Komponente. Diese Punkte habe ich sofort umgesetzt.
• Bewusst offen: Der Aufwand passt nicht zum Schutzbedarf. Diese Punkte sind markiert, mit Begründung. Sie stehen nicht in einem Plan, den niemand umsetzt.

Die dritte Klasse ist die wichtigste. Eine offene Anforderung mit Begründung ist eine Entscheidung. Eine offene Anforderung ohne Begründung ist eine Lücke. In ISO 27001 gehört diese Entscheidung in den Risikobehandlungsplan, freigegeben vom Risikoeigentümer.

04 — Die Methode: Konfiguration statt Dokument

Die wichtigste Regel der Prüfung: Eine Anforderung gilt als erfüllt, wenn das System es zeigt. Dass eine Seite es behauptet, reicht nicht.

Drei Arten von Nachweis

• Konfiguration: eine Einstellung im Repository, die das Verhalten erzwingt. Zum Beispiel eine Regel, die nur Maintainer Release-Tags anlegen lässt.
• Messung: ein Abruf am laufenden System, mit Datum. Zum Beispiel die Frage, ob eine Alarmregel geladen ist und ob ihre Metrik überhaupt ankommt.
• Dokument: nur dort, wo nichts anderes geht. Etwa bei organisatorischen Regeln oder Verträgen.

Die Art des Nachweises steht an jeder Zeile, zusammen mit dem Datum der Messung. Das klingt pedantisch. Es ist aber der Unterschied zwischen einer Prüfung und einem Abgleich zweier Texte. Wer nur Dokumente gegen Dokumente legt, prüft, ob die Doku mit sich selbst übereinstimmt. Das tut sie fast immer.

Klare Bewertungsregeln

• Erfüllt: Die Anforderung ist vollständig umgesetzt und belegt.
• Teilweise: Die Maßnahme existiert, aber ein Teil fehlt. Das kann ein Alarm sein, der niemanden erreicht, oder ein Prozess ohne Nachweis. Die fehlende Hälfte steht in der Zeile.
• Nicht erfüllt: Es gibt keine Maßnahme oder nur eine Behauptung.
• Nicht anwendbar: Die Anforderung passt nicht zum Betrieb. Die Begründung steht dabei, wie in der Anwendbarkeitserklärung.

Eine Regel hat sich als besonders wichtig herausgestellt: Eine Maßnahme, die nur auf dem Papier existiert, zählt als nicht erfüllt, nicht als teilweise. Sonst wird die Mitte der Skala zum Versteck.

05 — Der Katalog als Datenmodell: Abgleich mit IaC und GitOps

Grundschutz++ ist das erste BSI-Regelwerk in OSCAL, einem Standardformat des NIST für Compliance-Daten. Es lässt sich damit ohne eigenen Parser verarbeiten. Jede Anforderung ist ein JSON-Objekt mit festen Feldern. Wer seine Infrastruktur als Code führt, hat damit zwei Datenbestände, die sich vergleichen lassen. Das macht die Prüfung reproduzierbar.

Anatomie einer Anforderung

Eine Anforderung ist kein Fließtext mit Spielraum. Sie ist ein Satz mit fester Grammatik, und die Bibliothek zerlegt ihn in Felder. Gekürzt sieht das so aus:

{
  "id": "KONF.3.2",
  "title": "Speicherverschlüsselung",
  "props": [
    { "name": "sec_level",       "value": "normal-SdT" },
    { "name": "effort_level",    "value": "3" },
    { "name": "confidentiality", "value": "2" },
    { "name": "threats",         "value": "G 0.19, G 0.14" }
  ],
  "parts": [{
    "name": "statement",
    "props": [
      { "name": "target_object_categories", "value": "IT-Systeme" },
      { "name": "documentation", "value": "Konfigurationshistorie" },
      { "name": "result",        "value": "integrierte Festspeichermedien" },
      { "name": "action_word",   "value": "verschlüsseln" },
      { "name": "modal_verb",    "value": "SOLLTE" }
    ],
    "prose": "Konfiguration für IT-Systeme SOLLTE integrierte Festspeichermedien verschlüsseln."
  }]
}

Quelle: BSI, Stand-der-Technik-Bibliothek, CC BY-SA 4.0, gekürzt.

Für eine technische Prüfung zählen fünf Felder:

• Zielobjekt: worauf sich die Anforderung bezieht, hier IT-Systeme. Es sagt, wo man suchen muss.
• Handlungswort: was zu tun ist, etwa aktivieren, einschränken, verschlüsseln, überprüfen oder verankern. Es sagt, welche Art Nachweis passt.
• Ergebnis: woran die Handlung ansetzt, hier die eingebauten Datenträger.
• Modalverb: MUSS, SOLLTE oder KANN. Es sagt, wie schwer eine Lücke wiegt.
• Dokumentationsvorgabe: wo der Nachweis liegen soll, hier die Konfigurationshistorie.

Dazu kommen Niveau, Aufwandsstufe, die betroffenen Schutzziele und Verweise auf die elementaren Gefährdungen. Damit lässt sich filtern, bevor man eine einzige Zeile Text liest.

Das Handlungswort bestimmt den Nachweis

Das Handlungswort ist das nützlichste Feld. Es trennt die Anforderungen, die man im Repository prüfen kann, von denen, die ein Protokoll oder einen Termin brauchen. Für meine 280 Anforderungen ergab das vier Gruppen:

• 110 Konfiguration: aktivieren, deaktivieren, einschränken, installieren, blockieren, verschlüsseln, protokollieren, zuweisen, autorisieren, authentifizieren, platzieren, untersagen, löschen. Nachweis ist eine Stelle im IaC- oder GitOps-Repository und eine Messung, dass sie wirkt.
• 49 Prüfung: überprüfen, testen, überwachen, ausführen. Hier reicht Code nicht. Nachweis ist ein Lauf mit Datum: ein CI-Job, ein Alarm, der ausgelöst hat, ein Protokoll einer Wiederherstellung.
• 100 Dokument: verankern, dokumentieren, festlegen, vereinbaren. Nachweis ist ein Text, ein Vertrag oder eine Freigabe.
• 21 Menschen: sensibilisieren, anweisen, informieren. Nachweis ist ein datierter Eintrag, wer wann was erfahren hat.

Knapp 40 Prozent der Prüfliste lassen sich also direkt gegen Code beantworten. Ein weiteres Sechstel gegen Daten aus Pipeline und Monitoring, die ohnehin anfallen. Nur der Rest braucht Handarbeit am Dokument.

Vom Zielobjekt zum Repository-Pfad

Das Zielobjekt sagt, in welchem Teil des Codes man sucht. Die Zuordnung habe ich einmal festgelegt und dann für alle Anforderungen benutzt:

• Konfiguration für IT-Systeme: OpenTofu-Module und Vorlagen der Server. KONF.3.2 ist dort eine einzige Ressource, die Verschlüsselung für neue Volumes erzwingt. Dazu kommt eine Messung, dass auch alle bestehenden Volumes verschlüsselt sind.
• Konfiguration für Anwendungen und Webserver: Helm-Values und Manifeste im GitOps-Repository, etwa Sicherheits-Header am Ingress.
• Architektur für Netze: Security Groups, NetworkPolicies und Firewall-Regeln.
• Berechtigung: IAM-Policies, Kubernetes-RBAC, geschützte Branches und Tags.
• Detektion: Alarmregeln, Log-Pipelines und die Konfiguration der Scanner.
• Änderungen und Tests: CI-Definitionen, Merge-Regeln und Signaturprüfung.

Die Konfigurationshistorie ist Git

Die häufigste Dokumentationsvorgabe im ganzen Katalog ist die Konfigurationshistorie. Sie steht an 183 von 1.000 Anforderungen. Wer mit GitOps arbeitet, hat sie bereits. Jede Änderung ist ein Commit, jeder Commit hängt an einem Merge Request, jede Freigabe an einer Pipeline. Man muss nichts nachträglich aufschreiben. Man muss nur auf den richtigen Commit zeigen.

Deshalb nennt jede Zeile der Prüfung Repository und Commit. Eine Aussage wie „Verschlüsselung aktiv“ ist ohne Commit eine Behauptung. Mit Commit ist sie nachprüfbar, auch noch in einem Jahr.

Soll, Ist und Behauptung

IaC beschreibt den Soll-Zustand. Das reicht nicht, denn das laufende System kann abweichen. Für jede Konfigurationsanforderung habe ich deshalb drei Quellen gegeneinander gelegt:

• Soll: was im Repository steht, an einem festen Commit.
• Ist: was das laufende System meldet. Ein tofu plan ohne Änderungen, ein ArgoCD-Status „Synced“, ein Abruf an der API, ein curl gegen die Header.
• Behauptung: was die ISMS-Dokumentation sagt.

Erfüllt ist eine Anforderung erst, wenn Soll und Ist übereinstimmen. Die interessanten Befunde liegen dort, wo die Behauptung von beiden abweicht. Das passiert öfter als erwartet, und in beide Richtungen.

Reproduzierbar machen

Die Bibliothek wird laufend neu veröffentlicht. Eine Prüfung gegen „die aktuelle Fassung“ lässt sich deshalb nicht wiederholen. Drei Regeln haben das gelöst:

• Fest auf einen Commit: Katalog, Mapping und die eigenen Repositories werden auf einen Commit festgelegt. Das Skript lehnt Branch-Namen ab.
• Nichts fällt still heraus: Das Mapping zeigte auf 299 Kennungen. 19 davon gibt es im Katalog am festgelegten Commit nicht, das Mapping hinkt dem Katalog hinterher. Das Skript listet sie am Ende auf, statt sie zu verwerfen.
• Differenz statt Neuanfang: Kommt ein neuer Commit der Bibliothek, vergleicht man die Kennungen. Nur neue oder geänderte Anforderungen werden neu bewertet.

Was sich messen lässt, wird danach selbst zur Prüfung in der Pipeline. Ein nächtlicher Job prüft etwa, ob alle Release-Tags geschützt sind. Ein täglicher tofu plan meldet Drift. So bleibt eine einmal erfüllte Anforderung erfüllt, oder jemand erfährt es.

Das Werkzeug

Das Skript habe ich als grundschutz-worksheets auf GitHub veröffentlicht, unter MIT-Lizenz. Es ist ein Node-Programm ohne Abhängigkeiten und ohne Installation. Es lädt Katalog und Mapping zu einem festen Commit direkt aus der Bibliothek. Es löst verschachtelte Anforderungen auf, setzt Parameter ein und gruppiert nach Praxis. Heraus kommt pro Anforderung eine Zeile mit Kennung, Niveau, Modalverb, Handlungswort, Zielobjekt, Dokumentationsvorgabe und den Anhang-A-Maßnahmen, die dorthin führen. Als Markdown-Checkliste oder als CSV für die Tabellenkalkulation.

git clone github.com/ohartwig/grundschutz-worksheets
cd grundschutz-worksheets

C=367d775010abee641b258926bb482fcd05270059   # Commit der BSI-Bibliothek
CAT=control_layer/Grundschutz++/Grundschutz++-resolved_catalog.json
MAP=control_layer/Mappings/ISO-27001-zu-GSpp/ISO27001-AnnexA-to-GS++-mapping_collection.json

# Arbeitsblatt für die eigenen Anhang-A-Maßnahmen, als CSV
node worksheet.mjs $CAT --mapping $MAP --sources @anwendbare-massnahmen.txt \
  --format csv --commit $C > arbeitsblatt.csv

# Wo liegt die Arbeit? Zählung nach Praxis, Niveau, Modalverb und Handlungswort
node worksheet.mjs $CAT --mapping $MAP --summary --commit $C

Das Beantworten nimmt es nicht ab. Es sorgt nur dafür, dass keine Anforderung fehlt. Die Texte des BSI kopiert es nicht in die eigene Dokumentation. Dort stehen nur Kennungen und die eigene Bewertung, auch wegen der Lizenz.

Zweite Ebene: vom laufenden System zurück zum Code

Ein ISO-27001-Auditor, dem ich den Ansatz gezeigt habe, hat den wunden Punkt sofort benannt. Der Abgleich läuft bisher in eine Richtung, vom Code zum System. Er prüft, ob das, was im Repository steht, auch läuft. Er findet nicht, was läuft, obwohl es nirgends steht. Ein Server, der längst weg sein sollte. Ein offener Port, den niemand geplant hat. Eine Ressource, die jemand von Hand angelegt hat.

Ein Drift-Check hilft da nur halb. tofu plan vergleicht nur die Ressourcen, die der Code kennt. Was ohne Code entstanden ist, taucht dort nicht auf. Die zweite Ebene dreht die Richtung um und fragt das laufende System, was es gibt:

• Inventar gegen State: alle Ressourcen, die die Cloud-API auflistet, gegen die Ressourcen im State. Was nur in der API steht, ist Schatten-IT oder ein Rest.
• Außensicht gegen Erwartung: ein Portscan der eigenen Adressen von außen, verglichen mit der Liste der Dienste, die erreichbar sein sollen.
• Namen gegen Erwartung: Die Logs der Zertifikats-Transparenz zeigen jeden Hostnamen, für den ein Zertifikat ausgestellt wurde. Ein unbekannter Name ist ein Hinweis.
• Verkehr gegen Architektur: Flow-Logs zeigen, welche Verbindungen tatsächlich stattfinden. Jede Verbindung, die die Netzarchitektur nicht vorsieht, ist ein Befund.

Erfüllt ist eine Anforderung erst, wenn beide Richtungen stimmen. Der Code beschreibt das Richtige, und das System enthält nichts darüber hinaus.

Grenzen des Ansatzes

• ISO 27001 lässt Freiheit. Die Norm schreibt keine bestimmte Maßnahme vor, sie verlangt eine angemessene. Eine Maßnahme kann weit weg von Grundschutz++ liegen und trotzdem wirksam sein. Dann ist die Abweichung zu begründen, nicht zu korrigieren. Grundschutz++ bleibt ein Maßstab, keine Vorgabe.
• Nicht alles ist Code. In vielen Netzen werden Switches, Firewalls und VLANs nicht über IaC ausgerollt. Dort gibt es kein Repository, gegen das man prüfen kann. Übrig bleibt die zweite Ebene, also das System selbst zu befragen.
• Manches braucht Sensoren. Ob eine Netztrennung wirkt, zeigt keine Konfigurationsdatei. Dafür braucht es Messpunkte in jeder Zone. Wer seine DMZ in ein VLAN pro Dienst aufteilt, braucht entsprechend viele.
• Abwesenheit ist schwer zu belegen. „Verzeichnisauflistung einschränken“ ist nicht mit einer Zeile erfüllt. Man muss alle Webserver abfragen und zeigen, dass keiner die Regel bricht.
• Laufzeit ist nicht Konfiguration. Welche Rechte ein Pod tatsächlich hat, steht nicht im Repository, sondern im Cluster.
• Das Urteil bleibt beim Menschen. Die Struktur sagt, wo man suchen muss. Ob das Gefundene angemessen ist, sagt sie nicht.

Mein Setup ist klein und fast vollständig als Code beschrieben. Das hat den Ansatz leicht gemacht. In einer gewachsenen Umgebung würde ich genauso anfangen, mit einem kleinen Bereich, der schon als Code vorliegt. Dort zeigt sich schnell, ob der Abgleich trägt. Größer und komplexer geht danach immer. Manches muss man ohnehin mehrfach und aus verschiedenen Richtungen prüfen.

06 — Die Zahlen

Von den 280 Anforderungen waren am Ende der Prüfung, Stand 26. September 2026:

• 113 erfüllt,
• 115 teilweise erfüllt,
• 29 nicht erfüllt,
• 23 nicht anwendbar.

Die große Mitte ist typisch für ein ISMS, das technisch gut aufgestellt ist. Die Maßnahme läuft, aber ein Glied der Kette fehlt. Typisch sind ein Alarm, der feuert, aber niemanden erreicht, oder ein Test, der einen älteren Aufbau prüft. Solche Lücken sieht nur, wer die ganze Kette misst.

Die 29 Lücken verteilen sich ungleich. Technische Anforderungen, etwa zu Protokollierung, Backups oder Konfiguration, ließen sich oft am selben Tag schließen. Offen blieben vor allem organisatorische Anforderungen. Die brauchen Termine, keine Merge Requests.

07 — Der eigentliche Befund

Ich hatte fehlende Maßnahmen erwartet. Gefunden habe ich vor allem Dokumentation, die nicht mehr stimmte. Und zwar in beide Richtungen.

Muster, die sich wiederholt haben

• Geplant, aber nie gebaut: Die Doku beschrieb eine Komponente, die es nie gab. Sie war beim Schreiben als nächster Schritt gedacht und blieb als Tatsache stehen.
• Nachweis zur falschen Architektur: Ein Nachweis beschrieb einen Aufbau, der längst ersetzt war. Er war formal vollständig und inhaltlich wertlos.
• Alarm ohne Signal: Eine Regel prüfte eine Metrik, die vorher weggefiltert wurde. So eine Regel wirft keinen Fehler. Sie bleibt einfach still.
• Umgekehrt: Maßnahmen liefen längst, die die Doku als fehlend führte. Auch das ist ein Fehler. Wer die Doku liest, plant Arbeit, die schon erledigt ist.

In kleinen Organisationen passiert das fast zwangsläufig. Die Doku entsteht einmal, sorgfältig und vollständig. Danach wandert das System weiter, die Doku nicht. Niemand lügt. Es prüft nur niemand nach.

08 — Was ich daraus ändere

Die Änderungen setzen dort an, wo ISO 27001 ohnehin etwas verlangt. Sie machen die Anforderung prüfbar.

• Gemessen am, nach 7.5: Dokumentierte Information muss gelenkt und aktuell sein. Jede Aussage über den Zustand des Systems trägt deshalb das Datum ihrer Messung. Eine Aussage ohne Datum ist eine Behauptung.
• Nachweise nur mit datiertem Nachtrag, nach 7.5.3: Ein Nachweis wird nicht umgeschrieben, wenn er sich als falsch herausstellt. Er bekommt einen Nachtrag mit Datum. So bleibt sichtbar, was wann bekannt war.
• Alarme, die feuern können, nach Anhang A 8.16: Eine neue Regel gilt erst als fertig, wenn feststeht, dass ihre Metrik ankommt.
• Drift maschinell erkennen, nach Anhang A 8.9: Ein täglicher tofu plan meldet, wenn die Infrastruktur vom Code abweicht. Der erste Lauf hat gleich einen echten Fehler gefunden.
• Die Prüfung als internes Audit, nach 9.2: Sie wiederholt sich, statt einmalig zu bleiben. Die Befunde gehen als Korrekturmaßnahmen nach 10.2 in das Maßnahmenregister.

09 — Was das für ein ISO-27001-Audit bedeutet

Ein Auditor prüft nicht, ob die Doku schön ist. Er prüft, ob die dokumentierten Maßnahmen wirksam sind. Dazu nimmt er Stichproben. Er lässt sich eine Einstellung zeigen, einen Alarm, einen Wiederherstellungstest.

Genau dort fällt veraltete Doku auf. Eine Maßnahme, die nur auf dem Papier existiert, ist eine Abweichung. Wiederholt sich das Muster, wird aus der Nebenabweichung schnell eine Hauptabweichung. Denn dann steht die Lenkung dokumentierter Information nach 7.5 insgesamt in Frage.

Was die Prüfung vorher leistet

• Sie findet die Stichproben, die ein Auditor ziehen würde, vor ihm.
• Sie liefert für jede Anhang-A-Maßnahme einen datierten Nachweis.
• Sie zeigt offen, was bewusst nicht umgesetzt ist. Das gehört in den Risikobehandlungsplan nach 6.1.3 und braucht die Freigabe des Risikoeigentümers.
• Sie gibt der Managementbewertung nach 9.3 eine belastbare Grundlage statt eines Gefühls.

Grundschutz++ ersetzt dabei keine Zertifizierung. Es ist aber ein sehr genauer Maßstab dafür, was der Stand der Technik ist. Wer seine Anwendbarkeitserklärung dagegen prüft, geht besser vorbereitet ins Audit.

10 — Meine Bewertung von Grundschutz++

Nach einem vollständigen Durchgang fällt mein Urteil gemischt aus. Insgesamt ist es klar positiv.

Was überzeugt

• Maschinenlesbar: Die Anforderungen lassen sich vollständig einlesen, filtern und versionieren. Wer seine Nachweise ohnehin im Repository führt, kann Prüfung und Doku zusammenbringen.
• Die Brücke zu ISO 27001: Das Mapping erspart die doppelte Buchführung. Die Anwendbarkeitserklärung bleibt das führende Dokument, Grundschutz++ liefert die Tiefe dazu.
• Konkreter als Anhang A: Wo ISO 27001 eine Maßnahme nur benennt, sagt Grundschutz++ oft, was sie im Betrieb bedeutet. Das macht die Bewertung weniger eine Frage der Auslegung.
• Niveaus statt Alles-oder-nichts: Die Trennung von normal und erhöht zwingt zu einer bewussten Entscheidung pro Anforderung.

Was Arbeit macht

• Das Mapping ist nicht eins zu eins. Eine Anhang-A-Maßnahme zieht mehrere Anforderungen nach sich, und manche Anforderung hängt an mehreren Maßnahmen. Doppelte Zeilen muss man selbst zusammenführen.
• Angemessen bleibt Auslegung. Viele Anforderungen verlangen etwas Angemessenes. Was angemessen ist, entscheidet der eigene Schutzbedarf. Ohne dokumentierte Schutzbedarfsfeststellung ist jede Bewertung angreifbar.
• Keine Werkzeuge für die Bewertung. Die Bibliothek liefert die Anforderungen, nicht die Arbeitsblätter und nicht die Nachweisführung. Das muss jeder selbst bauen. Einen Anfang für die Arbeitsblätter habe ich mit grundschutz-worksheets veröffentlicht.
• Kleine Betriebe müssen streichen. Manche Anforderung setzt eine Organisation mit mehreren Rollen voraus. Mit einer Person im Betrieb braucht es eine begründete Anpassung, keine blinde Übernahme.

Mein Fazit zur Bewertung: Grundschutz++ taugt als Maßstab für ein ISMS nach ISO 27001, gerade in kleinen Betrieben. Den größten Nutzen hat, wer die Prüfung nicht als Formular behandelt. Man sollte sie als Messung behandeln.

11 — Die Serie im Überblick

Bisher liest die Prüfung OSCAL nur. Der Katalog kommt als Datensatz, die Antworten stehen noch als Text im Handbuch. Die Serie dreht das Schritt für Schritt um: Der Betrieb beschreibt sich selbst in OSCAL, erzeugt aus dem, was ohnehin im Repository steht.

1. Grundschutz++ gegen die eigene Dokumentation: die Methode, der Katalog als Datenmodell, der Abgleich mit IaC und GitOps. Dieser Beitrag.
2. Die Anwendbarkeit als Datensatz: die eigene Auswahl aus Grundschutz++ als OSCAL-Profil, erzeugt aus der Anwendbarkeitserklärung.
3. Container, die sagen, welche Anforderungen sie erfüllen: eine signierte Komponentendefinition an jedem Image, das die Pipeline baut.
4. Messung als Nachweis: nächtliche Prüfungen schreiben ihre Ergebnisse als OSCAL. Dazu die zweite Ebene, die im laufenden System findet, was kein Repository kennt.
5. Das ISMS als Build-Produkt: ein Sicherheitsplan, der zusammengebaut statt geschrieben wird, mit einer ehrlichen Bilanz des Aufwands.

Ein Teil erscheint erst, wenn der beschriebene Schritt im Betrieb läuft und gemessen ist. Der Code dazu liegt vorher in grundschutz-worksheets. Die Titel werden hier verlinkt, sobald der jeweilige Beitrag online ist.

Fazit

Die Prüfung gegen Grundschutz++ hat weniger fehlende Maßnahmen gefunden als erwartet. Sie hat vor allem gezeigt, wo die Doku nicht mehr zum System passt. Das ist der Teil, der in einem ISO-27001-Audit am meisten kostet. Die Anwendbarkeitserklärung liefert die Prüfliste, das Mapping der Bibliothek liefert die Anforderungen. Weil jede Anforderung als Datensatz mit Zielobjekt und Handlungswort vorliegt, lässt sich ein großer Teil direkt gegen IaC- und GitOps-Repositories beantworten. Den Rest erledigt eine einfache Regel: nur messen, was das System zeigt, und jede Aussage mit Datum versehen.

Weiter mit Teil 2: Die Anwendbarkeit als Datensatz.