Trügerische Transparenz: Cloud Security braucht mehr als Tools 

Das Wichtigste in Kürze

• CTEM ist ein kontinuierliches, fünfphasiges Programm (Scoping, Discovery, Prioritization, Validation, Mobilization), das Security von reaktivem Schwachstellenmanagement zu proaktiver, geschäftsorientierter Risikosteuerung verschiebt.
• CTEM ist kein einzelnes Tool — sondern ein Operating Model, das Technologie, Prozesse und Verantwortlichkeiten zusammenführt.
• Der Ausgangspunkt ist nicht Beschaffung, sondern Konsolidierung: bestehende Tool-Landschaften rationalisieren, bevor neue Plattformen eingeführt werden.
• KI beschleunigt die Identifikation und Bewertung von Exposures erheblich und sorgt dafür, dass Risiken deutlich schneller sichtbar werden. Damit aus dieser Geschwindigkeit wirksames Handeln entsteht, brauchen Organisationen ein starkes Operating Model — sonst führt schnellere Erkennung nicht automatisch zu schnellerer Reaktion.
• Entscheidend für den Erfolg: ein klar definiertes Target Operating Model, bereichsübergreifende Zusammenarbeit und die Bereitschaft der Führungsebene, CTEM als dauerhaftes Programm zu tragen — nicht als einmaliges Projekt.

Die Sichtbarkeitslücke 

Den meisten Organisationen fehlt es heute nicht an Sicherheitsdaten — sie ertrinken darin. Cloud Native Application Protection Platforms (CNAPP), die CSPM, CWPP, CIEM und DSPM vereinen, haben eine beispiellose Transparenz über Cloud-Umgebungen geschaffen. Doch trotz dieser Sichtbarkeit fällt es Sicherheitsteams schwer, die eine Frage zu beantworten, die am meisten zählt: Wo liegt unser kritischstes Geschäftsrisiko — genau jetzt? 

Diese Lücke will Continuous Threat Exposure Management (CTEM) schließen. Von Gartner eingeführt, ist CTEM ein kontinuierliches Fünf-Phasen-Programm — Scoping, Discovery, Prioritization, Validation und Mobilization — das Security von reaktivem Lückenmanagement hin zu proaktiver, geschäftsorientierter Risikoreduktion verschiebt. Technisch baut CTEM auf bestehenden Cloud-Security-Tools auf — CNAPP, Breach and Attack Simulation (BAS), Cyber Threat Intelligence (CTI)-Plattformen — und verbindet deren Ergebnisse in einem Exposure Graph, der Assets, Identitäten, Schwachstellen und Datensensitivität zu durchgängigen Attack Paths zusammenführt. Das gibt Organisationen die kontextuelle Sicht, die sie brauchen, um knappe Ressourcen auf die Exposures zu fokussieren, die wirklich geschäftsrelevant sind. 

Doch hier liegt die unbequeme Wahrheit, die in den meisten CTEM-Diskussionen ausgespart wird: Die größte Herausforderung bei CTEM ist nicht die Technologie. Es sind Menschen und Prozesse. 

Erst konsolidieren, dann automatisieren: Ohne tragfähige Prozesse verstärkt KI nur bestehende Schwächen 

Der Reflex der Branche bei neuen Security-Herausforderungen ist häufig, eine weitere Plattform zu beschaffen. CTEM gefordert? Plattform beschaffen, Exposure Graph aufbauen, Tickets automatisieren — fertig. Tatsächlich sollte die Einführung von CTEM mit einem kritischen Blick nach innen beginnen: die bestehende Security-Tool-Landschaft rationalisieren — Redundanzen beseitigen, Lizenzkosten senken und die schlanke Integrationsschicht schaffen, die ein kontinuierliches Programm verlangt. Doch selbst mit einer rationalisierten, erstklassigen Toollandschaft reicht Technologie allein nicht aus. 

Das gilt ebenso für die neueste Generation KI-gestützter Security-Plattformen. AI Assistants, autonome Agenten und graphbasierte Analyze Engines verändern grundlegend, wie Exposures entdeckt, priorisiert und validiert werden — und komprimieren, was bisher Wochen dauerte, auf Minuten. Doch KI verkürzt auch das Zeitfenster der Angreifer: Das Fenster zwischen CVE-Veröffentlichung und aktiver Ausnutzung schrumpft auf Stunden. Das Ergebnis ist ein Paradoxon — Organisationen haben bessere Tools und weniger Zeit. Ohne ein Operating Model, das auf KI-generierte Erkenntnisse in Echtzeit reagieren kann, bedeutet schnellere Erkennung lediglich schnelleres Bewusstsein über Versäumnisse, die niemand befugt ist zu beheben. 

CTEM ist, wie dargelegt, kein einzelnes Tool, sondern ein ganzheitlicher Prozess, der kontinuierlich und über Teamgrenzen hinweg arbeitet. Das macht die klassische Triade aus People, Processes und Technology relevanter denn je. Dennoch investieren die meisten Organisationen weiterhin überproportional in Technologie, während die Grundlagen bei Menschen und Prozessen unterfinanziert bleiben. Bei CTEM ist dieses Ungleichgewicht der häufigste Grund, warum Programme ins Stocken geraten. 

Bereichsübergreifende Zusammenarbeit als Voraussetzung 

CTEM erfordert bereichsübergreifende Zusammenarbeit auf einem Niveau, das die meisten Sicherheitsorganisationen noch nicht operationalisiert haben. Cloud Security Engineering, SecOps, Plattformteams und Application Owner spielen alle eine Rolle — doch CTEM verlangt, dass sie als integrierte Kette agieren, nicht als nebeneinander existierende Silos. Ein Finding muss nahtlos von der Discovery über die Validation bis zur Remediation fließen, mit geteiltem Kontext und gemeinsamer Verantwortlichkeit an jedem Übergabepunkt. Wenn Teams nur für ihre eigene Domäne optimieren, bleiben Exposures in den Lücken zwischen ihnen stecken. 

Was es kostet, das falsch zu machen, ist real — und aktuell. Ende 2023 wurde eine kritische Schwachstelle in Citrix NetScaler (CVE-2023-4966, weithin bekannt als „Citrix Bleed") von Ransomware-Gruppen wie LockBit in kürzester Zeit ausgenutzt. Viele Organisationen spielten den Herstellerpatch umgehend ein — und blieben dennoch kompromittiert. Die vollständige Behebung erforderte nicht nur das Patching, sondern auch die Invalidierung aktiver Session Tokens: ein mehrstufiger Prozess, der koordiniertes Handeln über Netzwerk-, Identitäts- und Sicherheitsteams hinweg voraussetzte. Wo diese Übergaben nicht definiert oder Zuständigkeiten unklar waren, blieb die Remediation unvollständig — und Angreifer behielten Zugang, obwohl der Patch eingespielt war. Die Ursache war kein fehlendes Tool. Es war ein fehlender Prozess.¹

CTEM adressiert genau dieses Muster, indem es ein einheitliches operatives Lagebild über alle beteiligten Teams hinweg bereitstellt. Jede Exposure trägt den vollständigen Kontext — Asset, Verantwortlicher, Geschäftskritikalität, Risikobewertung und empfohlene Behebungsmaßnahme — sodass jede Übergabe strukturiert, nachvollziehbar und verantwortlich zugeordnet ist. Wenn ein Finding vom Security Engineering an ein Plattformteam oder einen Application Owner übergeht, wandert der Kontext mit — und verhindert, dass Exposures unbemerkt zwischen Teamgrenzen verloren gehen. 

Das Operating Model hinter dem Lifecycle 

CTEM erfordert, was vielen Organisationen nach wie vor fehlt: ein klar definiertes Target Operating Model (TOM) und eine RACI-Struktur, die Continuous Exposure Management als bereichsübergreifende Fähigkeit verankert, getragen von Governance-Funktionen, die Richtlinien durchsetzen, Schwellenwerte für Risikoakzeptanz definieren und Ausnahmen steuern. Gemeinsam bilden sie das Bindegewebe zwischen den Teams und die durchgängige Prozesstransparenz und Steuerung, die häufig das kritischste fehlende Element ist. Ohne sie kann die Unternehmensführung nicht unterscheiden, ob ein Programm tatsächlich Risiken reduziert oder lediglich Dashboards produziert.

Von periodischen Projekten zu kontinuierlichen Programmen

Der tiefgreifendste Wandel, den CTEM verlangt, ist häufig organisatorischer, nicht technischer Natur. Traditionelles Vulnerability Management ist periodisch, kampagnengetrieben und Compliance-motiviert. CTEM ist kontinuierlich, geschäftsrisikogetrieben und ergebnisorientiert. Das ist ein fundamental anderer Betriebsrhythmus. 

Messbarkeit als Führungsinstrument

Ein CTEM-Programm, das nicht gemessen wird, verliert innerhalb weniger Monate die Aufmerksamkeit der Führungsebene. Dabei geht um KPIs, die den Geschäftswert von Exposure Management sichtbar machen. Fünf Beispiel-Kennzahlen mit hoher Aussagekraft:

• Mean Time to Remediate (MTTR) nach Kritikalität: Wie schnell werden kritische Exposures tatsächlich geschlossen? Nicht der Durchschnitt über alle Findings zählt, sondern die Behebungszeit für Exposures mit dem höchsten Risikoscore.
• Exposure-Aging: Wie viele kritische Exposures überschreiten definierte Behebungsfristen? Ein steigender Anteil gealterter Findings ist ein klarer Indikator für Prozess- oder Zuständigkeitsprobleme.
• Abdeckungsgrad: Welcher Anteil der geschäftskritischen Assets ist tatsächlich im CTEM-Programm erfasst? Eine hohe Zahl an Findings ist wertlos, wenn wesentliche Teile der Angriffsfläche nicht im Scope liegen.
• Validierungsrate: Wie viele priorisierte Exposures werden tatsächlich validiert, bevor sie in die Remediation gehen? Eine niedrige Rate bedeutet, dass Teams auf Basis ungeprüfter Annahmen arbeiten und knappe Ressourcen auf False Positives verschwenden.
• Bereichsübergreifende Handoff-Effizienz: Wie lange dauert es vom Discovery eines Findings bis zur Zuweisung an den verantwortlichen Remediation Owner? Diese Metrik macht sichtbar, ob das Operating Model funktioniert oder ob Findings zwischen Teams liegen bleiben. 

Diese KPIs verschieben die Diskussion von „Wie viele Schwachstellen haben wir gefunden?" hin zu „Wie effektiv reduzieren wir geschäftsrelevantes Risiko?" Sie geben der Führungsebene die Steuerungsfähigkeit, die ein kontinuierliches Programm verlangt.

Ohne Rückhalt der Führungsebene kein nachhaltiges Programm

Für CISOs und andere Sicherheitsverantwortliche bedeutet das: CTEM nicht als einmaliges Implementierungsprojekt zu positionieren, sondern als lebendes Programm, das dauerhafte Unterstützung durch die Unternehmensleitung, dedizierte Ressourcen und das organisatorische Mandat für bereichsübergreifende Verantwortlichkeit erfordert. Ohne dieses Commitment von oben verliert selbst das beste Operating Model mit der Zeit an Wirkung. 

Die Frage, die sich jedes Security-Leadership-Team stellen sollte, bevor es seine CTEM-Ambitionen vorantreibt: Haben wir das Operating Model, die Rollenklarheit und das organisatorische Commitment, um dies als kontinuierliches Programm zu tragen? 

Wenn die Antwort „noch nicht" lautet, dann beginnt genau dort Ihre CTEM-Reise.

¹ Google Cloud Blog, Tenable Blog

Häufig gestellte Fragen