Grundschutz Compliance

Beschreibung

Dieser Check prüft, ob ein Projekt die Anforderungen des BSI IT-Grundschutzes erfüllt. Grundlage ist ein OSCAL System Security Plan (SSP), den DevGuard für das Projekt bereitstellt und der die Kontrollen der DevGuard System Component in vier Kategorien dokumentiert: Entwicklung (Grundschutz_DEV), Test (Grundschutz_TEST), Assets (Grundschutz_ASST) und Konfiguration (Grundschutz_KONF). Projekte ohne DevGuard-Anbindung können alternativ auch eine Datei SystemSecurityPlan.json im Stammverzeichnis ihres default Branches hinterlegen.

Der Check läuft in folgenden Schritten ab:

1. Auflösung des DevGuard-Projekts, das zum Repository gehört, und Ermittlung des default Branches
2. Abruf des OSCAL SSP über die DevGuard API für den aktuellen Stand des default Branches
3. Schlägt Schritt 2 fehl, etwa weil das Repository (noch) nicht an DevGuard angebunden ist, sucht der Check im Stammverzeichnis des default Branches nach einer Datei SystemSecurityPlan.json (siehe Fallback)
4. Filterung der Kontrollen der DevGuard System Component nach den konfigurierten control_id_prefixes, sec_level und modal_verb Werten
5. Prüfung, ob der Implementierungsstatus (implementation-status) jeder verbleibenden Kontrolle implemented oder not-applicable ist

Der Check gilt als bestanden, wenn keine der gefilterten Kontrollen einen anderen Status aufweist (z. B. planned, partial, alternative oder fehlend). Kontrollen, die durch die Konfiguration herausgefiltert werden, fließen nicht in die Bewertung ein.

Fallback ohne DevGuard-Anbindung

Ist das Repository nicht (oder noch nicht) an DevGuard angebunden, wird stattdessen eine Datei SystemSecurityPlan.json im Wurzelverzeichnis des default Branches gesucht und, falls vorhanden, als OSCAL SSP ausgewertet. Da diese Datei nicht von DevGuard stammt, entfällt hierbei die Anforderung an eine DevGuard System Component: Es werden die Kontrollen aller in der SSP enthaltenen Komponenten berücksichtigt.

Existiert weder eine DevGuard-Anbindung noch eine solche Fallback-Datei, gilt der Check als nicht bestanden.

Konfiguration

Der Check wird über grundschutz_config parametrisiert:

• sec_level: Schutzniveaus, die berücksichtigt werden sollen, z. B. normal-SdT (Stand der Technik) oder erhöht.
• modal_verb: Anforderungsklassen, die berücksichtigt werden sollen, z. B. MUSS, SOLLTE oder KANN.
• control_id_prefixes: Präfixe der Kontroll-IDs, die berücksichtigt werden sollen, z. B. Grundschutz_DEV, Grundschutz_TEST, Grundschutz_ASST oder Grundschutz_KONF.

Ist eine Liste leer, werden alle Werte für dieses Kriterium akzeptiert.

Die Grundschutz++ Badge nutzt diesen Check auf drei Stufen mit jeweils strengerer Konfiguration: Bronze prüft nur MUSS-Anforderungen des Schutzniveaus „normal (Stand der Technik)“, Silber ergänzt die SOLLTE-Anforderungen desselben Schutzniveaus, und Gold prüft zusätzlich KANN-Anforderungen sowie sämtliche Anforderungen des Schutzniveaus „erhöht“ – jeweils in allen vier Kategorien.

Fallback: Repository-lokaler SSP

Schlägt der Abruf über DevGuard fehl, greift der Fallback-Check auf eine Datei SystemSecurityPlan.json im Stammverzeichnis des default Branches zurück. Damit können auch Projekte die Grundschutz++ Badge erhalten, deren SSP außerhalb von DevGuard erzeugt und gepflegt wird. Antwortet DevGuard erfolgreich, wird dessen SSP bewertet. Eine lokale Datei überschreibt dieses Ergebnis nicht.

Für diese Datei gelten folgende Regeln:

• Dateiname und Ort: exakt SystemSecurityPlan.json im Stammverzeichnis des default Branches. Andere Namen, Pfade oder Branches werden nicht gelesen.
• Format: Ein OSCAL System Security Plan im JSON-Format. Die Datei wird gegen das OSCAL-Schema validiert. Ist sie nicht parsebar, meldet der Check einen Fehler.
• Benennung der Komponenten: anders als beim SSP aus DevGuard ist keine Komponente mit dem Titel DevGuard System Component erforderlich. Beim Fallback werden die by-components aller Kontrollen ausgewertet, unabhängig von der referenzierten Komponente.
• Benennung der Kontrollen: die Filterung über control_id_prefixes, sec_level und modal_verb greift unverändert. Damit Kontrollen in die Bewertung einfließen, müssen ihre control-id Werte den konfigurierten Präfixen entsprechen (z. B. Grundschutz_DEV), und Schutzniveau sowie Anforderungsklasse müssen den konfigurierten Werten entsprechen.

Hintergrund

Der BSI IT-Grundschutz ist der etablierte Standard der öffentlichen Verwaltung in Deutschland für Informationssicherheit. Durch die Abbildung der Grundschutz-Anforderungen als OSCAL SSP wird die Umsetzung maschinenlesbar, versionierbar und automatisiert überprüfbar, statt manuell in Dokumenten gepflegt zu werden.