Grundschutz++: der modernisierte, OSCAL-basierte Ansatz

Problem in der Praxis

Der klassische IT-Grundschutz ist inhaltlich stark, aber sein Transportformat war lange ein Hindernis. Anforderungen, Umsetzungshinweise und Gefährdungen liegen vor allem als Dokument vor; wer sie in ein GRC-Tool oder ein eigenes Steuerungsmodell bringen will, kopiert und pflegt Texte manuell. Die Tool-Abbildung ist bei jedem Hersteller anders, und Mappings zu ISO/IEC 27001 veralten in gepflegten Tabellen. Grundschutz++ adressiert diese Transportlücke und liefert den Grundschutz in einem maschinenlesbaren Standardformat, das Werkzeuge ohne manuelle Nacharbeit verarbeiten können.

CISO-Einordnung

Drei Eigenschaften machen den Kern von Grundschutz++ aus. Erstens das Format: Der Anwenderkatalog liegt in OSCAL vor, dem offenen, von NIST entwickelten Datenmodell für Sicherheitskataloge. OSCAL ist kein Sicherheitsstandard, sondern eine herstellerneutrale Struktur, die den Grundschutz interoperabel mit OSCAL-fähigen Werkzeugen macht.

Zweitens die Gliederung in 20 Themenfelder. Anstelle der klassischen Schichten- und Bausteinlogik ordnet Grundschutz++ die Anforderungen entlang fachlicher Domänen, von Steuerung (Governance, Risikomanagement, Monitoring) über Personal, Berechtigung und Lieferkette bis zu Technik und Betrieb (Architektur, Konfiguration, Entwicklung) und Resilienz (Detektion, Vorfallsbehandlung, Notfallplanung). Diese Navigation liegt näher an der Arbeitsteilung einer Organisation als an einer Objektmodellierung.

Drittens die maschinenlesbaren Metadaten. Anforderungen tragen strukturierte Attribute. Durchgängig vorhanden sind Verbindlichkeitsgrad, Sicherheitsniveau (Stand der Technik gegenüber erhöhten Anforderungen) und Aufwandsklasse; weitere Attribute wie Zielobjekt-Kategorien, Schlagworte und Querverweise sind nur dort gesetzt, wo sie einschlägig sind. Der Anforderungstext liegt je Eintrag vor, in der Regel ergänzt um einen unmittelbar gebündelten Umsetzungshinweis. Das erlaubt automatisiertes Filtern, Priorisieren und Mappen, ohne den Fließtext interpretieren zu müssen. Der Katalog umfasst rund 650 Anforderungen auf der direkten Anforderungsebene unterhalb der Themenfelder (in deren Untergruppen), mit verschachtelten Unteranforderungen knapp tausend; die gemeinte Zählebene sollte man stets angeben.

Umsetzungsperspektive

Für die Praxis bedeutet Grundschutz++ vor allem eine veränderte Werkzeugkette. Der Katalog ist als Datenquelle zu behandeln, nicht als Lektüre. Wer ihn nutzt, sollte zuerst klären, welches GRC- oder ISMS-Werkzeug OSCAL importieren oder anbinden kann; davon hängt ab, ob die Attribute (Aufwand, Sicherheitsniveau, Zielobjekt-Kategorien) als Priorisierungs- und Scoping-Hebel nutzbar werden oder man am Ende doch wieder Texte kopiert.

Die methodische Grundlage bleibt unverändert: Geltungsbereich, Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, IT-Grundschutz-Check und gegebenenfalls Risikoanalyse bleiben die Arbeitsschritte. Grundschutz++ ändert nicht die Methodik, sondern die Form, in der die Anforderungen in sie einfließen.

Typische Fehler

1. Grundschutz++ wird wie ein neuer Inhalt behandelt, obwohl es primär ein neues Format für bekannten Grundschutz ist.
2. Das Format wird beschafft, ohne dass ein Werkzeug existiert, das OSCAL und die Metadaten verarbeitet.
3. Die maschinenlesbaren Attribute werden ignoriert und der Katalog wieder zu manuell gepflegtem Fließtext flachgeklopft.
4. Anforderungszahlen werden ohne Angabe der Zählebene kommuniziert, was zu widersprüchlichen Kennzahlen führt.
5. Aus der Existenz des Katalogs werden Annahmen über Verbindlichkeit oder Zertifizierungsfähigkeit abgeleitet, die nicht durch aktuelle BSI-Quellen gedeckt sind.

Risiken und Trade-offs

Der wichtigste Trade-off betrifft die Reife des Ökosystems: Ein maschinenlesbarer Katalog entfaltet seinen Nutzen erst, wenn Werkzeuge ihn durchgängig unterstützen; solange die Tool-Landschaft uneinheitlich ist, kann der Vorteil teilweise verpuffen. Hinzu kommt die Stabilität: Format und Versionsstand eines jungen Katalogs können sich ändern, weshalb Versionierung und Migrationsfähigkeit einzuplanen sind.

Daneben droht Scheinpräzision: Attribute wie Aufwandsklassen wirken objektiv, sind aber Orientierungswerte und ersetzen keine institutionsspezifische Bewertung von Schutzbedarf, Risiko und Angemessenheit. Schließlich steht der Katalog unter Share-Alike, weshalb die Weitergabe abgeleiteter Inhalte bewusst zu handhaben ist.

Entscheidungspunkte

• Verarbeitet die vorhandene GRC- oder ISMS-Plattform OSCAL nativ, oder muss eine Integration aufgebaut werden?
• Wie wird mit Versionsständen umgegangen, und wer verantwortet die Migration bei Aktualisierungen?
• Welche Rolle spielt Grundschutz++ neben dem klassischen Kompendium mit Blick auf Zertifizierungsziele, und wer prüft dafür den aktuellen Stand bei BSI?

Praktische Empfehlungen

1. Behandeln Sie Grundschutz++ als Datenquelle und klären Sie zuerst die Werkzeugfähigkeit, bevor Sie Inhalte übernehmen.
2. Trennen Sie Format und Methodik: Die Grundschutz-Vorgehensweise bleibt gültig, nur der Anforderungstransport ändert sich.
3. Nutzen Sie die Attribute für Scoping und Priorisierung, halten Sie aber die institutionsspezifische Risikobewertung getrennt.
4. Verankern Sie Versionierung und einen bewussten Lizenz-Umgang, bevor Sie Automatisierung produktiv schalten.
5. Verifizieren Sie verbindliche Details (Status, Zertifizierungsbezug, Verbindlichkeit) an der aktuellen BSI-Originalquelle.

Relevante Normreferenzen

• BSI IT-Grundschutz (Methodik nach BSI-Standard 200-2 und IT-Grundschutz-Kompendium): inhaltliche Grundlage des Anwenderkatalogs, als Fundstelle.
• ISO/IEC 27001:2022: internationaler ISMS-Bezugsrahmen, zu dem der IT-Grundschutz traditionell kompatibel ist (ISO-Stand vor verbindlicher Nutzung prüfen).
• NIST OSCAL: offenes Datenmodell für Sicherheitskataloge; technisches Transportformat, kein Sicherheitsstandard.