OSCAL in der Praxis: Was ein maschinenlesbarer Nachweis tatsächlich belegt

Eine Datei besteht die Schema-Prüfung. Darin steht, dass eine Kontrolle erfüllt ist. Belegt sie damit bereits, dass euer System sicher betrieben wird? Nein. Die Datei kann technisch gültig sein und trotzdem den falschen Systemumfang, einen veralteten Nachweis oder eine unbegründete Bewertung enthalten.

OSCAL macht Sicherheitsinformationen strukturiert austauschbar. Der Nutzen entsteht, wenn ihr damit den Weg von der Anforderung zur Prüfung nachvollziehen könnt. Wer zunächst die Grundlagen sucht, findet sie in unserem OSCAL-Einstieg. Hier geht es um die fachliche Qualität der Daten.

Welche Aussage liegt überhaupt vor?

NIST trennt im OSCAL-Modell zwischen Anforderungen, dokumentierter Umsetzung und Bewertung. Ein Katalog beschreibt Controls. Ein Profil wählt Anforderungen aus und passt sie für einen Kontext an. Ein System Security Plan beschreibt die Umsetzung in einem bestimmten System. Für Prüfungen gibt es eigene Modelle.

Diese Trennung verhindert einen häufigen Denkfehler: Eine beschriebene Sicherheitsmaßnahme ist noch kein Nachweis, dass sie umgesetzt wurde. Und eine Beobachtung ist noch nicht die abschließende Bewertung einer ganzen Anforderung.

Fragt beim nächsten Export deshalb zuerst, welche Art von Information er enthält. Ein vollständiger Anforderungskatalog beantwortet eine andere Frage als ein Bericht über tatsächlich geprüfte Systeme.

Ein Beispiel: MFA für administrative Zugänge

Wir verwenden eine fiktive Prüffrage: Für alle administrativen Zugänge einer bestimmten Anwendung soll Mehrfaktor-Authentifizierung wirksam sein. Das ist unser Beispiel, kein wörtlicher ISO-Control und keine OSCAL-Datei zum Importieren.

Der Systemverantwortliche beschreibt, wie MFA durchgesetzt wird. Die prüfende Person untersucht die betroffenen Konten, die Konfiguration und einen passenden Anmeldetest. Dabei wird ein lokales Administratorkonto entdeckt, das nicht über den zentralen Identitätsdienst läuft.

Der Fund macht die ursprüngliche Beschreibung nicht wertlos. Er zeigt, wo sie unvollständig ist. Wenn ein Export nur „MFA: aktiviert“ überträgt, verschwindet genau diese entscheidende Information.

Beobachtung, Befund und Risiko nicht zusammenwerfen

Das Assessment Results Model beschreibt unter anderem Prüfgegenstände, Aktivitäten, Beobachtungen, Befunde und Risiken. Damit lässt sich festhalten, was geprüft wurde und wie die Bewertung zustande kam. Ein Ergebnis steht im Kontext eines Assessment Plans.

Für unser Beispiel empfehlen wir drei getrennte Aussagen: gesehen, bewertet, entschieden. Gesehen wurde ein zusätzlicher Anmeldeweg. Bewertet wird seine Bedeutung für das Prüfziel. Entschieden wird, wie das Unternehmen damit umgeht. Ein automatisierter Konfigurationsabruf kann den ersten Teil unterstützen. Er ersetzt nicht automatisch die beiden anderen.

Das ist auch für wiederverwendete Nachweise wichtig. Ein Konfigurationsexport kann mehrere Prüfungen unterstützen, sofern sein Umfang jeweils passt. Der Zusammenhang wird nicht dadurch richtig, dass dieselbe Datei an mehrere Controls angehängt ist. Mehr dazu: Einen Nachweis für mehrere Audits nutzen.

Der offene Befund braucht einen weiteren Weg

NIST beschreibt im Plan of Action and Milestones Model die Nachverfolgung von Risiken und deren Behandlung. Für die Praxis heißt das: Ein Prüfbericht sollte offene Punkte nicht nur exportieren, sondern an die zuständige Bearbeitung anschließen.

In unserem Beispiel bekommt das lokale Konto einen Verantwortlichen und eine Frist. Nach der Änderung wird geprüft, ob der zusätzliche Zugang tatsächlich geschlossen ist. Soll er als Ausnahme erhalten bleiben, braucht die Risikoakzeptanz einen Entscheider, eine Begründung und einen nächsten Prüfanlass.

Denkt auch an Änderungen nach dem Test. Ein neuer Anmeldeweg oder ein neues System kann den ursprünglichen Umfang verlassen. Der alte Befund bleibt historisch richtig, sagt dann aber nicht mehr alles über den aktuellen Zustand.

Fünf Fragen vor dem Datenaustausch

Prüft an einem einzelnen, bereinigten Datensatz:

1. Umfang: Auf welche Systeme, Konten und Versionen bezieht sich die Aussage?
2. Zeit: Wann wurde der Nachweis erhoben und was hat sich seitdem geändert?
3. Herkunft: Wer oder welches Verfahren hat ihn erzeugt?
4. Bewertung: Welche Prüffrage wurde damit beantwortet und welche Grenze bleibt?
5. Folge: Wer bearbeitet einen offenen Befund und womit wird der Abschluss belegt?

Erst wenn Sender und Empfänger diese Fragen gleich verstehen, lohnt sich die Automatisierung in größerem Umfang. Testet außerdem, ob Verweise und Berechtigungen nach dem Transfer funktionieren. Ein Link, den der Empfänger nicht öffnen darf, ist keine nutzbare Übergabe.

In Kopexa hängen Nachweise an Maßnahmen; diese werden auf Controls gemappt. Dieser Arbeitszusammenhang hilft, Belege mit der Umsetzung zu verbinden. Er ist keine Aussage über eine native OSCAL-Schnittstelle. Für einen Austausch müssen Datenmodell, Format und Zuordnung gesondert geprüft werden.