Grundschutz++ als Code, Teil 5: Das ISMS als Build-Produkt

01 — Vier Dokumente, vier Fragen

OSCAL hält auseinander, was in vielen Sicherheitskonzepten ineinanderläuft. Für jede Frage gibt es ein eigenes Modell:

• System Security Plan: „So machen wir es.“ Wie das System jede Anforderung umsetzt, in den Worten des Betreibers.
• Assessment Plan: „So prüfen wir es.“ Welche Prüfung was untersucht und wie oft.
• Assessment Results: „Das haben wir gefunden.“ Befunde je Anforderung, mit Beleg. Das war Teil 4.
• Plan of Action and Milestones: „Das beheben wir, und bis wann.“

Im Grundschutz entspricht das erste dem Sicherheitskonzept mit dem IT-Grundschutz-Check, das dritte dem Revisions- oder Auditbericht. Dass beide getrennt bleiben, hat einen einfachen Grund. Wer prüft, ob eine Aussage stimmt, darf sie nicht nebenbei umschreiben.

02 — Das Sicherheitskonzept ist ein Anspruch

Zu jeder anwendbaren Anforderung sagt mein Konzept, ob sie umgesetzt, teilweise umgesetzt oder geplant ist. Daneben steht, worauf die Aussage beruht. In der Regel ist das mein datiertes Urteil aus der Anwendbarkeitsprüfung, das ein kleines Werkzeug aus der Statusspalte der Paketseiten im Handbuch liest. Fehlt ein Urteil, zählt der Anspruch einer Komponente mit Belegen, etwa der Images aus Teil 3. Und wo gar nichts spricht, ist die Anforderung geplant. Das Konzept schreibt das ausdrücklich hin.

Komponentendefinitionen bringen ihre Beschreibung und ihre Belege zu jeder Anforderung mit, die sie beanspruchen. Ein Urteil heben sie trotzdem nie an. Ein Image weiß, was bei seinem Build vorhanden war, über das ganze System weiß es nichts.

Neu ist das Inventar. Was der Infrastruktur-Code deklariert, steht als Eintrag im Konzept, bei mir zunächst die DNS-Einträge aus dem OpenTofu-State. So listet das Konzept, was laut Code existiert, und keine Erinnerung daran.

node ssp.mjs system.json > ssp.json
node validate.mjs ssp.json

03 — Erst das vorhandene Werkzeug

Bevor ich einen eigenen Generator geschrieben habe, habe ich es mit compliance-trestle versucht, dem bekanntesten Open-Source-Werkzeug für OSCAL. Version 5.1.0 liest Profil, Katalog, Komponentendefinition und Ergebnisse ohne Probleme und löst das Profil korrekt auf.

Beim Zusammenbau des Plans passte es für meinen Fall aber nicht:

• Es lehnt UUIDs der Version 5 ab, also genau die deterministischen Kennungen, auf denen die ganze Serie aufbaut.
• Die Links der beanspruchten Anforderungen, also die Belege, gehen verloren.
• Die verschachtelten Gruppen des BSI-Katalogs werden flachgeklopft.

trestle läuft deshalb nur noch als beratende Prüfung in der CI mit, daneben das oscal-cli des NIST. Beide sagen, ob sie lesen können, was ich schreibe. Den Build halten sie nicht an.

04 — Der erste Zusammenbau fand Lücken im Geltungsbereich

Ein Plan, der zusammengebaut wird, meldet etwas, das ein geschriebener nie meldet: eine Anforderung, die eine Quelle nennt, die das Profil aber nicht enthält.

Beim ersten Lauf waren es drei. Zwei hatten die Images für sich beansprucht, eine wurde gemessen. Im Profil fehlten alle drei, weil es aus der Zuordnung zu ISO 27001 abgeleitet war und diese Anforderungen dort nicht vorkamen.

Jede solche Meldung hat zwei mögliche Antworten. Entweder fehlt die Anforderung im Profil, oder die Quelle beansprucht etwas außerhalb des Geltungsbereichs. Hier war es das Erste, und die drei Anforderungen stehen jetzt in der Anwendbarkeitsprüfung. Bemerkt hätte das beim Schreiben niemand.

05 — Der Fehler: Anspruch und Urteil vermischt

Meine erste Fassung hatte eine Rangfolge. Was gemessen ist, schlägt, was beansprucht ist, und das schlägt das Urteil von Hand. Das klang genau nach dem Ziel der Serie: Fakten statt Behauptungen.

Der erste Plan aus der Pipeline hat mich eines Besseren belehrt. Zwei Anforderungen standen auf der Paketseite als „teilweise“, jede mit einem Grund daneben. Inzwischen wurden beide gemessen, beide Messungen waren grün, und im Plan stand plötzlich „umgesetzt“. Nur hatten die Prüfungen etwas ganz anderes angesehen als das, woran mein Urteil hing. Eine Backup-Prüfung sieht, ob die Kopien frisch sind. Ob sie weit genug vom Original entfernt liegen, sieht sie nicht.

Ich habe die Regel nachgebessert, erst für Messungen und dann für die Ansprüche von Komponenten. Geholfen hat beides nur halb, denn die Schieflage blieb: Ein Prüfergebnis konnte meine Aussage umschreiben. Gelöst hat es erst die Trennung, die OSCAL ohnehin vorsieht.

Heute bestimmt allein mein Urteil, was im Konzept steht. Zu jeder Anforderung nennt es das letzte Prüfergebnis mit Datum. Widerspricht das Ergebnis, bekommt die Anforderung einen Vermerk, und die Metadaten zählen mit. Die Aussage bleibt, bis ich sie ändere.

06 — Stichprobe statt Vertrauen

Zum Abschluss dieser Phase habe ich zehn Anforderungen von Hand gegen den Plan geprüft. Fünf davon waren gemessen, drei beansprucht, zwei beruhten nur auf einem Review.

Sieben passten. Eine wich ab, und die Abweichung war richtig: Die Messung hatte eine Lücke gefunden, die auf der Paketseite noch nicht stand. Zwei passten nicht, und das war derselbe Fehler wie in Abschnitt 05, nur von der anderen Seite. Ein Image hatte zwei Anforderungen für sich beansprucht, und der Anspruch hatte das Review auf „umgesetzt“ gehoben.

Eine Komponentendefinition sagt aber, was bei einem Build vorhanden war. Über das ganze System sagt sie nichts. Diese Stichprobe war der zweite Anlass für die Trennung aus Abschnitt 05.

Ohne die Stichprobe wäre das nicht aufgefallen. Der Plan war gültig, deterministisch und signiert, und er stimmte trotzdem an zwei Stellen nicht.

07 — Der Prüfplan

Zwischen Aussage und Ergebnis liegt in OSCAL ein eigenes Dokument, der Prüfplan. Bei mir entsteht er aus derselben Liste, aus der die Prüfungen schon ihre Zuordnung zu Grundschutz++ lesen. Jede Prüfung wird darin zu einer Aktivität mit ihrer Methode, ihrem Gegenstand und den Anforderungen, für die sie Belege liefert. Eine wiederkehrende Aufgabe legt den Takt fest.

node assessment-plan.mjs checks.json > assessment-plan.json
node validate.mjs assessment-plan.json

Jedes Prüfergebnis verweist auf diesen Plan. Wer ein Ergebnis vor sich hat, kann also nachschlagen, wie es entstehen sollte. Verbunden sind die beiden über den Namen der Prüfung, den beide tragen.

08 — Die Brücke zurück: die Statusspalte

Wenn Ergebnisse das Konzept nicht mehr umschreiben, braucht ein Befund einen anderen Weg zum Betreiber. Bei mir ist das ein Merge Request.

Nach jedem Lauf vergleicht ein Werkzeug das Konzept mit den Ergebnissen. Steht eine Anforderung in der Statusspalte als „erfüllt“ und hat die letzte Prüfung sie anders gesehen, schlägt es „teilweise“ vor. Das alte Wort bleibt in Klammern stehen, damit man sieht, was sich bewegt hat. Den Vorschlag lese ich wie jeden anderen Merge Request auch.

Der Weg führt nur nach unten. Eine grüne Prüfung hebt keine Zeile an, weil ich erst abwägen muss, ob sie den Teil trifft, an dem mein Urteil hängt. Belege und Anmerkungen fasst das Werkzeug ohnehin nicht an.

Der erste Vorschlag kam am Tag nach dem Bau. Eine Prüfung hatte ein Projekt mit abweichender Regel gefunden, und das Werkzeug wollte eine Anforderung von „erfüllt“ auf „teilweise“ setzen. Auf der Seite stand davon noch nichts.

09 — Der Maßnahmenplan zeigt, was fehlt

Das letzte Dokument der Kette sagt, was behoben wird und bis wann. Es speist sich aus zwei Richtungen. Zum einen aus meinem eigenen Konzept, überall dort, wo es eine Anforderung als teilweise umgesetzt oder geplant führt. Zum anderen aus den Ergebnissen, wo die letzte Prüfung eine Anforderung nicht als erfüllt gesehen hat. Dann zählt der Befund, auch wenn das Konzept etwas anderes sagt.

Jeder Punkt bekommt ein offenes Risiko. Schließen kann es nur eine Maßnahme aus dem Verbesserungsregister, mit Termin und Status. Die Verbindung ist die Register-Nummer in der Zeile der Paketseite. Steht dort ein Quartal als Termin, gilt dessen letzter Tag. „Laufend“ hat keinen Termin.

node poam.mjs poam.json > poam-out.json
node validate.mjs poam-out.json

Ein Datum erfindet das Werkzeug nicht. Ein Punkt ohne Maßnahme sagt, dass er keine hat, und die Metadaten zählen solche Punkte.

Der erste Lauf war aufschlussreicher, als mir lieb war. Die Anwendbarkeitsprüfung kannte viele Lücken, das Register viele Maßnahmen, aber miteinander verbunden waren nur wenige. Gepflegt wurde beides, nur eben getrennt. Ohne den Maßnahmenplan wäre mir das kaum aufgefallen.

10 — Gebaut, signiert, gesperrt

Alle vier Dokumente entstehen im selben Lauf. Sie werden abgelegt wie die Prüfergebnisse aus Teil 4, als signiertes OCI-Artefakt und als Kopie im gesperrten Bucket.

Signiert wird mit einem Schlüssel, der nur für diese Nachweise da ist. Am Anfang habe ich den Schlüssel der Images benutzt, und das war ein Fehler. Dessen Rolle dürfen viele Pipelines übernehmen, und jede von ihnen hätte ein gefälschtes Ergebnis signieren können, das echt aussieht. Ein Nachweis ist nur so viel wert wie die Liste derer, die ihn signieren dürfen.

So wächst mit jedem Lauf eine Reihe datierter Dokumente. Wer wissen will, wie es an einem bestimmten Tag stand, holt sich genau diese Fassung und prüft die Signatur. Eine nachträglich geschönte Version gibt es nicht.

11 — Was der Betrieb kostet

Wenig. Das war eine Bedingung, denn ein Sicherheitskonzept, das im Betrieb teuer ist, wird früher oder später wieder von Hand gepflegt.

• Rechenzeit: ein paar Minuten CI alle sechs Stunden, im selben Lauf wie die Prüfungen.
• Speicher: ein Bucket mit Objektsperre. Die Dokumente eines Laufs sind zusammen einige hundert Kilobyte groß und löschen sich nach 400 Tagen selbst.
• Aufmerksamkeit: ab und zu ein Merge Request mit einem Vorschlag für die Statusspalte. Manche schließe ich wieder.

Was bleibt, sind die Urteile. Reviews und Register muss weiter jemand pflegen, und die Kette nimmt einem das nicht ab. Sie zeigt nur sehr deutlich, wo es fehlt.

12 — Was die Kette nicht ist

• Kein Zertifikat: Die Dokumente halten fest, was behauptet, geprüft, gefunden und geplant ist. Ob das für ein Audit reicht, entscheidet die Auditorin.
• Noch überwiegend von Hand: Geprüft wird bisher nur ein kleiner Teil der Anforderungen, für den Rest gilt mein Urteil. Mit jeder neuen Prüfung verschiebt sich das ein Stück.
• Blind für das Unbeschriebene: Alles in der Kette steht irgendwo geschrieben. Was läuft, ohne beschrieben zu sein, taucht darin nicht auf. Darum geht es im nächsten Teil.

13 — Die Serie im Überblick

1. Grundschutz++ gegen die eigene Dokumentation: die Methode, der Katalog als Datenmodell, der Abgleich mit IaC und GitOps.
2. Die Anwendbarkeit als Datensatz: die Anwendbarkeitserklärung als OSCAL-Profil.
3. Container, die sagen, welche Anforderungen sie erfüllen: eine signierte Komponentendefinition an jedem Image, das die Pipeline baut.
4. Messung als Nachweis: Prüfungen schreiben ihre Ergebnisse als OSCAL, datiert, signiert, nicht löschbar.
5. Das ISMS als Build-Produkt: Konzept, Prüfplan, Ergebnis und Maßnahmenplan als OSCAL-Kette, bei jeder Messung neu gebaut. Dieser Beitrag.
6. Was kein Repository weiß: die zweite Ebene, das laufende System gegen seinen Code.
7. Ein Nachweis, viele Standards: NIS2, DORA, C5 und SOC 2 als Mappings auf Grundschutz++.
8. Die Kette zum Mitnehmen: allgemeine Checks, der Bericht über einen Zeitraum und eine Vorlage, die alles zusammenschaltet.

Die Teile 1 bis 6 beschreiben, was in meinem ISMS läuft. Sie erscheinen erst, wenn der Schritt im Betrieb läuft und gemessen ist. Die Teile 7 und 8 zeigen Werkzeuge, die ich nach dem Feedback beim InfoSec-Stammtisch gebaut habe und selbst nicht einsetze. Der Code liegt in grundschutz-worksheets. Eine Karte der ganzen Serie zeigt OSCAL in der Praxis: acht Modelle, eine Kette.

Fazit

Ein Sicherheitskonzept, das sich selbst baut, ist schnell erklärt. Schwerer war, es nicht mehr sagen zu lassen, als es weiß. Solange Prüfergebnisse meine Aussage umschreiben konnten, behauptete das Konzept Dinge, die ich nie behauptet hätte. Gelöst hat das erst die Trennung, die OSCAL ohnehin vorsieht. Ich sage, wie es ist. Die Prüfungen sagen, was sie sehen. Und was dazwischen liegt, landet als Merge Request bei mir.

Weiter mit Teil 6: Was kein Repository weiß.