Auf den Punkt gebracht
Grundschutz++ erwartet alle Dokumente im nativen OSCAL-Format. Aber weißt du, ob dein ISMS/GRC-Tool das OSCAL-Format nativ beherrscht? Wenn nicht: Es gibt eine Alternative - schau dir mjEdit an.
Für die Interessierten
Die gute Nachricht: Wenn die übliche Praxis beibehalten wird, dann hast du voraussichtlich noch bis 2028 Zeit, dein ISMS auf Grundschutz++ zu migrieren.
Die Herausforderung: Die Zeit vergeht schnell, besonders wenn ein neues Tooling benötigt wird, weil der Hersteller deines bisherigen GRC-Tools nicht klar sagen kann, wann wirklich alle OSCAL-Dokumenttypen vollständig unterstützt werden und damit der Gesamtprozess durchgängig abbildbar ist.
Außerdem stellen sich zentrale Migrationsfragen:
- Welche Inhalte können weiterverwendet werden?
- Welche Anforderungen müssen neu bewertet werden?
- Wo sind neue Inhalte erforderlich?
Genau hier kann mjEdit in Kombination mit einer RAG-KI-Funktion unterstützen: Du chattest mit bestehenden ISMS-Daten, und die KI erstellt über MCP zusammen mit mjEdit neue OSCAL-Dokumente.
Für die, die es genau wissen wollen
Das OSCAL-Format ist ein flexibles, schema-basiertes Datenformat. Daraus ergibt sich eine zentrale Frage: Kann ein datenbankbasiertes GRC-Tool die Vorteile von nativem OSCAL wirklich ohne Reibungsverluste abbilden?
OSCAL ist ein standardisiertes, schema-basiertes Austauschformat mit JSON/XML/YAML-Semantik sowie offiziellen JSON-Schemata und Konvertern von NIST. Das macht JSON zur geeigneten kanonischen Repräsentation für automatisierte Workflows.
Direkt mit nativen OSCAL-JSON-Dateien zu arbeiten, reduziert Konvertierungsverluste, vereinfacht Referenzauflösung und beschleunigt Validierung im Vergleich zu GRC-Tools, die intern primär in SQL persistieren. Die wichtigsten Risiken liegen im Integrationsaufwand und in der Reife der bestehenden Toolchain. Deshalb sollten standardkonforme Validatoren und Resolver früh in den Erstellungs- und Bearbeitungsprozess eingebunden werden.
Vergleichstabelle: Native OSCAL-JSON vs. GRC-Tool mit SQL-Backend
| Argument | Begründung | Auswirkung | Risiko | Risikobewertung |
|---|---|---|---|---|
| Keine Konvertierungs-Roundtrips | Arbeiten mit nativen OSCAL-Dateien vermeidet bidirektionale Mapping-Logik zwischen OSCAL-Schema und relationalem Modell. | Weniger Fehler, schnellere Verarbeitung, deterministische Validierung. | Migrationsaufwand bei bestehender SQL-Infrastruktur. | Hoch |
| Erhalt von OSCAL-Links und Importketten | OSCAL-Modelle nutzen imports, href und Back-Matter; Viewer/Resolver erwarten native OSCAL-Dokumente. |
Automatische Kettenauflösung und konsistente Kontrolleinblendung. | GRC-Tools müssen komplexe Resolver nachbauen; dabei sind Inkonsistenzen möglich. | Hoch |
| Schema-getriebene Validierung | NIST stellt JSON-Schemata und CLI-Tools zur Validierung und Konvertierung bereit. | Frühzeitige Fehlererkennung; Audit-Nachweisbarkeit. | Fehlende/veraltete Schema-Versionen oder fehlende Nachweise führen zu Auditabweichungen. | Hoch |
| Interoperabilität mit OSCAL-Ökosystem | Viele OSCAL-Tools und Bibliotheken erwarten OSCAL-JSON als Input/Output. | Einfachere Integration mit OSS-Tools, Viewer und NIST-Artefakten. | Vendor-Lock-in bei proprietären GRC-APIs bleibt möglich. | Mittel |
| Komplexitätsreduktion gegenüber ORM/Impedance-Mismatch | Relationale Modelle müssen dynamische und hierarchische OSCAL-Strukturen abbilden; ORMs können Mapping-Lücken erzeugen. | Weniger Sonderfälle, geringere Wartungskosten. | Performance-Optimierungen für Abfragen müssen neu gedacht werden. | Mittel |
| Versionierung und Reproduzierbarkeit | OSCAL-JSON ist dateibasiert und eignet sich für VCS, Releases und Metadaten. | Nachvollziehbare Änderungen, einfacher Audit-Trail. | Große Sammlungen brauchen Storage und Indexierung. | Mittel |
| Evidenz-Referenzierung statt Datenhaltung | OSCAL referenziert Belege; es ersetzt nicht die Quelle. | Klare Trennung zwischen Metadaten und Evidence. | Belege müssen organisatorisch weiterhin sauber integriert werden. | Niedrig |
Quellen zur Tabelle:
- How OSCAL Viewer Works
- OSCAL Validation Concepts
- OSCAL CLI Converting Formats
- OSCAL Tools and Resources
- Decoding ORM
- OSCAL Releases
- Praxisbeispiel zu OSCAL/GRC
Zusammengefasst
- Konvertierungsfehler entstehen, wenn relationale Tabellen komplexe Arrays, verschachtelte Objekte oder
props/linkssauber abbilden müssen; das führt zu semantischen Lücken beim Re-Export in OSCAL. - Referenzauflösung (Profile -> Catalog -> SSP-Ketten) ist in OSCAL spezifiziert; Viewer/Resolver erwarten originale
href- und Back-Matter-Strukturen. - Validierung und Tooling: NIST-CLI und Bibliotheken ermöglichen standardisierte Validierung und Konvertierung; das reduziert Audit-Risiken gegenüber proprietären Mappings.
Eine Empfehlung
Wenn Compliance-Interoperabilität, deterministische Referenzauflösung und Auditierbarkeit Priorität haben, ist native OSCAL-JSON die bessere Basis - so wie es mjEdit anbietet.
mjEdit unterstützt den aktuellen OSCAL-Standard mit allen relevanten Dokumenttypen: von Katalog und Profil über SSP bis hin zu AP, AR und POA&M. So können ISB, ISK-Ersteller, IT-Fachleute und Auditoren in einem durchgängigen Werkzeug arbeiten.
Für Organisationen mit bestehender GRC-SQL-Infrastruktur empfiehlt sich ein hybrider Ansatz: OSCAL-native Speicherung für kanonische Artefakte plus synchronisierte SQL-Views für UI und Reporting, begleitet von automatisierten Validatoren und Resolvern.