Grundschutz++ braucht spezialisierte Tools

Grundschutz++ braucht spezialisierte Tools

Irgendeinen PDF-Reader verwenden wir vermutlich alle, und niemand würde hierin ein spezialisiertes Tool sehen. PDF ist der De-facto-Standard für den Austausch elektronischer Dokumente. Daher ist es nur folgerichtig, dass Veröffentlichungen des BSI ebenfalls im PDF-Format erfolgen. So auch das noch gültige IT-Grundschutz-Kompendium. Für die in den Startlöchern befindliche Modernisierung GS++ geht das BSI einen neuen Weg. Statt menschenlesbarer Prosa in ellenlangen Dokumenten werden Sicherheitsanforderungen künftig maschinenlesbar im JSON-Format auf Basis von OSCAL in der sogenannten Stand-der-Technik-Bibliothek (SdT) über ein Github-Repository des BSI bereitgestellt.

Maschinenlesbarkeit bedeutet in der menschlichen Praxis: Eine JSON-Datei mit wenigen Zeilen ist noch halbwegs übersichtlich und lässt sich auch in einem Texteditor lesen – die mittlerweile über 90.000 Zeilen des Anwenderkatalogs Grundschutz++ bereiten auf diesem Wege dagegen keine Freude. Eine spezialisierte Toolunterstützung ist dringend notwendig. Über die Schwierigkeiten im Umgang mit dem neuen Format haben meine Kollegen bereits letztes Jahr berichtet. Seitdem hat die GS++-Community eine Handvoll weiterer Tools entwickelt, die besonders die erste Durchsicht unterstützen:

• Stand-der-Technik-Viewer, Open Source, kann als HTML-Datei lokal ausgeführt werden, entwickelt von der Arbeitsgruppe Werkzeugbox des BSI. Bietet umfangreiche Filtermöglichkeiten der Anforderungen z.B. nach Zielobjektkategorie oder Dokumentationsempfehlung, zusätzlich Visualisierung von Abhängigkeiten und Vererbung und erlaubt einen systematischen Überblick.
• Grundschutz-++-Tools (mittlerweile umgezogen), open-source, als HTML-Datei lokal ausgeführt, ursprünglich entwickelt von der Arbeitsgruppe Nutzergenerierte Inhalte. Der zur Verfügung gestellte Viewer bietet weniger Filtermöglichkeiten, ist ansonsten vergleichbar mit dem vorherigen. Zusätzlich werden weitere erste Tool-Ideen entlang der Arbeitsschritte nach den BSI-Anforderungen an OSCAL zur Verfügung gestellt.
• Grundschutz-Navigator.de, nicht Open Source, wird nicht lokal ausgeführt, Daten verbleiben aber lokal. Bietet nur eine rudimentäre Suchfunktion. Dafür am einfachsten im Handling, da Kataloge automatisch geladen werden.

Den GS++-Katalog sollte nun jeder interessierte Anwender durchblättern können. Die tatsächliche GS++-Anwendung im ISMS-Umfeld erfordert jedoch mehr als die bloße Durchsicht des Katalogs und seiner Anforderungen. Im Rahmen der Modellierung des Informationsverbundes  müssen im Rahmen von Prozessschritt 2 des Sicherheitsprozesses konkrete Anforderungspakete für die verwendeten Assets geschnürt werden, bestehend aus den tatsächlich anwendbaren und umzusetzenden Anforderungen des Katalogs für den Informationsverbund. Deren Umsetzung und Status müssen erfasst werden, gegebenenfalls unter Bezugnahme auf Komponentendefinitionen des BSI, sog. Implementierungsbeschreibungen. Abschließend muss zur Überprüfung eine entsprechend übergabefähige und vor allem prüfbare Dokumentation erstellt werden können, z.B. für interne oder externe Audits im Rahmen einer ab 01.01.2027 möglichen Zertifizierung. Und all das gerade nicht als PDF-Stapel, der händisch auditiert werden muss, sondern in maschinenlesbarer Form, um den Hebel der Automation überhaupt nutzbar zu machen. Für all das mangelt es bislang an geeigneten Tools.

BSI-Ausschreibung P1013 – das Verfahren

Um diese Lücke zu schließen, schreibt das BSI die Entwicklung von zwei Software-Artefakten aus: SdT-Editor und SdT-Generator. Achtung: Die Teilnahmefrist der Ausschreibung war der 22.06.2026. Zum Zeitpunkt der Veröffentlichung dieses Beitrags sind die Unterlagen nicht mehr öffentlich einsehbar, liegen dem Autor dieses Beitrags jedoch vor. Es folgt eine Beschreibung des Vergabeverfahrens sowie der ausgeschriebenen Tools und etwaiger Rückschlüsse, die sich daraus ziehen lassen.

Als Verfahrensart wählt das BSI das Verhandlungsverfahren mit vorgeschaltetem Teilnahmewettbewerb. Zur Verhandlungsphase mit max. 2 Verhandlungsrunden werden die 3 besten Bewerber eingeladen. Alleine aufgrund der Verfahrenskomplexität ist mit einer längeren Verfahrensdauer zu rechnen. Verfahrensfristen gehen aus den Unterlagen der Phase des Teilnahmewettbewerbs nicht hervor, lassen sich jedoch abschätzen.

Ins Blaue hinein könnte man von ca. 3 Wochen für die Auswertung der Teilnahmeanträge und anschließende Aufforderung zum Angebot ausgehen, je nach Anzahl eingegangener Bewerbungen. In offenen Verfahren des BSI liegen erfahrungsgemäß 4-6 Wochen zwischen Veröffentlichung und Angebotsfrist, je nach Komplexität des zu erstellenden Angebots, sowie anschließend 3 Monate zwischen Angebotsabgabe und Zuschlagserteilung. Je nach Inhalt und Komplexität der im vorliegenden Verfahren gewählten Verhandlungen und zu erstellenden Folgeangeboten könnten je anschließende Verhandlungsrunde 3-6 Wochen realistisch erscheinen (vgl. ufab 2018, Kap. 13). Optimistisch gerechnet wäre im Q3 eine Zuschlagserteilung möglich, pessimistisch läuft es auf Ende dieses Jahres hinaus.

Die Projektlaufzeit beträgt 8 Monate. In der optimistischen Zeitplanung wäre etwa im Mai 2027 mit der Fertigstellung der ausgeschriebenen Tools zu rechnen. Im pessimistischen Szenario wäre es der September. Schnellstarter, die das Projekt GS++-Zertifizierung als guten Neujahrsvorsatz 2027 angehen möchten, sollten nicht mit den BSI-Tools rechnen. Alle anderen, und vor allem diejenigen, die nicht zertifizieren müssen, werden dagegen genügend Zeit haben, sich mit dem neuen Angebot vertraut machen zu können.

SdT-Editor und SdT-Generator

Bei den ausgeschriebenen Tools soll es sich um Web-Anwendungen handeln. Die Anwendungen müssen dabei ausdrücklich als Offline-Produkte bereitgestellt werden können, was als KO-Kriterium festgehalten wird. Im Sinne der digitalen Souveränität macht man sich so von vorneherein von Drittressourcen unabhängig, die für einen reinen Onlinebetrieb nötig wären. Zusätzlich wird die Expertise in der Entwicklung solcher offlinefähigen Web-Anwendungen bei der Auswahl der Teilnehmer honoriert. Analoge Anforderungen in Richtung Open Source, die man hätte erwarten können, gibt es aber nicht.

Etwas verwunderlich: Das BSI schreibt nur die Tool-Entwicklung aus. Anschließende Wartung, Instandhaltung oder Bugfixing sind nicht Teil des Auftrags. Das Projekt endet mit den „funktionsfähige[n] Anwendungen in einem abnahmefähigen Zustand, einschließlich der Dokumentation in einem abnahmefähigen Zustand.“ Wobei die Dokumentation die Weiterentwicklung der Anwendung beschreiben muss. Es ist unklar, wer diese Weiterentwicklung übernehmen soll. Ein Open-Source-Ansatz könnte die gewachsene GS++-Community dafür miteinbeziehen und zusätzlich z.B. interessante Forks hervorbringen. Dennoch scheint dieser Ansatz aktuell nicht das Mittel der Wahl zu sein.

Der SdT-Editor richtet sich vor allem an GS++-Editoren, d.h. an all diejenigen, die an Erstellung, Bearbeitung und Pflege von Anforderungen, Maßnahmen und Katalogen der Stand-der-Technik-Bibliothek beteiligt sind.

Der SdT-Editor wird daher primär für Mitarbeiter des BSI interessant sein, die aktiv an der inhaltlichen (Weiter-)Entwicklung des Standards und Formulierung von Anforderungen mitwirken. Der Fokus liegt dabei auf einfacher Zugänglichkeit, ohne Fachkenntnisse im OSCAL-Format vorauszusetzen. Das ist insofern wichtig, als nicht allein GS++-Experten des BSI in der Lage sein sollten, Anforderungen erstellen zu können. Im Sinne von derzeitigen IT-Grundschutz-Profilen, die mindestens unter Beteiligung von BSI-externen Branchenvertretern entstehen, oder benutzernutzerdefinierten Bausteinen, muss es auch in Zukunft für Anwender oder Branchenvertreter möglich sein, zusätzliche Anforderungen definieren zu können, nur eben maschinenlesbar.

Die Notwendigkeit einer solchen Funktionalität auch auf Ebene der Anwender unterstreicht Kap. 3.6 „Anforderungsergänzungen“ des GS++-Leitfadens: Sollten für bestimmte Assets im GS++ noch keine Anforderungen existieren oder sich durch externe Compliance-Verpflichtungen weitere ergeben, müssen diese von der Institution erstellt werden.

Der SdT-Generator richtet sich anders als der SdT-Editor hauptsächlich an zukünftige GS++-Anwender und soll für die Auswahl relevanter Anforderungen sowie die Verwaltung, Umsetzung und Dokumentation entsprechender Maßnahmen eingesetzt werden. Anforderungen sollen übersichtlich dargestellt und die Nachvollziehbarkeit von Entscheidungen und Umsetzungsständen unterstützt werden. Der SdT-Generator soll es nicht nur ermöglichen, Anforderungspakete zu schnüren, sondern auch die folgenden Schritte – Realisierung, Überwachung und kontinuierliche Verbesserung des GS++-Leitfadens – umzusetzen und entsprechend zu dokumentieren. Der Generator dürfte damit eine zentrale Schnittstelle zwischen maschinenlesbaren Anforderungen, der menschengemachten Umsetzung und wiederum maschinenlesbarer Dokumentation darstellen. Der Beschreibung nach wird es sich um ein Tool handeln, das die GS++-Umsetzung erheblich erleichtern wird und sich für diese gar als essentiell erweisen könnte.

Fazit

Mit der Ausschreibung von SdT-Editor und -Generator geht das BSI einen wichtigen nächsten Schritt in der Entwicklung von GS++, insbesondere aus Perspektive der Anwender. Auch wenn die Tools zur GS++-Veröffentlichung auf der it-sa 2026 voraussichtlich noch nicht verfügbar sein dürften, sollten sie für anschließende Umsetzungsprojekte früh genug auf dem Markt sein. Wer sich mit öffentlichen Vergaben auskennt, wird wissen, dass Zeitplanung und Verfahrensrealität stark auseinanderdriften können. Drücken wir dem BSI also die Daumen, dass das Vergabeverfahren ohne große Stolpersteine und wie geplant über die Bühne gehen wird.