Jenseits von Spreadsheet-Crosswalks

Organisationen arbeiten nur selten mit einem einzigen Cybersicherheits-Framework.

Ein SaaS-Anbieter benötigt möglicherweise ISO 27001 für sein Informationssicherheitsmanagementsystem, SOC 2 zur Erfüllung von Kundenerwartungen, die DSGVO für Datenschutzpflichten und NIS2 aufgrund seiner Branche oder Kundenbasis. Ein Zulieferer der Verteidigungsindustrie muss unter Umständen gleichzeitig NIST SP 800-171, CMMC, vertragliche Anforderungen und seine bestehenden ISO-basierten Kontrollen berücksichtigen.

Das Problem: Diese Frameworks sind nicht vollständig unabhängig voneinander. Sie verlangen häufig ähnliche Aktivitäten, verwenden dafür aber unterschiedliche Begriffe, Strukturen und Detailgrade.

Genau hier wird das Cross-Mapping von Frameworks wertvoll.

Ähnliche Anforderungen zu identifizieren, ist jedoch nur der Anfang. Damit Cross-Mappings verlässlich, wiederverwendbar und automatisierbar werden, müssen Organisationen außerdem wissen, woher eine Beziehung stammt, wie belastbar sie ist, für welche Framework-Versionen sie gilt und wo wichtige Lücken verbleiben.

Zwei NIST-Initiativen sind für diese Herausforderung besonders relevant: das National Online Informative References Program, besser bekannt als OLIR, und das OSCAL Control Mapping Model.

Sie lösen unterschiedliche Teile desselben Problems.

Warum Multi-Framework-Compliance unnötige Arbeit erzeugt

Klassische Compliance-Programme sind häufig nach einzelnen Frameworks organisiert.

Eine Tabelle enthält die ISO-27001-Kontrollen. Eine weitere verfolgt die NIS2-Anforderungen. Eine dritte wird für einen Kundenfragebogen oder ein bevorstehendes SOC-2-Audit gepflegt. Nachweise, Richtlinien, Kontrollbeschreibungen und Implementierungshinweise werden zwischen ihnen kopiert.

Dadurch wird jedes neue Framework schnell wie ein vollständig neues Compliance-Programm behandelt.

Cross-Mapping identifiziert gemeinsame oder sich überschneidende Anforderungen, damit bestehende Kontrollen und Nachweise wie Richtlinien, Protokolle, Screenshots und Verfahren dort wiederverwendet werden können, wo es angemessen ist. Der praktische Nutzen geht über die Vermeidung doppelter Arbeit hinaus. Cross-Mapping kann auch die Auditvorbereitung, das Reporting, die Risikotransparenz und die Reaktion auf regulatorische Änderungen verbessern.

Das wertvollste Ergebnis ist häufig nicht die Überschneidung selbst, sondern die Differenz.

Ein Incident-Response-Prozess kann Anforderungen aus ISO 27001, SOC 2 und NIS2 unterstützen. Das bedeutet nicht, dass diese Anforderungen identisch sind. Ein Framework kann konkrete Meldefristen verlangen, ein anderes den Schwerpunkt auf Governance-Verantwortlichkeiten legen und ein weiteres bestimmte Nachweise während eines Audits erwarten.

Ein nützliches Mapping muss daher zwei Fragen beantworten:

1. Was lässt sich wiederverwenden?
2. Was fehlt noch?

Diese Unterscheidung trennt einen belastbaren Crosswalk von einer einfachen Tabelle vermeintlich gleichwertiger Kontrollen.

Was ist OLIR?

OLIR steht für Online Informative Reference und ist Teil des National Online Informative References Program des NIST.

Das Programm ermöglicht Fachexpertinnen und Fachexperten, Beziehungen zwischen Elementen ihrer eigenen Standards, Frameworks, Produkte oder Leitfäden und Elementen unterstützter NIST-Dokumente zu beschreiben. Diese NIST-Dokumente werden als Focal Documents bezeichnet und können Veröffentlichungen wie das NIST Cybersecurity Framework, NIST SP 800-53 oder das NIST AI Risk Management Framework umfassen.

Ein OLIR könnte beispielsweise eine Anforderung aus einem Branchenframework mit einer Subcategory des NIST CSF 2.0 verbinden.

OLIR bietet mehr als eine Tabellenstruktur. Das Programm stellt Folgendes bereit:

• Einen standardisierten Ansatz zum Ausdrücken von Mapping-Aussagen
• Vorlagen für unterstützte NIST Focal Documents
• Metadaten über die einreichende Organisation und die zugeordneten Dokumente
• Einen zentralen öffentlichen Katalog
• Entwurfs- und finale Veröffentlichungsstatus
• Einen öffentlichen Review-Prozess
• Informationen darüber, ob das Mapping vom Eigentümer eines Dokuments oder von einer dritten Partei erstellt wurde

NIST unterscheidet zwischen drei OLIR-Mapping-Stilen: Concept Crosswalks, Set-Theory Relationship Mappings und Supportive Relationship Mappings.

Für detaillierte Compliance-Crosswalks sind Set-Theory Mappings besonders interessant. Anstatt lediglich festzuhalten, dass zwei Anforderungen in Beziehung stehen, können sie beschreiben, ob eine Anforderung gleich, eine Teilmenge, eine Obermenge oder eine teilweise Überschneidung der anderen ist.

OLIR liefert damit zwei Dinge, die vielen internen Mapping-Projekten fehlen: auffindbare Mapping-Inhalte und eine Governance-Struktur rund um diese Inhalte.

Was ist das OSCAL Control Mapping Model?

OSCAL, die Open Security Controls Assessment Language, stellt maschinenlesbare Modelle zur Darstellung von Kontrollkatalogen, Profilen, System Security Plans, Assessment Plans, Assessment Results und weiteren Compliance-Informationen bereit.

Das OSCAL Control Mapping Model erweitert dieses Ökosystem um eine strukturierte Darstellung von Beziehungen zwischen Kontrollen und Kontrollelementen aus unterschiedlichen Dokumentquellen.

Anders als ein narrativer Crosswalk ist das Modell für die Verarbeitung durch Software ausgelegt. Es kann in JSON, YAML oder XML dargestellt werden und Kontrollen oder einzelne Kontrollaussagen aus OSCAL-Katalogen und -Profilen zuordnen.

Zu seinen Beziehungstypen gehören:

• equal-to
• equivalent-to
• subset-of
• superset-of
• intersects-with
• no-relationship

Das Modell kann außerdem beschreiben, ob ein Mapping auf syntaktischer Ähnlichkeit, semantischer Bedeutung oder funktionalem Ergebnis basiert.

Das ist wichtig, weil zwei Anforderungen ähnlich aussehen und dennoch unterschiedliche operative Ergebnisse erzeugen können. Umgekehrt können Anforderungen mit völlig unterschiedlicher Sprache nahezu dieselbe Sicherheitsfunktion erfüllen.

Das Modell kann zusätzlich Herkunft, verantwortliche Parteien, Status, Konfidenz, Abdeckung, Lücken und die manuelle, automatisierte oder hybride Erstellung eines Mappings erfassen. Dadurch eignet es sich nicht nur zur Anzeige von Crosswalks, sondern auch für automatisierte Gap-Analysen, Change-Impact-Analysen, Validierung und Wiederverwendung in Compliance-Workflows.

OLIR und OSCAL sind keine konkurrierenden Ansätze

Es liegt nahe zu fragen, ob eine Organisation OLIR oder das OSCAL Control Mapping Model einsetzen sollte.

In der Praxis lösen sie unterschiedliche Probleme.

OLIR ist in erster Linie ein Programm, ein Katalog, ein Einreichungsprozess und eine Quelle für Mapping-Aussagen. Es hilft Organisationen, Mappings mit Bezug zu NIST Focal Documents zu finden und zu veröffentlichen.

Das OSCAL Control Mapping Model ist ein technisches Datenmodell. Es legt fest, wie Mapping-Beziehungen in einem System gespeichert, ausgetauscht, validiert und verarbeitet werden können.

OLIR kann einer Plattform mitteilen, dass eine Expertin, ein Experte oder eine Organisation eine bestimmte Beziehung festgestellt hat. OSCAL kann diese Beziehung zum Bestandteil eines größeren, berechenbaren Compliance-Systems machen.

OSCAL ist außerdem allgemeiner angelegt. Eine OSCAL Mapping Collection kann beliebige geeignete OSCAL-Kataloge oder -Profile verbinden. Sie ist nicht auf Beziehungen mit einem NIST Focal Document beschränkt.

Eine Organisation könnte OSCAL daher nutzen, um direkte Beziehungen wie diese darzustellen:

• BSI IT-Grundschutz zu ISO 27001
• NIS2 zu ISO 27001
• DORA zu einer internen Kontrollbibliothek
• Kundenspezifische Anforderungen zu bestehenden organisatorischen Kontrollen

Diese Mappings würden sich nicht zwingend als offizielle OLIR-Einreichungen eignen. Sie könnten jedoch vergleichbare Beziehungskonzepte verwenden und durch OSCAL konsistent gespeichert werden.

Wie beide Ansätze zusammenspielen können

Eine praktische Implementierung könnte OLIR als eine von mehreren externen Mapping-Quellen und OSCAL als kanonische interne Darstellung behandeln.

OLIR-Mappings
BSI- oder regulatorische Crosswalks
Mappings von Herausgebern
Mappings von Fachexperten
Kundenspezifische Mappings
KI-generierte Mapping-Vorschläge
                ↓
       Import und Normalisierung
                ↓
  Auflösung von Framework und Version
                ↓
      OSCAL Mapping Collections
                ↓
 Review, Freigabe und Konfidenz
                ↓
Gap-Analyse, Wiederverwendung von Nachweisen
und Auswirkungsanalyse

Beim Import eines OLIR würde eine Plattform das Reference Document und das Focal Document identifizieren, deren Element-IDs gegen die entsprechenden OSCAL-Kataloge auflösen und jede Beziehung in einen OSCAL-Mapping-Eintrag übersetzen.

Das ursprüngliche OLIR sollte als Herkunftsnachweis verknüpft bleiben. Nutzerinnen und Nutzer sollten erkennen können:

• Wer das Mapping erstellt hat
• Welche Versionen verglichen wurden
• Ob der Herausgeber Eigentümer einer der beiden Quellen war
• Ob das Mapping ein Entwurf oder final ist
• Welche Mapping-Methode verwendet wurde
• Ob es intern geprüft wurde

So bleiben Mappings nachvollziehbar, anstatt wie universelle Tatsachen behandelt zu werden.

Cross-Mapping darf nicht zu blinder Gleichsetzung führen

Automatisierung birgt das Risiko, dass Organisationen Mappings als Beleg dafür behandeln, dass eine Implementierung automatisch jede verwandte Anforderung erfüllt.

Diese Schlussfolgerung ist nur selten gerechtfertigt.

Ein Crosswalk beschreibt Beziehungen zwischen Anforderungen. Er beweist nicht automatisch, dass eine Organisation diese Anforderungen wirksam umgesetzt hat.

Nachweise können zudem wiederverwendbar sein, ohne ausreichend zu sein. Eine Backup-Richtlinie könnte mehrere Frameworks unterstützen, während eines davon zusätzlich Wiederherstellungstests, definierte Wiederherstellungsziele, konkrete Aufbewahrungsfristen oder Nachweise einer Managementprüfung verlangt.

Belastbares Cross-Mapping erfordert daher:

• Granularität auf Aussageebene, wo immer möglich
• Explizite Framework-Versionen
• Dokumentierte Beziehungstypen
• Beschreibungen von Lücken
• Herkunftsnachweise
• Konfidenzwerte
• Menschliche Prüfung bei folgenreichen Entscheidungen

Abgeleitete Beziehungen verdienen besondere Vorsicht. OLIR kann Derived Relationship Mappings zwischen zwei Reference Documents erzeugen, indem verglichen wird, wie beide zu einem gemeinsamen NIST Focal Document stehen. NIST beschreibt diese als nicht autoritative Ausgangspunkte und nicht als verifizierte direkte Crosswalks.

Sie können Analysen beschleunigen, sollten aber Review-Aufgaben und keine automatischen Compliance-Aussagen erzeugen.

Von statischen Crosswalks zu wiederverwendbarer Compliance-Infrastruktur

Das praktische Argument für Cross-Mapping ist überzeugend: Organisationen sollten nicht für jedes Framework dieselben Kontrollen erneut erstellen, dieselben Nachweise sammeln und voneinander getrennte Compliance-Programme pflegen. Ein zentrales Repository und skalierbare Automatisierung können Doppelarbeit reduzieren und Lücken sichtbarer machen.

Der nächste Schritt besteht darin, diese Crosswalks portabel, versioniert und maschinenlesbar zu machen.

OLIR kann bestehendes Mapping-Wissen, Veröffentlichungs-Governance und einen Weg zur Einreichung neuer NIST-orientierter Mappings bereitstellen. Das OSCAL Control Mapping Model kann diese Beziehungen in strukturierte Objekte überführen, die Compliance-Werkzeuge validieren, abfragen, erweitern und mit umfassenderen Assessment-Workflows verbinden können.

Bei Secani betrachten wir OSCAL als die kanonische technische Grundlage. OLIR ist kein konkurrierendes Modell, sondern eine wertvolle Quelle, die OSCAL bereichern kann.

Die langfristige Chance ist größer als die Anzeige, dass sich zwei Kontrollen überschneiden. Es geht darum, eine vertrauenswürdige Mapping-Schicht zu schaffen, die zeigt, was wiederverwendet werden kann, was weiterhin unzureichend abgedeckt ist, warum eine Beziehung besteht, wer sie freigegeben hat und wie sich eine Framework-Aktualisierung auf den Rest des Compliance-Programms auswirkt.

So entwickelt sich Cross-Mapping von einer Sammlung von Tabellen zu wiederverwendbarer Compliance-Infrastruktur.