Einführung und Aufbau von BSI Grundschutz++
|
Diese Seite ist derzeit noch ein Entwurf. Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite. |
Dieser Artikel bietet einen schrittweisen Überblick über BSI Grundschutz++ und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
Einführung in Grundschutz++
Grundschutz++ ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.
Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.
Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.
Wiki-Referenz: Grundschutz++
BSI-Quelle: BSI-Website IT-Grundschutz-Kompendium (aktuelle Version 2026).
Bedeutung von OSCAL im Grundschutz++
Das zugrundeliegende Format für Grundschutz++ ist OSCAL. Es handelt sich um ein vom NIST entwickeltes, standardisiertes, maschinenlesbares Format (XML, JSON oder YAML) zur Dokumentation, Implementierung und Bewertung von Sicherheitsanforderungen. Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert auszulesen und zu bearbeiten. D.h.
- Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
- Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).
Das heißt aber nicht:
- Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
- Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
- Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
Grundlagen und Standards
- BSI-Standard 200-1: Leitlinien für ISMS.
- BSI-Standard 200-2: Methodik (Basis-, Kern-, Standard-Absicherung). <- Wird überarbeitet
- BSI-Standard 200-3: Risikomanagement mit Grundschutz.
- Artikel zu OSCAL (Open Security Controls Assessment Language).
Schritt-für-Schritt-Methodik
Die Methodik-Grundschutz++ folgt einem 5-stufigem PDCA-basierten Prozess mit Fokus auf Anforderungsmodellierung und maschinenlesbarer Verarbeitung. Hier das praktische Vorgehen:
Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance)
- Kontextanalyse (intern/extern) durchführen
- Interessierte Parteien identifizieren und Anforderungen erfassen
- Geltungsbereich (Scope) durch Institutionsleitung festlegen und freigeben
- Geschäftsprozesse priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
- Sicherheitsleitlinie erstellen (Ziele, Strategie, Verpflichtung Leitung)
- Sicherheitsorganisation etablieren (Rollen: ISB, Asset-Owner, etc.)
- Compliance-Management initialisieren (Rechts-/Vertragskatalog)
Ergebnis: Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse
Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung)
- Informationsverbund definieren (techn./org. Abgrenzung)
- Assets für wichtigsten Geschäftsprozess erfassen
- Asset → Zielobjektkategorien mapping (Hierarchie + Vererbung)
- Anforderungspaket generieren:
- ISMS-Praktiken (vollständig)
- Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
- Zielobjektlose Anforderungen prüfen
- Ergänzungen: Externe Verpflichtungen, anforderungslose Assets
- Risikobetrachtung bei hohem Schutzbedarf oder Niveauerhöhung
- Parameter setzen (Zuständigkeiten, Werte)
Ergebnis: Individuelles Anforderungspaket pro Informationsverbund
Schritt 3: Realisierung (DO - Umsetzung)
- Umsetzungsstatus aller Anforderungen prüfen (ja/nein)
- Nicht-umgesetzte MUSS/SOLLTE → Risikobetrachtung
- Umsetzungsplan erstellen:
- Priorisierung (Risiko, Aufwand, Synergien)
- Zuständigkeiten + Fristen zuweisen
- Freigabe durch Institutionsleitung
- Fortschritt tracken (Ticketsystem/Projektmanagement)
- Ausnahmen dokumentieren (Begründung + Leitungsfreigabe)
Ergebnis: Umsetzungsplan + Status-Dokumentation
Schritt 4: Überwachung (CHECK - Monitoring/Evaluation)
- Leistungsbewertung (KPIs, Umsetzungsfortschritt, Vorfälle)
- Compliance-Überwachung (gesetzlich/vertraglich)
- Auditprogramm risikobasiert durchführen
- Managementbewertung → Managementbericht erstellen
- Monitoring-Tools einsetzen (SIEM, Vulnerability Scanner)
- Anforderungspaket validieren (Aktualität prüfen)
Ergebnis: Auditberichte, Managementbericht
Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung)
- Nicht-Konformitäten analysieren (Root-Cause)
- Verbesserungspotenziale identifizieren
- Korrektur-/Verbesserungsplan → in Umsetzungsplan integrieren
- Wirksamkeit prüfen nach Umsetzung
- Sicherheitsniveau bewerten (Trendanalyse)
- Compliance-Verstöße behandeln
Ergebnis: Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus
Praktische Hinweise
- Tool-gestützt: JSON/OSCAL-Bausteine, verinice.PRO empfohlen
- Iteration: Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
- Risikobetrachtung: Nur bei "hoch" oder Niveauserhöhung/Nicht-Umsetzung
- Dokumentation: Maschinenlesbar (GitHub-Link in Methodik)
Zyklusdauer: Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)
