Klassisches Schwachstellenmanagement stößt an seine Grenzen
Klassisches Vulnerability Management funktionieren folgendermaßen: Scanner laufen, CVEs werden gesammelt, nach CVSS-Score sortiert, und die Liste wandert an die IT-Abteilung zum Abarbeiten. Das Problem dabei ist nicht die Technik, sondern die Logik dahinter. Ein CVSS-Score sagt nichts darüber aus, ob eine Schwachstelle in der eigenen Umgebung überhaupt erreichbar ist, ob sie gerade aktiv ausgenutzt wird, oder wie wichtig das betroffene System fürs Geschäft ist. Das Ergebnis sind Listen mit tausenden offenen Findings, von denen die meisten nie zu einem echten Vorfall führen – während die wenigen wirklich kritischen Lücken in der Masse untergehen.
Dazu kommt: Cloud-Assets entstehen und verschwinden innerhalb von Stunden, Identitäten sammeln Berechtigungen schneller an, als Teams sie nachverfolgen können, und Angreifer nutzen mittlerweile selbst KI-gestützte Methoden, um Schwachstellen innerhalb von Stunden statt Wochen zu identifizieren und auszunutzen. Eine Welt, in der sich Scanner-Zyklen an einem monatlichen Rhythmus orientieren, kann mit diesem Tempo nicht mithalten.
Was CTEM anders macht
CTEM wurde von Gartner als Rahmenmodell beschrieben und funktioniert nicht als Produkt oder einmaliges Audit, sondern als wiederkehrender Prozess in fünf Phasen:
- Scoping – Zuerst wird abgesteckt, was überhaupt geschützt werden muss: Assets, Cloud-Umgebungen, Identitäten, externe Angriffsflächen und Geschäftsprozesse. Hier tauchen erfahrungsgemäß auch Dinge zum ersten Mal auf, die bislang niemand auf dem Schirm hatte – nicht freigegebene SaaS-Tools etwa, oder vergessene, nach außen offene Dienste.
- Discovery – Anschließend werden Schwachstellen, Fehlkonfigurationen und Risiken innerhalb dieses Scopes erfasst. Ziel ist dabei ausdrücklich nicht, absolut alles zu finden, sondern alles, was innerhalb des definierten Bereichs kritisch ist.
- Prioritization – Das Herzstück von CTEM. Statt nach Schweregrad allein zu sortieren, werden vier Fragen gestellt: Kann ein Angreifer das Asset überhaupt erreichen? Ist die Schwachstelle tatsächlich ausnutzbar? Wie wichtig ist das betroffene System fürs Geschäft? Und: Existieren bereits kompensierende Kontrollen? Wird diese Phase ernst genommen, schrumpft die Zahl der wirklich handlungsrelevanten Findings in der Regel drastisch.
- Validation – Bevor etwas behoben wird, wird geprüft, ob die geplante Maßnahme überhaupt sicher ist: Löst eine neue IPS-Regel False Positives aus? Bricht eine Konfigurationsänderung eine Geschäftsanwendung? Dieser Schritt wird in der Praxis am häufigsten übersprungen – und ist gleichzeitig einer der wichtigsten, weil er Vertrauen zwischen Security- und Infrastruktur-Teams schafft.
- Mobilization – Die validierte, priorisierte Schwachstelle wird an die richtige Stelle zur Behebung weitergegeben, mit dem passenden Kontext und der passenden Dringlichkeit. Diese Phase gilt als der am meisten unterschätzte Teil des gesamten Modells.
Die eigentliche Lücke liegt nicht im Finden, sondern im Schließen, oder?
Was ich in der Praxis am häufigsten beobachte: Die größte Verzögerung entsteht nicht dabei, eine Schwachstelle zu entdecken oder zu bewerten, sondern danach. Fünf Muster tauchen dabei immer wieder auf: Niemand fühlt sich für das Ergebnis verantwortlich, obwohl jedes Team seinen eigenen Alarm bearbeitet. Teams priorisieren nach unterschiedlichen Kriterien, ohne gemeinsamen Kontext. Freigaben laufen manuell und uneinheitlich. Behebungen werden nicht vorab validiert, wodurch Teams zögern oder zusätzliche manuelle Tests einschieben. Und es fehlt eine einheitliche Verantwortlichkeit, die den Fortschritt von der Entdeckung bis zum Schließen einer Lücke nachvollziehbar macht.
Angreifer warten nicht auf den nächsten Change-Management-Zyklus. Genau deshalb ist die Zeit, in der eine Schwachstelle offen bleibt – die sogenannte Exposure Dwell Time – die Kennzahl, die für mich mittlerweile aussagekräftiger ist als die reine Anzahl gefundener Schwachstellen.
Warum das Thema gerade jetzt an Bedeutung gewinnt
Die Bedrohungslage verschärft sich spürbar schneller, als klassische Prozesse mithalten können. Angreifer brauchen oft keine Zero-Days, sondern nutzen das, was in den meisten Umgebungen ohnehin vorhanden ist: Fehlkonfigurationen, wiederverwendete Zugangsdaten, offene Ports, ungepatchte, aber nach außen erreichbare Dienste. Check Point geht davon aus, dass bis 2028 mehr als 60 Prozent aller Sicherheitsvorfälle auf genau solche Fehlkonfigurationen zurückgehen werden – nicht auf neue, unbekannte Angriffstechniken. Gleichzeitig wächst mit NIS2 und vergleichbaren Regularien der Druck, Risikomanagement nicht nur zu betreiben, sondern auch nachvollziehbar zu dokumentieren.
CTEM ist deshalb für mich kein Hype-Begriff, sondern eine überfällige Antwort auf eine Realität, die sich in den letzten Jahren fundamental verändert hat: mehr Angriffsfläche, mehr Tempo bei Angreifern, und Sicherheitsteams, die nicht unbegrenzt mitwachsen. Wer weiterhin jede Schwachstelle gleich behandelt, verbrennt Kapazität an den falschen Stellen. Wer dagegen konsequent nach Erreichbarkeit, Ausnutzbarkeit und Geschäftsrelevanz priorisiert, validiert und die Behebung tatsächlich bis zum Ende durchzieht, reduziert das reale Risiko spürbar – mit denselben Teams und demselben Budget.
Fazit
CTEM ersetzt klassisches Schwachstellenmanagement nicht komplett, aber es verändert die Reihenfolge der Fragen: nicht "Wie viele Schwachstellen haben wir?", sondern "Welche davon können uns tatsächlich schaden, und wie schließen wir sie mit Zuversicht?".
Für Unternehmen, die ihre Sicherheitsarbeit an begrenzten Ressourcen und wachsendem Druck ausrichten müssen, ist das aus meiner Sicht keine Kür mehr, sondern eine der sinnvollsten Weiterentwicklungen im Risikomanagement der letzten Jahre. Wollen Sie sich mit mir persönlich zu dem Themen austauschen? Dann einfach direkt eine Anfrage an uns schicken!
