Grundschutz++ als Code, Teil 2: Die Anwendbarkeit als Datensatz

01 — Warum die Anwendbarkeitserklärung zuerst

Jeder weitere Schritt der Serie braucht eine Antwort auf dieselbe Frage: Welche Anforderungen gelten überhaupt? Eine Komponente beschreibt, welche Anforderungen sie abdeckt. Eine Messung prüft, ob eine Anforderung erfüllt ist. Ein Sicherheitsplan fasst beides zusammen. Alle drei beziehen sich auf eine Auswahl aus dem Katalog.

Diese Auswahl gibt es schon. ISO 27001 verlangt sie in Abschnitt 6.1.3 d als Anwendbarkeitserklärung. Über das Mapping der Bibliothek wird daraus eine Liste von Grundschutz++-Anforderungen, wie in Teil 1 gezeigt. Solange diese Liste nur als Text existiert, muss jedes Werkzeug sie neu erraten. Deshalb ist sie das erste Dokument, das OSCAL werden sollte.

02 — Was ein OSCAL-Profil ist

Ein Katalog enthält alle Anforderungen. Ein Profil wählt daraus aus und passt an. Es verweist auf den Katalog, nennt die Anforderungen, die gelten, und kann Parameter setzen oder Texte ergänzen. Das Ergebnis lässt sich wieder zu einem Katalog auflösen, der nur noch die Auswahl enthält.

Das BSI nutzt genau diesen Mechanismus selbst. Der Anwenderkatalog von Grundschutz++ ist ein aufgelöstes Profil über mehrere Quellkataloge der Bibliothek (Kernel-G0, Methodik, Teile des Risikomanagements). Ein eigenes Profil setzt also nur eine Ebene tiefer an. Gekürzt sieht es so aus:

{
  "profile": {
    "uuid": "…",
    "metadata": {
      "title": "Grundschutz++ tailoring of Example GmbH",
      "last-modified": "2026-09-27T00:00:00Z",
      "version": "2026-09-27",
      "oscal-version": "1.1.3"
    },
    "imports": [{
      "href": "https://raw.githubusercontent.com/BSI-Bund/Stand-der-Technik-Bibliothek/367d775…/control_layer/Grundschutz%2B%2B/Grundschutz%2B%2B-resolved_catalog.json",
      "include-controls": [{
        "with-child-controls": "no",
        "with-ids": ["DET.2.1", "DET.3.1", "KONF.3.2", "…"]
      }]
    }],
    "merge": { "as-is": true }
  }
}

Zwei Dinge fallen auf. Der Katalog ist über einen festen Commit eingebunden, nicht über die aktuelle Fassung. Und das Profil nennt Kennungen, keine Texte. Die Texte des BSI bleiben im Katalog, das Profil verweist nur darauf.

03 — Vom Dokument zum Profil

Die Anwendbarkeitserklärung von Hand in JSON abzuschreiben, wäre der Fehler aus Teil 1 in neuer Form. Dann gäbe es zwei Kopien, und eine davon wäre bald falsch. Das Profil wird deshalb erzeugt, und zwar in zwei Hälften.

• Ein Leser für die eigene Doku: Er kennt das Format der eigenen Tabellen und macht daraus eine kleine Auswahldatei. Er ist spezifisch und bleibt deshalb im eigenen Repository.
• Ein Generator für das Profil: Er kennt nur die Auswahldatei und OSCAL. Er ist allgemein und liegt öffentlich in grundschutz-worksheets.

Die Auswahldatei ist bewusst schlicht:

{
  "title": "Grundschutz++ tailoring of Example GmbH",
  "version": "2026-09-27",
  "last-modified": "2026-09-27T00:00:00Z",
  "catalog": {
    "path": "control_layer/Grundschutz++/Grundschutz++-resolved_catalog.json",
    "commit": "367d775010abee641b258926bb482fcd05270059"
  },
  "applicable": ["DET.2.1", "KONF.3.2"],
  "not-applicable": [{ "id": "ARCH.6.1", "reason": "keine eigenen WAN-Strecken" }]
}

git clone github.com/ohartwig/grundschutz-worksheets
cd grundschutz-worksheets
npm ci   # nur für validate.mjs

C=367d775010abee641b258926bb482fcd05270059
CAT=control_layer/Grundschutz++/Grundschutz++-resolved_catalog.json

node profile.mjs auswahl.json > profil.json
node validate.mjs profil.json
node worksheet.mjs $CAT --profile profil.json --commit $C

Die letzte Zeile schließt den Kreis. Das Arbeitsblatt aus Teil 1 liest jetzt das Profil statt einer Liste von Anhang-A-Maßnahmen. Heraus kommen genau die Anforderungen, die gelten. Beim Schreiben waren es bei mir 257 von 280.

Nichts fällt still heraus

• Jede Kennung wird gegen den Katalog am festen Commit geprüft. Eine unbekannte Kennung ist ein Fehler.
• Eine Kennung, die doppelt vorkommt oder zugleich gilt und nicht gilt, ist ein Fehler.
• Eine Tabellenzeile, die der Leser nicht versteht, bricht den Lauf ab. Sonst fehlt sie einfach im Profil.

Der letzte Punkt hat sich gleich beim ersten Lauf ausgezahlt. Zwei Zeilen trugen in der Spalte für das Niveau einen Zusatz, den das erste Muster nicht kannte. Heraus kamen 278 statt 280 Anforderungen, ohne jede Warnung.

04 — Die Lücke im Format: nicht anwendbar, weil …

Eine Anwendbarkeitserklärung sagt nicht nur, was gilt. Sie sagt auch, was nicht gilt, und warum. Genau dafür hat ein OSCAL-Profil kein Feld. Es kann Anforderungen einschließen oder ausschließen, aber nicht begründen.

Es gibt drei Auswege:

• Ausschließen ohne Grund: formal sauber, aber die Begründung geht verloren. Für ISO 27001 ist sie der eigentliche Inhalt.
• Ein Freitext in den Metadaten: lesbar für Menschen, nicht für Werkzeuge.
• Ein Back-Matter-Eintrag pro Ausschluss: OSCAL erlaubt Ressourcen im Back-Matter, dem Anhang eines Dokuments. Jede trägt Titel, Begründung und eine Kennung, markiert mit einem eigenen Namensraum.

Ich habe den dritten Weg gewählt:

"back-matter": {
  "resources": [{
    "uuid": "…",
    "title": "Not applicable: ARCH.6.1",
    "description": "keine eigenen WAN-Strecken",
    "props": [
      { "name": "control-id", "ns": "https://github.com/ohartwig/grundschutz-worksheets/ns", "value": "ARCH.6.1" },
      { "name": "tailoring", "ns": "https://github.com/ohartwig/grundschutz-worksheets/ns", "value": "not-applicable" }
    ]
  }]
}

OSCAL sieht diese Aussage eigentlich im Sicherheitsplan vor. Den gibt es erst in Teil 5. Bis dahin steht die Begründung im Profil, maschinenlesbar und gegen das Schema gültig.

Geltung ist nicht Erfüllung

Eine Anforderung, die gilt, aber noch offen ist, bleibt im Profil. Ob etwas gilt und ob es erfüllt ist, sind zwei Fragen. Die erste beantwortet das Profil. Die zweite beantworten Messungen, und die kommen in Teil 4. Wer beides in eine Datei mischt, bekommt eine Anwendbarkeitserklärung, die sich mit jedem Befund ändert.

05 — Deterministisch erzeugen

Ein erzeugtes Dokument ist nur dann prüfbar, wenn dieselbe Eingabe dieselben Bytes liefert. Sonst zeigt jeder Merge Request einen Diff über die ganze Datei, und niemand liest ihn.

• Kennungen aus dem Inhalt: OSCAL verlangt eine UUID für jedes Dokument und jede Ressource. Der Generator leitet sie aus dem Inhalt ab, statt sie zu würfeln.
• Datum aus der Quelle: Das Datum im Profil stammt nicht von der Uhr, sondern aus der Doku selbst. Bei mir ist es das Bearbeitungsdatum der Tabellenseiten, das bei jeder Änderung ohnehin nachgezogen wird.
• Feste Reihenfolge: Kennungen werden sortiert, und zwar numerisch. KONF.10 steht hinter KONF.9.

Die Probe darauf ist einfach. Eine einzige Anforderung auf „nicht anwendbar“ gesetzt, und der Diff zeigt genau das: die Kennung verschwindet aus der Auswahl, ein Back-Matter-Eintrag kommt dazu, zwei Zähler ändern sich. Sonst nichts.

Die Pipeline prüft das bei jeder Änderung. Sie erzeugt das Profil neu und vergleicht es mit der eingecheckten Fassung. Weicht es ab, ist der Merge Request rot. Eine geänderte Tabelle ohne neues Profil kommt so nicht durch, eine Handkorrektur am JSON auch nicht.

06 — Prüfen gegen das Schema

NIST veröffentlicht zu jeder OSCAL-Version ein JSON-Schema. Das Werkzeug validate.mjs prüft jede Datei gegen das Schema der Version, die sie selbst angibt. Das ist nötig, weil die Bibliothek des BSI mehrere Versionen mischt: Kataloge und Profile in 1.1.3, das Mapping und neuere Komponentendefinitionen in 1.2.2, ältere Komponentendefinitionen noch in 1.1.2. Nicht jede Datei der Bibliothek besteht die Prüfung. Zwei Komponentendefinitionen und das ISO-Mapping selbst weichen vom Schema ihrer Version ab.

• Feste Schemas: Die Schemas liegen unverändert aus den NIST-Releases im Repository und werden gegen eine SHA-256-Prüfsumme geprüft.
• Unbekannt ist ein Fehler: Eine Datei mit einer Version, für die kein Schema hinterlegt ist, besteht die Prüfung nicht. Sie wird auch nicht übersprungen.
• Kaputte Beispiele: Die Tests enthalten absichtlich ungültige Dateien. Sie müssen durchfallen. Ein Validator, der nie rot wird, prüft nichts.

Ein Hinweis aus der Praxis für alle, die ihre CI-Runner nur mit IPv6 betreiben: github.com und die Downloads der Releases haben keine IPv6-Adresse, raw.githubusercontent.com schon. Der Check im eigenen Repository lädt deshalb nur den abhängigkeitsfreien Generator über raw.githubusercontent.com. Die Prüfung gegen das Schema läuft beim Erzeugen und in der CI des öffentlichen Repositorys.

07 — Was das Profil jetzt trägt

Das Profil ist klein und unspektakulär. Genau das macht es nützlich. Jeder weitere Schritt kann sich darauf beziehen, statt die Auswahl neu zu bestimmen.

• Arbeitsblätter: genau für den eigenen Geltungsbereich, ohne Umweg über das Mapping.
• Komponenten (Teil 3): Welche Anforderungen aus dem Profil deckt ein Image ab, das die Pipeline gebaut hat?
• Messungen (Teil 4): Welche Anforderungen aus dem Profil hat die nächtliche Prüfung heute belegt?
• Sicherheitsplan (Teil 5): Profil, Komponenten und Messungen zusammengeführt, mit den Begründungen dort, wo OSCAL sie vorsieht.

08 — 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. Dieser Beitrag.
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 Anwendbarkeitserklärung ist das kleinste OSCAL-Dokument mit der größten Wirkung. Sie legt fest, worauf sich alles andere bezieht. Als Profil wird sie aus der eigenen Doku erzeugt, gegen den Katalog und das Schema geprüft und bei jeder Änderung neu verglichen. Die Lücke im Format für begründete Ausschlüsse lässt sich sauber überbrücken, bis der Sicherheitsplan sie aufnimmt.

Weiter mit Teil 3: Container, die sagen, welche Anforderungen sie erfüllen.