Was ist OSCAL?

Warum Compliance ein Datenproblem ist

Sicherheitsanforderungen leben heute überwiegend in Prosa: Kataloge als PDF, Sicherheitskonzepte als Word-Dokument, Prüfergebnisse als Bericht. Prosa ist flexibel, aber sie hat einen Preis. Dieselbe Anforderung wird unterschiedlich interpretiert, Querverweise brechen bei jeder neuen Version, und jede Auswertung beginnt mit Kopieren, Einfügen und manueller Pflege von Tabellen.

Genau dieses Problem adressiert OSCAL. Die Open Security Controls Assessment Language ist ein offener Standard des US-amerikanischen NIST, entwickelt gemeinsam mit FedRAMP und einer internationalen Community. OSCAL beschreibt Sicherheitsanforderungen, ihre Umsetzung und ihre Prüfung als strukturierte Daten – verfügbar in JSON, XML und YAML.

• Anforderungen erhalten stabile Identifier statt Seitenzahlen und Überschriften
• Zusammenhänge zwischen Anforderung, Umsetzung und Nachweis werden explizit
• Werkzeuge können Inhalte validieren, vergleichen und transformieren

Die acht Dokumentmodelle

OSCAL ist kein einzelnes Dateiformat, sondern eine Familie aufeinander aufbauender Dokumentmodelle. Wer die Ebenen einmal verstanden hat, findet sich in jedem OSCAL-Dokument zurecht.

Kontrollebene: Katalog und Profil

Ein Katalog definiert Anforderungen, etwa die Controls von NIST SP 800-53 oder die Bausteine eines nationalen Standards. Ein Profil wählt daraus aus, passt an und kombiniert: aus einem großen Katalog wird die konkrete Anforderungsmenge für einen Anwendungsfall, zum Beispiel eine Baseline für Cloud-Dienste.

Implementierungsebene: Component Definition und System Security Plan

Eine Component Definition beschreibt, wie ein Produkt oder ein Service Anforderungen erfüllen kann – wiederverwendbar über viele Systeme hinweg. Der System Security Plan (SSP) dokumentiert dann für ein konkretes System, welche Anforderungen gelten und wie sie dort tatsächlich umgesetzt sind.

Assessment-Ebene: Plan, Ergebnisse und offene Punkte

Der Assessment Plan legt fest, was wie geprüft wird. Assessment Results halten Beobachtungen, Feststellungen und Risiken strukturiert fest. Das Plan of Action and Milestones (POA&M) verwaltet offene Punkte mit Verantwortlichkeiten und Terminen – als Daten, nicht als Anhang.

Mit OSCAL 1.2 ist zusätzlich die Mapping Collection dazugekommen. Sie beschreibt Beziehungen zwischen Anforderungen verschiedener Kataloge, etwa zwischen einem internationalen Standard und einem nationalen Regelwerk. Damit werden Framework-Vergleiche selbst maschinenlesbar.

Wer OSCAL heute nutzt

OSCAL ist längst kein Forschungsprojekt mehr. FedRAMP, das US-Programm für Cloud-Autorisierungen, verabschiedet sich von Word- und Excel-Paketen und verlangt strukturierte, maschinenlesbare Autorisierungsdaten – ein Wandel, den wir im Beitrag FedRAMP wird maschinenlesbar im Detail beschreiben.

Auch in Deutschland ist die Entscheidung gefallen: Das BSI veröffentlicht die Inhalte seiner Stand-der-Technik-Bibliothek – darunter der Anwenderkatalog IT-Grundschutz++ – als OSCAL-Kataloge in XML, JSON und YAML. Die Begründung des BSI ist bemerkenswert pragmatisch: OSCAL ist international etabliert, eine nationale Sonderlösung wäre ein Umweg. Was das für Grundschutz-Teams bedeutet, zeigt unser Beitrag zu IT-Grundschutz++ und OSCAL.

• FedRAMP: maschinenlesbare Authorization Packages ersetzen Dokumentvorlagen
• BSI: IT-Grundschutz++ erscheint als OSCAL-Katalog auf GitHub
• Community: Viewer, Validatoren, Bibliotheken und Plattformen wachsen zusammen

Wie Teams praktisch starten

Der Einstieg in OSCAL muss kein Projekt sein. Ein guter erster Schritt ist, ein echtes Dokument anzusehen und zu validieren – zum Beispiel einen Katalog aus dem NIST-Repository oder einen eigenen Export.

Mit unserem kostenlosen OSCAL Validator lässt sich jedes OSCAL-JSON-Dokument direkt im Browser gegen die offiziellen Schemas prüfen, ohne Upload und ohne Registrierung. Wer tiefer einsteigen will, findet in unserem OSCAL Toolkit eine offene TypeScript-Bibliothek zum Laden, Validieren und Transformieren von OSCAL-Dokumenten.

Ab diesem Punkt wird OSCAL vor allem eine Frage des Arbeitsmodells: Welche Kataloge und Profile gelten für uns? Wo entstehen SSP-Inhalte, wo Nachweise? Secani ist von Grund auf OSCAL-nativ gebaut – damit Teams strukturierte Compliance nicht nur importieren, sondern darin arbeiten können.