FedRAMP VDR und VER verlangen kontinuierliche Sicherheitsnachweise

Die FedRAMP-Regeln VDR und VER verlangen kontinuierliche Sicherheitsnachweise, nicht nur häufigere Scans. Gemäß der Mitteilung, die auf die Binding Operational Directive 26-04 von CISA reagiert, müssen alle Cloud-Service-Angebote, die eine FedRAMP-Zertifizierung erhalten oder aufrechterhalten wollen, ab dem 7. Dezember 2026 die Anforderungen an die Erkennung und Reaktion auf Schwachstellen erfüllen, mit einer Übergangsfrist bis zum 7. März 2027 für Angebote, die unter einem Korrekturmaßnahmenplan betrieben werden. Das Problem für viele Programme ist nicht das Datum selbst; es ist die Tatsache, dass die Regeln wie ein Scan-Mandat aussehen, aber tatsächlich ein anderes Betriebsmodell erfordern.

Der alte Ansatz war ein pauschaler monatlicher Scan in Verbindung mit einem Plan of Actions and Milestones (POA&M), einer manuellen Liste offener Probleme. FedRAMP legt nun die Erkennungshäufigkeit je nach Zertifizierungsklasse fest. Regel VDR-TFR-PSD besagt, dass maschinenbasierte Ressourcen wie Server und virtuelle Maschinen mindestens alle 14 Tage für Anbieter der Klasse A, alle 7 Tage für Klasse B, alle 3 Tage für Klasse C und mindestens einmal pro Tag für Klasse D gescannt werden müssen. Separate maschinelle Verifikations- und Validierungsprüfungen laufen mindestens monatlich für Rev5-Inhaber und bis zu alle 3 Tage für höhere 20x-Klassen.

Drei Bestimmungen ändern die Engineering-Arbeit am direktesten. Die Sanierungsfristen sind gestaffelt und eng: Regel VDR-TFR-PVR legt Fristen für die Behebung basierend auf dem PAIN-Rating einer Schwachstelle, einem Schweregrad-Score, und ob sie bekanntermaßen ausgenutzt wird, fest. Die Fristen reichen von 192 Tagen am unteren Ende bis hinunter zu 12 Stunden für ein Klasse-D-Angebot mit einer PAIN-5-Schwachstelle, die sowohl wahrscheinlich ausgenutzt als auch sofort remote ausnutzbar ist. Eine 12-Stunden-Frist ist kein routinemäßiger Service-Level für eine Ticket-Warteschlange; es ist eine Frage von Paging und Zuständigkeit, die auch an einem Feiertagswochenende funktionieren muss. Die Beweislast ist ebenfalls umgekehrt: Regel VER-EVA-AIA, genannt Assume It's Automatable, verlangt von Anbietern, standardmäßig davon auszugehen, dass Exploits automatisiert werden können, es sei denn, sie haben Beweise, die das Gegenteil zeigen. Jede Verzögerung erfordert daher ein verteidigungsfähiges Artefakt, das in großem Umfang und nach derselben Uhr produziert wird. Schließlich zählen nun auch Prozessfehler als Schwachstellen: Regel VDR-CSO-FAV besagt, dass Anbieter Probleme oder Fehler in ihren Prozessen zur Erkennung und Reaktion auf Schwachstellen als Schwachstellen behandeln müssen. Wenn die Erkennungspipeline stillschweigend stoppt, ist das kein leiser operativer Schluckauf; das System, das Beweise produziert, ist selbst im Geltungsbereich. Zusammengenommen ändern diese Bestimmungen das Ergebnis von mehr Scans hin zu einem System, das verteidigungsfähige, aktuelle, maschinenlesbare Antworten über Exposition liefert und rechenschaftspflichtig ist, wenn es den Betrieb einstellt.

Der 7. Dezember ist nur die erste Rate. Die Consolidated Rules for 2026 haben FedRAMP in Regelsätze reorganisiert und einen viel größeren Übergang eingeleitet. FedRAMP beschreibt Rev5 als einen Legacy-Zertifizierungsprozess, der vollständig durch FedRAMP 20x ersetzt wird, und sagt, dass Anbieter neue Regeln befolgen und neue FedRAMP Practices aus 20x in ihre Rev5-Angebote übernehmen sollen. Die neuen Regeln werden am 1. Januar 2027 für alle Stakeholder verpflichtend, und FedRAMP akzeptiert ab dem 11. Juni 2027 keine neuen Rev5-Anträge mehr. Das bedeutet, dass VDR und VER kein Umweg vor dem eigentlichen Übergang sind; sie sind der Übergang, der in Raten ankommt. Arbeit, die als „bis Dezember durchkommen“ definiert ist, wird 2027 neu aufgebaut, während Arbeit, die als erster Teil der kontinuierlichen Validierung definiert ist, übertragen wird.

Die strukturellen Änderungen zeigen, wohin das Programm steuert. Der System Security Plan und seine Anhänge weichen einem Certification Package Overview und einem Security Decision Record. Plans of Action and Milestones wurden vollständig abgeschafft und durch eine Liste akzeptierter Schwachstellen ersetzt. Continuous Monitoring wird in Ongoing Certification umbenannt, weil der alte Begriff synonym mit Schwachstellen-Scans geworden war, aber die neuen Anforderungen sind viel breiter. FedRAMP war direkt darin, Lücken zu schließen, wo Dokumente die Realität ersetzten: Anbieter müssen moderne GRC-Fähigkeiten (Governance, Risk and Compliance) aufbauen oder kaufen und sie mit Automatisierung auf Basis realer Daten füllen, wo möglich, anstatt handgefertigte Dokumente zu pflegen. Fast nichts davon ist eine Forderung nach neuer Sicherheit; Zugriffskontrolle, Identität, Verschlüsselung, Protokollierung, Incident-Verfahren und Schulung bleiben weitgehend intakt. Was sich geändert hat, ist, dass ihre Beschreibung nicht mehr als Beweis für sie zählt.

Die Arbeit ist immer noch Compliance, aber das Ergebnis ist jetzt Engineering. Anbieter müssen eine Reihe laufender Validierungen übergeben, die aus den Systemen ziehen, die die Wahrheit enthalten, wie Cloud-Konfiguration, Identity Provider, ein SIEM, das Sicherheitsprotokolle aggregiert, CI/CD, der automatisierte Build- und Deployment-Prozess, und Ticketing, und maschinenlesbare Ergebnisse nach einem Zeitplan ausgeben. FedRAMP listet derzeit 49 Key Security Indicators in zehn Kategorien in CR26 auf, und Anbieter müssen sie persistent validieren; das ist eine Einstiegsanforderung, also ist jeder Übergangsplan im Kern ein Automatisierungs-Engineering-Plan. Jemand muss den kontinuierlichen Betrieb verantworten: Monatliches Monitoring hatte ein Fälligkeitsdatum und einen natürlichen Rhythmus des Aufholens, aber eine Validierungskadenz läuft entweder ständig oder stoppt stillschweigend, und der Unterschied ist unsichtbar, bis ein Prüfer oder Kunde ihn findet. Bevor Teams Pipelines bauen, sollten sie operative Fragen beantworten: Wer wird alarmiert, wenn eine Validierung fehlschlägt, was ist die Reaktionszeit, und wer bemerkt, wenn eine Beweisquelle stillschweigend ihre API ändert. FedRAMP definiert „persistent“ als auf eine feste, stetige Weise auftretend, die über einen langen Zeitraum trotz Hindernissen oder Schwierigkeiten wiederholt wird, eine Beschreibung eines Betriebszustands而非 eines Datums. Teams, die auf eine einzelne Einreichung hinarbeiten, bauen ein System, das auf einen Moment abgestimmt ist, und bauen es danach neu auf.

Sobald Beweise strukturierte Daten statt Narrative werden, gehören sie nicht mehr einem einzigen Framework. Die Identitätsnachweise, die einen FedRAMP-Indikator erfüllen, sind dieselben Nachweise, die ein SOC-2-Prüfer will und die ein Diligence-Team eines großen Kunden anfragt. Compliance hört auf, eine Reihe paralleler Projekte zu sein, die jeweils dasselbe Bild in einem anderen Vokabular neu aufbauen, und wird zu einem Substrat, aus dem viele Konsumenten lesen. Die Ökonomie kehrt sich um: Punkt-in-Zeit-Compliance-Kosten steigen mit jedem hinzugefügten Framework und jeder Region, weil jede Hinzufügung mehr Beschreibung zu produzieren und zu pflegen bedeutet. Kontinuierliche Validierung kostet mehr beim Aufbau und kaum mehr beim Betrieb. Der 7. Dezember ist ein hartes Datum, aber Aufsichtsbehörden für Finanzdienstleistungen, die Resilienz- und Produktsicherheitsregime der EU und Enterprise-Beschaffungsteams konvergieren auf dieselbe Forderung: Zeigen Sie den aktuellen Zustand, nicht die Beschreibung vom letzten Jahr. FedRAMP kam zuerst, weil es das klarste Mandat und die geringste Geduld hatte. Für Organisationen, die ihre eigenen Websites, Cloud-Konten oder Infrastruktur außerhalb des FedRAMP-Programms verwalten, gilt dasselbe Prinzip: Aktuelle, maschinenlesbare Nachweise Ihrer Sicherheitslage sind nützlicher als ein jährliches Zertifikat. AEU-I bietet sicherheitsorientierte IT, Infrastruktur und Beratung, die Teams dabei helfen kann, diese Art der kontinuierlichen Validierung aufzubauen und aufrechtzuerhalten.