SP 800-171 und CUI: Vertraulichkeit kontrollierter Information schützen

Problem in der Praxis

CUI-Schutz scheitert selten an grundsätzlichem Sicherheitsverständnis, sondern an drei wiederkehrenden Lücken. Erstens Unklarheit, welche Daten überhaupt CUI sind: Auftragnehmer erhalten Konstruktionsdaten, Spezifikationen oder Projektunterlagen, ohne dass im Vertrag sauber gekennzeichnet ist, dass es sich um CUI handelt - damit fehlt die Grundlage für jede Maßnahme.

Zweitens ein falsch gezogener Geltungsbereich: Entweder wird die gesamte Unternehmens-IT unter 800-171 gestellt, was Aufwand und Kosten unnötig treibt, oder die CUI-Umgebung wird zu eng definiert, sodass Datenflüsse, Backups, E-Mail-Pfade oder Cloud-Dienste durch das Raster fallen.

Drittens das Missverständnis, eine bestehende ISO/IEC-27001-Zertifizierung decke 800-171 automatisch ab. Die Schnittmengen sind real, aber 800-171 stellt spezifische, auf Vertraulichkeit zugeschnittene Anforderungen mit eigenen Parametern und eigenem Bewertungsverfahren. Hinzu kommt die ODP-Logik der Rev. 3: Bleiben die zu setzenden Parameterwerte offen, ist die Umsetzung weder eindeutig noch prüfbar.

CISO-Einordnung

800-171 ist am besten als zielgerichtete Verdichtung von SP 800-53 Rev. 5 zu verstehen. Der Mutterkatalog umfasst 20 Control-Familien mit 324 Basis-Controls und 872 Enhancements (1196 gesamt); seine Baselines (Low/Moderate/High) sind in SP 800-53B definiert, die Bewertungsprozeduren in SP 800-53A. 800-171 zieht aus der Moderate-Baseline jene Controls heran, die für die Vertraulichkeit von CUI relevant sind, und organisiert sie in Familien, die an den 800-53-Familien ausgerichtet sind - statt eines neuen Vokabulars erbt die Norm die bekannte Katalogstruktur.

Die wichtigste Neuerung der Rev. 3 sind die organisationsdefinierten Parameter (ODP). Sie entsprechen konzeptionell den Assignment- und Selection-Operationen in 800-53: Die Anforderung gibt das "Was" vor, der konkrete Wert - etwa Prüfintervalle oder Schwellen - wird als Parameter gesetzt, durch die auftraggebende Stelle oder die umsetzende Organisation. Das erhöht Flexibilität und Vergleichbarkeit, verlagert aber Verantwortung: Wer Parameter nicht aktiv bestimmt, hat keine prüfbare Soll-Vorgabe.

Zur Bewertung gehört der Companion SP 800-171A (analog zu 800-53A). Wichtig für die Erwartungssteuerung: Die Norm wurde in Rev. 3 gegenüber Rev. 2 restrukturiert. Rev. 2 umfasste 110 Anforderungen in 14 Familien; für Rev. 3 ist die exakte Anforderungs- und Familienzahl an der Originalpublikation zu verifizieren, statt sie ungeprüft zu übernehmen. Im DoD/CMMC-Kontext bildet 800-171 die fachliche Grundlage; CMMC ist der Mechanismus, über den die Schutzwirkung in der Lieferkette verifiziert wird.

Umsetzungsperspektive

Ein belastbarer 800-171-Weg lässt sich in wenige, aufeinander aufbauende Schritte gliedern - unabhängig von der genauen Anforderungszahl der Rev. 3.

• CUI identifizieren: Klären, welche Vertragsinformationen tatsächlich CUI sind, und dies mit der auftraggebenden Stelle abstimmen. Ohne saubere Klassifizierung kein tragfähiger Geltungsbereich.
• Geltungsbereich abgrenzen: Die CUI-Umgebung entlang der realen Datenflüsse definieren - Verarbeitung, Speicherung, Übertragung, inklusive Cloud, E-Mail und Backups. Ziel ist ein Bereich, der weder das ganze Unternehmen umfasst noch Datenpfade auslässt.
• ODP auflösen: Je parametrisierter Anforderung festlegen, welcher Wert gilt und wer ihn setzt - auftraggeberseitig vorgegeben oder organisationsseitig bestimmt und dokumentiert.
• Gap-Analyse und Plan: Ist-Zustand gegen die Anforderungen spiegeln und Lücken mit Verantwortlichen und Terminen führen (vergleichbar einem POA&M).
• Dokumentation und Bewertung: Umsetzungsstand nachvollziehbar beschreiben (Systemsicherheitsplan) und die Bewertung an SP 800-171A ausrichten.

Bestehende Reife aus einem ISO-27001-ISMS oder einer 800-53-Orientierung beschleunigt diesen Weg, ersetzt aber nicht die spezifische 800-171-Abbildung.

Typische Fehler

1. CUI wird nie sauber identifiziert; Maßnahmen entstehen ohne klaren Schutzgegenstand.
2. Der Geltungsbereich wird zu weit (gesamte IT) oder zu eng (ohne Backups, Cloud, E-Mail) gezogen.
3. Organisationsdefinierte Parameter bleiben unbesetzt; Anforderungen sind dadurch nicht eindeutig prüfbar.
4. Eine ISO-27001-Zertifizierung wird als automatischer 800-171-Nachweis behandelt.
5. 800-171 wird als einmaliges Compliance-Projekt verstanden, nicht als dauerhaft zu haltender Zustand mit Nachweis über 800-171A; teils wird sogar eine exakte Rev.-3-Anforderungszahl ungeprüft behauptet.

Risiken und Trade-offs

Der wichtigste Trade-off liegt im Scoping. Ein weiter Geltungsbereich vereinfacht die Argumentation ("alles ist abgedeckt"), erzeugt aber hohe, teils unnötige Kosten; ein enger, gut begründeter Bereich ist effizienter, verlangt aber präzise Kontrolle der Datenflüsse - jede übersehene Schnittstelle wird zum Vertraulichkeitsrisiko.

Zweitens der Fokus: 800-171 zielt primär auf Vertraulichkeit. Wer ausschließlich danach steuert, kann Verfügbarkeit und Integrität unterbelichten, die für den Geschäftsbetrieb genauso zählen. Drittens ist der Compliance-Zeitpunkt nicht der Dauerzustand: Eine Momentaufnahme zum Assessment sagt wenig über die Wirksamkeit im Betrieb. Und schließlich die ODP: Werden Parameter ohne Abstimmung mit dem Auftraggeber gesetzt, drohen spätere Differenzen genau dort, wo der Nachweis zählt.

Entscheidungspunkte

• Welche vertraglichen Informationen sind CUI, und ist das mit der auftraggebenden Stelle verbindlich geklärt?
• Wie ziehen wir den Geltungsbereich - dediziertes CUI-Enklavendesign oder unternehmensweite Abdeckung?
• Wer setzt die organisationsdefinierten Parameter, und wie dokumentieren wir die Werte prüfbar?
• Nutzen wir vorhandene ISO-27001- oder 800-53-Reife als Beschleuniger, und wo bleibt 800-171-spezifischer Mehraufwand?
• Wie organisieren wir Bewertung und Aufrechterhaltung - punktuelles Assessment nach 800-171A oder kontinuierlicher Nachweis, auch mit Blick auf CMMC?

Praktische Empfehlungen

1. Beginnen Sie mit CUI-Identifikation und Geltungsbereichsdefinition; beides ist Voraussetzung für jede sinnvolle Maßnahme.
2. Erwägen Sie eine dedizierte CUI-Enklave, um prüfbaren Bereich und Kosten beherrschbar zu halten.
3. Behandeln Sie organisationsdefinierte Parameter als eigene Aufgabe: Werte festlegen, Quelle (Auftraggeber/Organisation) benennen, dokumentieren.
4. Nutzen Sie die Nähe zu SP 800-53 Rev. 5 (Moderate-Baseline) und vorhandene ISMS-Reife als Beschleuniger statt bei null zu starten.
5. Richten Sie die Bewertung an SP 800-171A aus, planen Sie Aufrechterhaltung statt einmaliger Compliance, und verifizieren Sie strukturelle Eckdaten der Rev. 3 an der NIST-Originalpublikation; im DoD-Umfeld den CMMC-Bezug frühzeitig mitdenken.

Relevante Normreferenzen

• NIST SP 800-171 Rev. 3 (Mai 2024): "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations"; Vertraulichkeit von CUI, abgeleitet aus der 800-53-Moderate-Baseline, mit organisationsdefinierten Parametern (ODP). Public Domain.
• NIST SP 800-171A: Assessment-Prozeduren (Companion zu 800-171). Public Domain.
• NIST SP 800-53 Rev. 5 (Kontrollkatalog, 20 Familien) mit SP 800-53B (Baselines, u. a. Moderate) und SP 800-53A (Assessment): Ableitungs- und Bewertungsbasis. Public Domain.
• NIST SP 800-37 (RMF): einbettender Risikomanagement-Prozess im US-Kontext. Public Domain.
• Ergänzend: ISO/IEC 27001 (ISMS) als möglicher Beschleuniger; Edition vor Nutzung prüfen. Nicht Public Domain.