Die CTEM-Validierungsstufe in AWS, mit realen Zahlen

Vom Pathbreak-Team · 25. Oktober 2026 · 6 Min. Lesezeit

Continuous Threat Exposure Management ist eine Programmstruktur mit fünf Stufen. Das Scoping legt fest, welche Systeme zum Programm gehören. Die Discovery findet die Exposures darin. Die Priorisierung ordnet die Exposures. Die Validierung beweist, welche der priorisierten Exposures ein Angreifer nutzen könnte. Die Mobilisierung sorgt dafür, dass die bewiesenen von den Verantwortlichen behoben werden. Die Definition ist anderswo gut beschrieben, dieser Beitrag behandelt deshalb die vierte Stufe, in AWS, mit Zahlen aus einem realen Konto.

Wo AWS-Programme stecken bleiben

Die Discovery ist in AWS gut abgedeckt. Ein CSPM oder ein Scanner liefert an einem Nachmittag Tausende Findings: öffentliche Buckets, zu breite Policies, ungenutzte Schlüssel, fehlende Verschlüsselung, Rollen mit Wildcard-Vertrauen. Die Priorisierung ist ebenfalls gut abgedeckt, mit Severity Scores, Exploitability Scores und Tags zur Asset-Kritikalität, die die Liste sortieren.

Der Stillstand kommt auf der nächsten Stufe. Eine priorisierte Liste mit 3,000 Findings ist immer noch eine Liste mit 3,000 Findings, und die Priorisierung ist eine Schätzung. Ein kritisches Finding auf einer Rolle, die eine SCP bereits eingezäunt hat, verändert nichts. Ein mittleres Finding auf einer Rolle, die dem Konto eines Anbieters vertraut, könnte der Pfad in die Produktion sein. Ohne Validierung wählt das Team seine Arbeit nach Score aus, und der Score wurde berechnet, ohne die Autorisierung zu lesen, die darüber entscheidet, ob ein Angriff funktioniert.

Wie Validierung in der AWS Control Plane aussieht

In AWS sind die Züge des Angreifers API-Aufrufe. Jeder Aufruf wird durch einen Satz von Dokumenten erlaubt oder verweigert, die AWS gemeinsam auswertet: die Identity Policies des Aufrufers, eine etwaige Permission Boundary, die Service Control Policies auf der Organisationseinheit, die Trust oder Resource Policy auf dem Ziel und die Conditions auf jedem Statement. Validierung bedeutet, die Kandidatenkette aufzubauen und dann diese Dokumente für jeden Schritt der Kette so aufzulösen, wie AWS es tun würde. Löst sich jeder Schritt zu Allow auf, ist der Pfad bewiesen. Löst sich irgendein Schritt zu Deny auf, wird der Pfad von der Liste entfernt.

Nichts davon erfordert, etwas auszuführen. Der Beweis ist das Ergebnis der Autorisierung, und zum Lesen von Policies braucht es nur Lesezugriff. Das macht die Stufe in der Praxis kontinuierlich: Sie kann jeden Tag auf jedem Konto laufen, ohne Wartungsfenster.

Die Zahlen aus dem Laborkonto

Das Pathbreak-Laborkonto ist die Umgebung hinter den Zahlen auf der Startseite. Das hat die Validierungsstufe dort ergeben.

Diese Zahlen zeigen, wofür Validierung da ist. Tausende Kandidatenpfade waren nicht Tausende unabhängige Probleme. Die meisten liefen über dieselben wenigen Rollen, sodass eine kleine Zahl von Änderungen, auf den richtigen Principals platziert, die meisten bewiesenen Pfade auf einmal unterbrochen hat. Eine nach Schweregrad sortierte Liste hätte dasselbe Konto als 4,942 Einträge von ungefähr gleichem Gewicht gezeigt und das Team losgeschickt, sie einen nach dem anderen zu beheben.

Was die Mobilisierung von der Validierung braucht

Die fünfte Stufe scheitert, wenn die Person, der die Rolle gehört, ein Finding erhält, mit dem sie nichts anfangen kann. Die Validierung sollte drei Dinge übergeben. Den bewiesenen Pfad, als Kette mit jedem benannten Hop, damit der Verantwortliche sieht, warum die Rolle darauf liegt. Die konkrete Änderung, die ihn unterbricht: ein Deny-Statement, eine iam:PassedToService-Condition, eine engere Trust Policy, eine entfernte Berechtigung, geschrieben als die Änderung selbst, bereit zum Anwenden. Und eine Bestätigung: Nachdem die Änderung ausgerollt ist, wird der Pfad erneut ausgewertet und das Ergebnis festgehalten, sodass das Ticket auf Grundlage von Belegen geschlossen wird.

Im Labor waren 81 Prozent der Fixes ein einziger Befehl. Für die Mobilisierung ist das wichtig, weil eine einzeilige Änderung an einer IAM Policy in Minuten durch das Review geht, während die Neugestaltung einer Rollenhierarchie ins nächste Quartal wandert.

Die Stufe kontinuierlich machen

Konten driften mit jedem Deployment. Eine neue Rolle, eine erweiterte Trust Policy, eine Pipeline, die iam:PassRole auf einen Wildcard bekommt, und ein Pfad, der letzten Monat geschlossen war, ist wieder offen. Die Validierungsstufe bleibt nur dann nützlich, wenn sie nach Zeitplan läuft und meldet, was sich geändert hat, sodass das Team neue bewiesene Pfade an dem Tag sieht, an dem sie auftauchen, und ebenso bestätigte Fixes, die seitdem wieder zurückgefallen sind.

Schreibgeschützte Validierung macht das günstig. Es braucht weder einen Agenten noch ein Wartungsfenster, und der Test selbst birgt kein Risiko für die Produktion, sodass tägliche Läufe über jedes Konto der Standard sind.

Was Sie eine CTEM-Plattform zu AWS fragen sollten

Löst sie SCPs, Permission Boundaries, Trust Policies und Condition Keys für jeden Schritt eines Pfads auf? Sortiert sie danach, was ein Pfad erreicht, über Konten hinweg? Benennt sie die Änderung, die jeden Pfad unterbricht, und bestätigt sie die Änderung anschließend? Kann sie täglich laufen, ohne etwas im Konto auszuführen? Die Antworten sagen Ihnen, was die Plattform Ihrem Team auf der Mobilisierungsstufe übergeben wird.

Pathbreak ist für diese Stufe in AWS gebaut. Der Beitrag zu AEV für AWS behandelt die Validierungsmethode ausführlicher, und der Beitrag Analyse vs. Validierung führt eine Kette von erreichbar bis bewiesen.

Häufig gestellte Fragen