grundschutz-worksheets — der Grundschutz++-Katalog des BSI als Prüfliste und OSCAL-Kette.
Das BSI veröffentlicht Grundschutz++ maschinenlesbar, als OSCAL. grundschutz-worksheets macht daraus eine Zeile pro Anforderung, sortierbar nach der Art des Nachweises. Dazu schreibt es die OSCAL-Dokumente eines ISMS: Profil, Sicherheitsplan, Prüfplan, Prüfergebnisse und POA&M. Geprüft wird gegen das laufende System, nicht gegen die eigene Doku.
- Im Einsatz: in meinem eigenen ISMS, für Profil, Sicherheitsplan, Prüfplan, Prüfergebnisse und POA&M. Die Mappings auf NIS2, DORA, C5 und SOC 2 sind gebaut, aber nicht im Einsatz und ungeprüft.
- Version: v1.7.0, getestet an einem festen Commit der BSI-Bibliothek
- Voraussetzung: Node 24 oder neuer;
worksheet.mjsbraucht keine Installation - Lizenz: MIT · die Kataloge © BSI, CC BY-SA 4.0, zur Laufzeit geladen
Die Prüfung, die sich nicht wiederholen lässt
Bisher
- Die Anforderungen stehen in PDFs und Tabellen, die man von Hand abgleicht
- Welcher Stand des Katalogs galt, steht nirgends
- Der Sicherheitsplan ist ein Text, den jemand schreibt und der veraltet
- Was nicht anwendbar ist und warum, steht in einem anderen Dokument
Mit grundschutz-worksheets
- Eine Zeile pro Anforderung, mit Modalverb, Tätigkeitswort und Art der Dokumentation, als Markdown-Checkliste oder CSV
- Jede Ausgabe nennt den Commit der BSI-Bibliothek; ein Lauf gegen einen neueren Commit zeigt im Diff, was sich geändert hat
- Der Sicherheitsplan wird aus Profil, Komponentendefinitionen und Prüfergebnissen zusammengesetzt; gleiche Eingaben ergeben gleiche Bytes
- Nicht anwendbare Anforderungen stehen mit Begründung im Profil
Passt das zu meinem ISMS?
Nutze es wenn …
- du dein ISMS an Grundschutz++ ausrichtest oder deine ISO-27001-Anwendbarkeitserklärung darauf abbilden willst
- du eine Prüfung wiederholbar machen willst, an einem festen Stand des Katalogs
- du Nachweise aus dem Betrieb sammelst und sie als OSCAL ablegen willst
- dir Kommandozeile und JSON-Dateien reichen
Nutze es nicht wenn …
- du ein fertiges Urteil oder eine Zertifizierung erwartest: Das Werkzeug bewertet nichts für dich und ist keine Rechtsberatung
- du dich auf die Mappings für NIS2, DORA, C5 oder SOC 2 stützen musst: Sie sind ungeprüfte Entwürfe und vor jedem Audit gegen die Originaltexte zu prüfen
- du eine Oberfläche mit Benutzern, Rollen und Freigaben suchst
- du gegen „den neuesten Stand“ prüfen willst: Ohne Commit läuft nichts
Warum eine Zeile pro Anforderung
Das BSI veröffentlicht Grundschutz++ in der Stand-der-Technik-Bibliothek. Jede Anforderung ist ein JSON-Objekt mit fester Grammatik: ein Gegenstand, ein Modalverb (MUSS, SOLLTE, KANN), ein Tätigkeitswort und die Art der Dokumentation, in die der Nachweis gehört. Das Werkzeug macht daraus flache Zeilen. Danach lässt sich sortieren, welche Art von Nachweis eine Anforderung braucht.
Viel verrät schon das Tätigkeitswort. „Aktivieren“ oder „verschlüsseln“ verlangt eine Konfiguration und eine Messung, dass sie wirkt. „Überprüfen“ oder „testen“ verlangt einen datierten Lauf. „Verankern“ oder „dokumentieren“ verlangt ein Dokument. Wie ich so meine eigene Doku geprüft habe, steht im Blogbeitrag dazu. Wie daraus die OSCAL-Kette wurde, beschreibt die Reihe Grundschutz++ als Code.
Zwei Regeln sind eingebaut. Ohne Commit der Bibliothek läuft nichts, denn sie erscheint laufend neu. Und nichts fällt still weg: Mapping-Ziele, die der Katalog nicht kennt, stehen am Ende auf stderr.
So entsteht eine Prüfliste
Ein Preset nennt Katalog, Mapping und den Commit, an dem das Repository getestet ist. Elf gibt es, vom ganzen Katalog bis zu SOC 2:
node worksheet.mjs --presets
node worksheet.mjs --preset iso27001 --sources @soa.txt --format csv
node worksheet.mjs --preset gspp --levels normal-SdT --summary
Eine Zeile der Markdown-Checkliste sieht so aus:
- [ ] **KONF.2.1** Grundkonfiguration für Systeme · normal-SdT · SOLLTE · dokumentieren
Konfiguration für IT-Systeme SOLLTE eine Grundkonfiguration dokumentieren.
Aus der Anwendbarkeit wird ein OSCAL-Profil, aus einem Lauf einer Prüfung ein Prüfergebnis. Jedes Dokument wird gegen das NIST-Schema validiert:
node profile.mjs tailoring.json > profile.json
node results.mjs run.json > results.json
node validate.mjs profile.json results.json
Das Profil nennt den Katalog mit seiner SHA-256-Prüfsumme. Nicht anwendbare Anforderungen stehen dort mit Begründung, ebenso deine Werte für die Platzhalter des Katalogs: [jährlich] statt [regelmäßig].
Die Dokumentation
Presets und Mappings
Elf benannte Prüfumfänge: der ganze Katalog, ISO 27001 und IT-Grundschutz über die Mappings des BSI. Dazu NIS2, die Durchführungsverordnung, DORA, C5 und SOC 2 als ungeprüfte Entwürfe.
Die OSCAL-Kette
Profil aus der Anwendbarkeit, Komponentendefinition pro Build, Sicherheitsplan, Prüfplan, Prüfergebnisse und POA&M. Dazu Abdeckung pro Standard und der Bericht über einen Zeitraum.
Versionen
aktuell v1.7.0
Jede Version als Tag vX.Y.Z, getestet und gegen das NIST-Schema validiert am Commit der BSI-Bibliothek, den tools/bsi-library.mjs nennt.
GitHub
Node 24 oder neuer
Quellcode, Changelog, Issues. Ein Pull Request wird auf GitHub nicht gemergt, die Änderung übernehme ich von Hand. MIT.
Grundschutz++ im eigenen ISMS?
Ich helfe beim Einstieg: die Anwendbarkeit als Profil, erste Prüfungen aus dem Betrieb, ein Sicherheitsplan aus Daten statt aus Text.