Cloud Security Posture Management für Verteidigung: CSPM in klassifizierten Umgebungen

Cloud-Fehlkonfigurationen sind mittlerweile die häufigste Ursache für Datenpannen in cloud-gehosteter Infrastruktur — und das Problem ist in Verteidigungsumgebungen erheblich gravierender, wo die Folge einer einzigen exponierten Ressource keine Betriebsunterbrechung, sondern ein potenzielles Geheimdienstversagen ist. Verteidigungsorganisationen, die Workloads in Government-Cloud-Umgebungen verlagern — AWS GovCloud, Azure Government oder klassifizierte kommerzielle Cloud auf IL4- und IL5-Sicherheitsniveaus — übernehmen eine große und dynamische Angriffsfläche, die nicht allein durch periodische manuelle Audits gesichert werden kann.

Cloud Security Posture Management (CSPM) bietet die kontinuierliche Sichtbarkeitsebene, die Verteidigungsdienste in der Cloud benötigen: automatisiertes, richtliniengesteuertes Scannen des Cloud-Konfigurationsstatus anhand von Compliance-Baselines, mit Echtzeit-Alarmen bei Abweichungen und Integration in die formalen Behebungs- und Akkreditierungsworkflows, die DoD-Systeme regeln. Dieser Artikel erläutert, wie CSPM in klassifizierten Umgebungen funktioniert, was es scannt, wie die Drift-Erkennung arbeitet und wie CSPM-Ergebnisse in die ATO-Nachweispakete einfließen, die Authorizing Officials benötigen.

Was CSPM abdeckt und warum klassifizierte Cloud es benötigt

CSPM-Tools bewerten kontinuierlich den Konfigurationsstatus von Cloud-Ressourcen anhand einer definierten Richtlinien-Baseline — sie prüfen IAM-Rollen, Netzwerksicherheitsgruppen, Speicher-Bucket-Berechtigungen, Verschlüsselungseinstellungen, Protokollierungskonfiguration und Hunderte weitere Ressourcenattribute — und melden Abweichungen als Befunde, die behoben oder formal akzeptiert werden müssen. Dies unterscheidet sich grundlegend von einem Schwachstellenscanner, der nach Software-Schwächen sucht (CVEs, fehlende Patches, ausnutzbare Codepfade); CSPM sucht nach Konfigurationsschwächen.

Dieser Unterschied ist in der klassifizierten Cloud enorm wichtig. Verteidigungs-Cloud-Mandanten betreiben in der Regel gehärtete, gepatchte Infrastruktur, die vom Cloud-Dienstanbieter im Rahmen des gemeinsamen Verantwortungsmodells gewartet wird. Die Workloads selbst sind möglicherweise gut gepatcht. Aber die Konfiguration, wie diese Workloads bereitgestellt werden — die IAM-Richtlinien, die den Zugriff steuern, die Netzwerkregeln, die den Datenverkehr bestimmen, die Protokollierungseinstellungen, die festlegen, welche Aktionen aufgezeichnet werden — liegt in der Verantwortung des Mandanten und ändert sich kontinuierlich, wenn sich betriebliche Anforderungen weiterentwickeln.

Ein Punkt-in-Zeit-Audit — der traditionelle Ansatz, bei dem ein Prüfer die Konfiguration zu einem definierten Zeitpunkt während des ATO-Prozesses überprüft — liefert ein Compliance-Bild, das für diesen Moment korrekt und möglicherweise am nächsten Tag bereits ungenau ist. Ein autorisierter Benutzer, der eine legitime Änderung an einer Sicherheitsgruppenregel vornimmt, ein Administrator, der ein neues Dienstkonto mit übermäßig breiten Berechtigungen erstellt, ein Entwickler, der eine Funktion aktiviert, die die Speicherzugriffseinstellungen ändert: All dies kann eine Fehlkonfiguration einführen, die eine ausnutzbare Lücke schafft. In klassifizierten Umgebungen kann diese Lücke monatelang zwischen Audits bestehen bleiben.

CSPM ersetzt das Punkt-in-Zeit-Bild durch kontinuierliche Sichtbarkeit. In ereignisgesteuerten CSPM-Architekturen kann die Erkennungslatenz für eine neue Fehlkonfiguration in Sekunden gemessen werden — ein neu erstellter öffentlicher S3-Bucket oder eine IAM-Richtlinienänderung, die übermäßige Berechtigungen gewährt, löst einen Alarm aus, bevor die Fehlkonfiguration ausgenutzt werden kann. Dies ist der zentrale Mehrwert für die Cloud-Sicherheit militärischer Workloads: nicht die Möglichkeit von Fehlkonfigurationen zu eliminieren (was betriebliche Realitäten unvermeidlich machen), sondern sie zu erkennen und zu korrigieren, bevor sie zu einem Geheimdienstversagen oder einem operativen Sicherheitsvorfall werden.

Baseline-Richtlinienrahmen für Verteidigungs-Cloud

CSPM ist nur so nützlich wie die Richtlinien-Baseline, die es durchsetzt. Für Verteidigungs-Cloud-Umgebungen sind die anwendbaren Rahmenwerke klar definiert, aber mehrschichtig, und die korrekte Zuordnung ist eine Voraussetzung dafür, dass CSPM-Befunde im ATO-Kontext handlungsfähig sind.

DISA STIG Cloud Computing SRG. Der Security Requirements Guide for Cloud Computing ist das maßgebliche DISA-Dokument, das Sicherheitskontrollen für alle DoD-Cloud-Bereitstellungen definiert. Er überlagert NIST 800-53 mit DoD-spezifischen Anforderungen und weist Kontrollverantwortlichkeiten dem Cloud-Dienstanbieter, dem Mandanten und ihrer gemeinsamen Grenze zu. Das SRG definiert Anforderungen auf der Virtualisierungsschicht, der Betriebssystemschicht, der Anwendungsschicht und der Cloud-Dienstschicht — all diese müssen in einem DoD-ATO-Paket adressiert werden. CSPM-Richtlinienregeln müssen SRG-Kontrollkennungen zugeordnet werden, damit Befunde direkt mit ATO-Anforderungen verknüpft werden können.

NIST SP 800-53 Rev 5. Der zugrunde liegende Kontrollkatalog für alle föderalen Systeme. Für die Cloud sind die relevantesten Kontrollfamilien: Configuration Management (CM) — Verhinderung und Erkennung nicht autorisierter Konfigurationsänderungen; System and Communications Protection (SC) — Verschlüsselung bei der Übertragung und im Ruhezustand, Netzwerksegmentierung; Audit and Accountability (AU) — Protokollierung, Protokollintegrität und Protokollaufbewahrung; und Access Control (AC) / Identification and Authentication (IA) — IAM-Richtlinie und Rechteverwaltung. Eine gut konfigurierte CSPM-Bereitstellung ordnet Regeln spezifischen Kontroll-IDs zu (z. B. CM-6, CM-7, AC-3, AU-2), sodass jeder Befund seinen Kontrollverweis trägt.

FedRAMP High Baseline. Cloud-Dienste, die von DoD-Systemen auf IL4 und IL5 genutzt werden, müssen eine FedRAMP High-Autorisierung oder gleichwertige Zertifizierung besitzen. Die FedRAMP High Baseline erweitert 800-53 Rev 4/5 mit strengeren Parameterwerten — beispielsweise durch die Anforderung einer Multi-Faktor-Authentifizierung für alle privilegierten und nicht privilegierten Konten, nicht nur für privilegierte. CSPM-Richtlinienpakete für FedRAMP High sind für AWS, Azure Government und GCP verfügbar und bilden den Ausgangspunkt für die mandantenseitige CSPM-Konfiguration in den meisten Verteidigungs-Bereitstellungen.

Die folgende Tabelle veranschaulicht, wie wichtige CSPM-Prüfkategorien den drei primären Rahmenwerken zugeordnet werden:

Fehlkonfigurationserkennung: was CSPM scannt

Die Angriffsfläche, die CSPM in der Verteidigungs-Cloud adressiert, gliedert sich in fünf Hauptkategorien. Jede davon repräsentiert eine Klasse von Fehlkonfigurationen, die in realen DoD-ATO-Befunden aufgetaucht ist und ausnutzbare Zustände schafft, wenn sie nicht kontinuierlich erkannt wird.

IAM-Fehlkonfigurationen sind die häufigste Kategorie mit hohem Schweregrad. Übermäßig permissive Rollenrichtlinien — insbesondere Richtlinien, die Platzhalter-Ressourcenbezeichner (Resource: "*") für sensible Aktionen verwenden oder administrative Richtlinien an nicht-administrative Prinzipale anhängen — verstoßen gegen das Prinzip der geringsten Berechtigung und schaffen laterale Bewegungspfade für einen Angreifer, der einen Prinzipal mit diesen Berechtigungen kompromittiert. CSPM-IAM-Prüfungen suchen nach: ungenutzten Rollen und Zugriffsschlüsseln (veraltete Anmeldedaten, die nie deaktiviert wurden), Pfaden zur Berechtigungseskalation (Rollenrichtlinien, die einem Prinzipal erlauben, seine eigenen Berechtigungen zu ändern), kontoübergreifenden Vertrauensbeziehungen und Root-Kontoaktivität.

Netzwerk-Expositionsprüfungen identifizieren Sicherheitsgruppenregeln, Netzwerk-ACLs oder Firewall-Richtlinien, die eingehenden Zugriff aus uneingeschränkten Adressbereichen (0.0.0.0/0 oder ::/0) auf sensiblen Ports erlauben — SSH (22), RDP (3389), Datenbankports und Verwaltungsschnittstellen. In der klassifizierten Cloud ist jede Exposition von Verwaltungsschnittstellen gegenüber breiten Netzwerkbereichen ein STIG-Befund der Kategorie I. CSPM-Netzwerkprüfungen überprüfen auch, ob VPC-Flow-Protokollierung aktiviert ist, ob keine öffentliche IP-Zuweisung für Ressourcen in privaten Subnetzen aktiviert ist, und ob Netzwerk-Peering-Beziehungen angemessen sind.

Lücken bei der Verschlüsselung im Ruhezustand sind eine harte FedRAMP High- und STIG-Anforderung — jedes Volume, jede Datenbank und jeder Objektspeicher, der DoD-Daten enthält, muss mit einem FIPS 140-2-validierten Algorithmus verschlüsselt sein. CSPM-Verschlüsselungsprüfungen inventarisieren Speicherressourcen (EBS-Volumes, RDS-Instanzen, S3-Buckets, DynamoDB-Tabellen) und markieren alle, die unverschlüsselt oder mit einem nicht-validierten Algorithmus verschlüsselt sind. Schlüsselverwaltungsprüfungen überprüfen, ob Verschlüsselungsschlüssel kundenverwaltete Schlüssel (CMK) statt anbieterverwalteter Schlüssel sind, wo dies im SSP erforderlich ist, und ob die Schlüsselrotation aktiviert ist.

Protokollierungslücken sind eine besonders tückische Fehlkonfiguration, da ihre Abwesenheit unsichtbar ist, bis nach einem Vorfall eine forensische Rekonstruktion erforderlich ist. CSPM-Protokollierungsprüfungen überprüfen, ob CloudTrail (oder Äquivalent) in jeder Region und jedem Konto aktiviert ist, ob der Protokollspeicher eine Integritätsvalidierung aktiviert hat (z. B. CloudTrail-Protokolldatei-Validierung), ob die Protokollaufbewahrung die Mindestaufbewahrungsfrist erfüllt (typischerweise 1–3 Jahre für DoD-Systeme), und ob Verwaltungsereignisse — API-Aufrufe, die Konfigurationen ändern — speziell erfasst werden. Protokollierungslücken verstoßen direkt gegen die Anforderungen der AU-Kontrollfamilie und können zu ATO-Befunden führen, die architektonisch schwer zu kompensieren sind.

Öffentliche Speicherexposition — Objektspeicher-Buckets mit öffentlichem Lese- oder Schreibzugriff — bleibt in CSPM-Prüfsätzen, weil sie weiterhin in realen Vorfällen auftritt. In der Verteidigungs-Cloud stellt ein falsch konfigurierter S3-Bucket oder Azure Blob-Container mit öffentlichem Zugriff einen direkten CUI- oder klassifizierten Datenexpositionspfad dar. CSPM prüft Bucket-Level-Einstellungen für öffentlichen Zugriffsblock, Bucket-ACLs, Bucket-Richtlinien, die nicht authentifizierten Zugriff erlauben, und öffentlichen Zugriff auf Kontoebene (AWS S3 Account Public Access Block).

Ein typisches CSPM-Scan-Ergebnis für eine mittelkomplexe Verteidigungs-Cloud-Umgebung könnte wie folgt aussehen:

CSPM Scan-Zusammenfassung — GovCloud-Konto: 123456789012
Scan-Datum: 2026-06-25T08:14:32Z  |  Framework: FedRAMP-High + STIG-SRG

Kategorie                 Gesamt  BESTANDEN  FEHLGESCHL.  WARNUNG  UNTERDRÜCKT
────────────────────────────────────────────────────────────────────────────────
IAM                          142        118           17        4            3
Netzwerksicherheit            89         82            5        2            0
Verschlüsselung i. Ruhezust.  54         51            2        1            0
Audit-Protokollierung         31         28            3        0            0
Öffentliche Exposition        18         18            0        0            0
Schlüsselverwaltung           22         20            1        1            0
────────────────────────────────────────────────────────────────────────────────
GESAMT                       356        317           28        8            3

Schweregrad-Aufschlüsselung (FEHLGESCHLAGEN):
  Kritisch / Kat-I:   3  ← SLA: 15 Tage
  Hoch     / Kat-II: 14  ← SLA: 30 Tage
  Mittel   / Kat-III: 11  ← SLA: 90 Tage

Drift-Erkennung und Richtliniendurchsetzung

Ein CSPM-Scan erfasst den Zustand zu einem bestimmten Zeitpunkt; die Drift-Erkennung erfasst Zustandsänderungen. In operativen Verteidigungs-Cloud-Umgebungen sind Konfigurationsänderungen häufig — Infrastructure-as-Code-Bereitstellungen, Administratoraktionen, Dienstkonten-Provisionierung, Feature-Flag-Aktualisierungen und Cloud-Provider-Wartung können alle Ressourcenkonfigurationen ändern. Die Drift-Erkennung identifiziert, wenn der aktuelle Zustand von der genehmigten Baseline abweicht, und zwar mit einer dem Risiko angemessenen Latenz.

Die zwei primären Scan-Architekturen sind geplantes Scannen und ereignisgesteuertes Scannen. Geplantes Scannen führt einen vollständigen Konfigurationsdurchlauf in einem definierten Intervall durch — stündlich, alle vier Stunden oder täglich — und ist der Basisansatz für die meisten CSPM-Bereitstellungen. Es ist einfach, umfassend und funktioniert gut für Umgebungen mit geringerem Änderungsvolumen. Seine Einschränkung ist die Latenz: Eine unmittelbar nach einem Scan-Zyklus eingeführte Fehlkonfiguration wird möglicherweise erst fast am Ende des vollen Intervalls erkannt.

Ereignisgesteuertes Scannen reduziert diese Latenz auf Sekunden, indem gezielte Prüfungen ausgelöst werden, wenn Konfigurationsänderungs-Ereignisse erkannt werden. AWS EventBridge kann CloudTrail-Ereignisse für spezifische API-Aufrufe (CreateBucket, PutBucketAcl, AuthorizeSecurityGroupIngress, AttachRolePolicy) an eine CSPM-Evaluierungsfunktion weiterleiten, die unmittelbar nach der Änderung nur die betroffene Ressource prüft. Diese Architektur ist für die risikoreichsten Prüfkategorien — IAM und Netzwerkexposition — unverzichtbar, wo das Fenster zwischen Fehlkonfigurationserststellung und Ausnutzung Stunden statt Tage betragen kann.

Automatisierte Behebungs-Guardrails gehen einen Schritt weiter als die ereignisgesteuerte Erkennung: Bei Erkennung einer Fehlkonfiguration korrigiert das CSPM-System diese automatisch, ohne auf menschliches Eingreifen zu warten. Ein Guardrail gegen die Erstellung öffentlicher Buckets würde beispielsweise einen neuen Bucket mit aktiviertem öffentlichem Zugriff erkennen, sofort den öffentlichen Zugriffsblock setzen, das Sicherheitsteam benachrichtigen und ein Ticket erstellen, das dokumentiert, was passiert ist. Guardrails sind mächtig, erfordern aber sorgfältige Einschränkung. In Verteidigungsumgebungen ist ein konservatives Guardrail-Design angebracht:

• Automatische Behebung nur für Kontrollen anwenden, bei denen die Korrekturmaßnahme eindeutig und das Risiko einer Unterbrechung legitimer Betriebsabläufe nahezu null ist (Deaktivierung des öffentlichen Zugriffs auf Speicher, Durchsetzung von MFA-Token-Anforderungen)
• IAM-Richtlinienänderungen oder Netzwerkregel-Modifikationen niemals ohne Abhängigkeitsvalidierung automatisch beheben — Anwendungen könnten von der zu korrigierenden Konfiguration abhängen
• Jede automatisierte Behebungsaktion muss protokolliert werden und einen Alarm generieren — Guardrails dürfen keinen unsichtbaren Konfigurationsstatus erzeugen
• Einen Break-Glass-Unterdrückungsmechanismus beibehalten, damit ein autorisierter Administrator die automatische Behebung für eine bestimmte Ressource während geplanter Wartungsfenster sperren kann

Break-Glass-Ausnahmebehandlung ist der komplementäre Prozess für Situationen, in denen eine sofortige Behebung nicht möglich ist. Wenn ein CSPM-Befund aufgrund einer technischen Einschränkung oder operativen Abhängigkeit nicht innerhalb der SLA behoben werden kann, leitet der ISSO einen formalen Risikoakzeptanz-Workflow ein: den Befund dokumentieren, kompensierende Kontrollen identifizieren, die Unterschrift des AO für eine zeitlich begrenzte Akzeptanz einholen und die Ausnahme in eMASS als offenes POA&M-Element erfassen. Das CSPM-Tool sollte akzeptierte Ausnahmen durch Unterdrückung des Befunds aus aktiven Dashboards widerspiegeln, ihn aber im Prüfverlauf behalten, und sollte den Befund automatisch wieder anzeigen, wenn die Akzeptanzfrist abläuft.

CSPM in air-gapped und IL4/IL5-Umgebungen

Das standardmäßige kommerzielle CSPM-Bereitstellungsmodell — eine SaaS-Plattform, die sich mit Cloud-APIs verbindet, Befunde in einem vom Anbieter gehosteten Backend aggregiert und ein Web-Dashboard bereitstellt — ist grundlegend inkompatibel mit IL5- und klassifizierten Cloud-Anforderungen. Daten über klassifizierte Cloud-Konfigurationen, Ressourceninventare, IAM-Strukturen und Sicherheitsbefunde dürfen die Klassifizierungsgrenze nicht zum kommerziellen Cloud-Bereich des Anbieters verlassen. Selbst bei IL4 (Controlled Unclassified Information) wenden viele Programme konservative Datenverwaltung an, die SaaS-CSPM ausschließt.

Dies schafft eine architektonische Einschränkung, die Verteidigungs-CSPM-Bereitstellungen explizit lösen müssen. Die praktikablen Ansätze sind:

On-Premises CSPM-Engine-Bereitstellung. Open-Source CSPM-Engines — Prowler (AWS), Steampipe mit Compliance-Mods, Checkov (IaC-statische Analyse) oder Scout Suite — können vollständig innerhalb der klassifizierten Enklave bereitgestellt werden. Das Tool läuft innerhalb der Grenze, fragt Cloud-APIs von innerhalb der Grenze ab, speichert Befunde in einer internen Datenbank und generiert Berichte, die die Klassifizierungsgrenze nie verlassen. Dieser Ansatz erfordert operativen Besitz des CSPM-Tools selbst (Updates, Signaturwartung, Regelpaket-Management), bietet aber vollständige Kontrolle und kein Datenabfluss-Risiko.

Autorisiertes kommerzielles CSPM auf Sicherheitsniveau. Mehrere kommerzielle CSPM-Produkte besitzen FedRAMP High-Autorisierungen und bieten Bereitstellungsmodi in AWS GovCloud- oder Azure Government-Regionen an. Diese können für IL4-Workloads akzeptabel sein, wenn die Datenverwaltung des CSPM-Tools innerhalb der autorisierten Grenze liegt. Programme sollten überprüfen, dass die FedRAMP-Autorisierung des spezifischen CSPM-Produkts die zu bewertenden Datentypen abdeckt und dass das Produkt in einer GovCloud-residenten Bereitstellung betrieben wird, nicht in einem kommerziellen Regions-Backend, das GovCloud-Daten empfängt.

Der agentlose vs. agentenbasierte Scanning-Kompromiss ist in klassifizierten Umgebungen bedeutsam:

Agentloses CSPM fragt Cloud-Provider-APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory) ab, um Cloud-native Ressourcen zu inventarisieren und zu bewerten. Es erfordert keine auf Compute-Instanzen installierte Software, hat keine Leistungsauswirkungen auf Workloads und ist einfach zu autorisieren, da die Angriffsfläche auf die schreibgeschützten API-Anmeldedaten beschränkt ist. Es ist jedoch blind für den OS-Level-Konfigurationsstatus — es kann überprüfen, ob eine EC2-Instanz die korrekte Sicherheitsgruppe angehängt hat, kann aber nicht überprüfen, ob die OS-Firewall korrekt konfiguriert ist oder ob ein unzulässiger Dienst innerhalb der Instanz läuft.

Agentenbasiertes CSPM installiert einen leichten Sensor auf jeder Compute-Instanz, der OS-Level-Sichtbarkeit bietet: laufende Prozesse, installierte Pakete, Dateiintegritätsüberwachung, OS-Level-Konfigurationseinstellungen, die STIG-Host-Kontrollen entsprechen. Dies bietet Abdeckung für Kontrollen, die Cloud-APIs nicht bewerten können. Der Kompromiss besteht darin, dass die Agentensoftware selbst auf dem anwendbaren Klassifizierungsniveau autorisiert, durch den Akkreditierungsprozess bereitgestellt und innerhalb der Klassifizierungsgrenze gewartet (Updates, Signaturänderungen) werden muss. In klassifizierten Umgebungen ist der Agenten-Autorisierungsprozess oft die primäre Einschränkung für die Einführung agentenbasierter CSPM.

Die meisten ausgereiften IL4/IL5-CSPM-Bereitstellungen verwenden agentloses Scannen für Cloud-API-sichtbare Kontrollen und eine separate HBSS (Host-Based Security System)- oder Endpoint-Agent-Lösung — oft das DoD-Standard McAfee HIP/HBSS — für STIG-Compliance auf Host-Ebene, wobei beide Datenquellen in ein einheitliches Compliance-Dashboard integriert werden. Diese DevSecOps für Verteidigungs-Pipelines-Haltung, bei der CSPM in denselben Compliance-Datensatz wie Pipeline-Sicherheitskontrollen einfließt, liefert das vollständigste ATO-Nachweisbild.

Integration des Behebungsworkflows

CSPM-Befunde, die nur im Dashboard des CSPM-Tools vorhanden sind, haben für ein Verteidigungsprogramm begrenzten Wert. Der institutionelle Prozess zur Verfolgung von Sicherheitsbefunden ist das POA&M in eMASS — und CSPM-Befunde müssen automatisch in diesen Prozess einfließen, nicht durch manuelle Übertragung durch einen ISSO, der das CSPM-Dashboard überprüft und Befunde manuell in eMASS-Datensätze kopiert.

Die Integrationsarchitektur für klassifizierte Programme umfasst typischerweise zwei Stufen. Erstens werden CSPM-Befunde in das autorisierte Ticket- oder Issue-Tracking-System des Programms exportiert — ServiceNow Government Cloud, Jira auf einer klassifizierten Instanz oder ein benutzerdefiniertes Tool — wo sie zu umsetzbaren Arbeitselementen werden, die dem Cloud-Platform-Team oder dem Anwendungsteam zugewiesen sind, das für die betroffene Ressource verantwortlich ist. Jedes Ticket enthält die CSPM-Befundkennung, den betroffenen Ressourcen-ARN oder Äquivalent, den Schweregrad, anwendbare Compliance-Kontrollverweise, das empfohlene Behebungsverfahren und das SLA-Fälligkeitsdatum, das aus dem Befunderststellungszeitstempel und der schweregradbasierten SLA-Richtlinie berechnet wird.

Die SLA-Verfolgung muss explizit und für die Programmleitung sichtbar sein. Ein Befund, der sein SLA ohne Abschluss überschreitet, sollte eine automatische Eskalation auslösen: zuerst an den Teamleiter, dann an den ISSO, dann an den Systemeigentümer. Programme sollten wöchentlich eine SLA-Compliance-Kennzahl veröffentlichen — Prozentsatz der innerhalb der SLA nach Schweregrad abgeschlossenen Befunde — als Programm-Gesundheitsindikator, der in das kontinuierliche Monitoring-Reporting einfließt, das der AO erhält.

Für klassifizierte Infrastruktur trägt die Ticketing-Integration zusätzliche Einschränkungen. Tickets mit spezifischen Befunddetails (Ressourcennamen, IP-Adressen, Konfigurationsdetails) müssen möglicherweise auf klassifizierten Systemen vorhanden sein, wenn die Informationen selbst klassifiziert sind. Programme sollten bewerten, ob CSPM-Befunddetails das CUI-Niveau oder darüber erreichen — oft tun sie es, insbesondere wenn Befunde die Netzwerkexposition von Ressourcen mit klassifizierten Hostnamen beschreiben — und Tickets entsprechend weiterleiten. Nicht klassifizierte Zusammenfassungsmetriken (Befundanzahl, SLA-Leistung) können auf nicht klassifizierten Systemen gemeldet werden.

Risikoakzeptanz-Workflows formalisieren den Umgang mit Befunden, die nicht sofort behoben werden können. Der Workflow ist:

1. Der ISSO reicht einen Risikoakzeptanz-Antrag ein, der dokumentiert: den spezifischen Befund, den technischen oder operativen Grund, warum eine sofortige Behebung nicht machbar ist, identifizierte kompensierende Kontrollen, die das Risiko in der Zwischenzeit reduzieren, und den vorgeschlagenen Akzeptanzzeitraum (nicht mehr als 90 Tage für Befunde mit hohem Schweregrad)
2. Das Sicherheitsteam überprüft und validiert die Behauptungen zu kompensierenden Kontrollen
3. Der AO überprüft und unterzeichnet das Risikoakzeptanz-Memo und akzeptiert damit formal das Restrisiko
4. Der Befund wird als offenes POA&M-Element in eMASS mit dem unterzeichneten Memo eingegeben
5. CSPM unterdrückt den aktiven Befundsalarm und behält ihn im Prüfverlauf, markiert mit der Akzeptanzdatensatznummer
6. Eine Kalender-Erinnerung wird 30 Tage vor Ablauf der Akzeptanz gesetzt, um Erneuerung oder Behebung einzuleiten

Dieser Prozess stellt sicher, dass akzeptierte Ausnahmen für den AO sichtbar, zeitlich begrenzt und nicht still akkumulierend sind. Zero-Trust-Mikrosegmentierungsarchitekturen für die Verteidigung profitieren direkt von diesem Workflow, da Mikrosegmentierungsrichtlinienänderungen, die CSPM-Befunde beeinflussen, durch denselben formalen Ausnahmeprozess verfolgt werden müssen, um die ATO-Kontinuität aufrechtzuerhalten.

Kontinuierliches Compliance-Reporting

Der ATO-Prozess für DoD-Systeme unter dem Risk Management Framework (RMF) erfordert einen umfassenden Body of Evidence (BOE), der nachweist, dass Sicherheitskontrollen implementiert und wirksam sind. Für Cloud-Infrastrukturkontrollen bestand dieser Nachweis traditionell aus manuell generierten STIG-Scan-Berichten und Konfigurations-Screenshots, die zum Bewertungszeitpunkt erstellt wurden. CSPM ermöglicht ein grundlegend anderes Modell: kontinuierlich generierte und auf Anfrage verfügbare Nachweise, anstatt während eines intensiven Nachweis-Sammelsprints vor jeder Bewertung erstellt zu werden.

Eine CSPM-Architektur für kontinuierliches Compliance-Reporting produziert drei Kategorien von Ausgaben:

Automatisierte ATO-Nachweispakete. CSPM-Compliance-Berichte, die wöchentlich und vor jedem Bewertungsereignis exportiert werden, liefern strukturierte Nachweise über den Implementierungsstatus von Kontrollen. Berichte werden eMASS-Kontrollkennungen zugeordnet — ein auf AU-2-Befunde gefilterter CSPM-Bericht demonstriert den Zustand der Audit-Ereigniskonfiguration; ein CM-6-Bericht demonstriert die Durchsetzung der Konfigurations-Baseline. Diese können über die REST-API an eMASS übertragen oder als Nachweisartefakte hochgeladen werden. Die Rolle des ISSO verschiebt sich von der Nachweisgenerierung zur Überprüfung und Zertifizierung von Nachweisen, die das System automatisch generiert.

Kontroll-Vererbungszuordnung. In Cloud-Umgebungen, die das gemeinsame Verantwortungsmodell verwenden, werden viele Kontrollen vom CSP (Cloud Service Provider) geerbt und nicht vom Mandanten implementiert. CSPM muss so konfiguriert werden, dass diese Vererbung widergespiegelt wird: Prüfungen für physische Zugriffskontrollen, Hypervisor-Patching und physische Rechenzentrumssicherheit werden CSP-geerbten Kontrollen zugeordnet und sollten nicht als Mandantenbefunde erscheinen. Mandantenverantwortliche Kontrollen — IAM, Netzwerk, Verschlüsselung, Protokollierung — sind der CSPM-Geltungsbereich. Ein korrekt konfiguriertes CSPM-System erstellt eine Vererbungszuordnung, die dem Systemsicherheitsplan entspricht, und vermeidet sowohl falsche Befunde bei geerbten Kontrollen als auch Lücken bei mandantenverantwortlichen Kontrollen.

Automatisierte POA&M-Updates. Offene CSPM-Befunde sollten automatisch als offene Elemente in das eMASS-POA&M einfließen. Wenn Befunde behoben werden und CSPM die korrigierte Konfiguration verifiziert, sollten die entsprechenden POA&M-Elemente mit Abschlussnachweisen aktualisiert werden. Dies schließt den Kreislauf zwischen dem Sicherheitstool und dem maßgeblichen Datensatz der Kontrolldurchführung — der ISSO muss keine Informationen mehr manuell zwischen Systemen übertragen, und der AO hat immer ein genaues Bild der offenen Befunde und ihres Behebungsstatus.

Ein Beispiel eines CSPM-zu-eMASS-Integrationsflusses veranschaulicht die Datenbewegung:

# CSPM → eMASS Integration (illustrativ)

CSPM-Befund:
  id: CSPM-2026-06-25-0041
  check: aws-s3-bucket-encryption-enabled
  resource: arn:aws:s3:::dod-app-data-prod
  severity: High
  controls: [SC-28, SC-28(1), SRG-APP-000428]
  status: FAIL
  detected: 2026-06-25T09:14:22Z
  sla_due: 2026-07-25T09:14:22Z

eMASS POA&M-Eintrag (automatisch erstellt):
  weakness_name: S3-Bucket ohne Verschlüsselung im Ruhezustand
  control: SC-28(1) / SRG-APP-000428
  scheduled_completion: 2026-07-25
  milestone: SSE-KMS mit CMK auf Bucket dod-app-data-prod aktivieren
  resources_required: Cloud-Platform-Team, geschätzt 2h
  status: Laufend
  evidence_artifact: cspm-finding-CSPM-2026-06-25-0041.json

Der langfristige Nutzen dieser Integration ist eine Transformation in der Durchführung von ATO-Verlängerungen. Anstatt einer intensiven Vorab-Nachweis-Sammelphase — die in traditionellen Programmen wochenlange Sicherheitsteamarbeit erfordert und das Risiko von Nachweislücken birgt — kann ein Programm mit reifer CSPM-Integration in Stunden ein aktuelles, vollständiges Nachweispaket generieren. Die kontinuierlichen Monitoring-Daten sind der Nachweis. Dies ist das Betriebsmodell, das DoDs Übergang zu laufender Autorisierung (kontinuierliches ATO) vorsieht, und CSPM ist das grundlegende Tool, das es für cloud-gehostete Verteidigungs-Workloads erreichbar macht.