CTEM 2026: Ein monatlicher Schwachstellenscan liefert oft Hunderte oder Tausende Befunde. Trotzdem kann ausgerechnet das System übersehen werden, das aktuell aus dem Internet erreichbar ist und eine tatsächlich ausgenutzte Schwachstelle aufweist. CTEM 2026 – Continuous Threat Exposure Management – ist ein Ansatz, mit dem Unternehmen ihre Angriffsflächen laufend verstehen, Risiken nach tatsächlicher Bedeutung priorisieren und den Erfolg von Maßnahmen nachweisen. Statt nur CVE-Listen abzuarbeiten, werden Asset-Kontext, Ausnutzungsinformationen, Geschäftsrelevanz und technische Validierung verknüpft. Der Leitfaden zeigt, wie ein solcher Prozess auch für mittelständische IT-Teams praktikabel wird.
GORTNET Fachredaktion · Stand: 25. Oktober 2026 · Fachartikel
Was ist Continuous Threat Exposure Management?
Continuous Threat Exposure Management beschreibt einen kontinuierlichen Zyklus zum Erkennen, Bewerten, Priorisieren und Reduzieren relevanter Angriffsflächen. Die Idee unterscheidet sich von einem einmaligen Penetrationstest oder einer regelmäßig exportierten Scannerliste. IT-Systeme ändern sich täglich: Ein neuer Cloud-Dienst wird veröffentlicht, eine Firewall-Regel geöffnet, ein administratives Konto erhält Rechte oder ein Lieferant fügt eine Fernwartungsschnittstelle hinzu. Eine Momentaufnahme bildet diese Änderungen nur unzureichend ab.
CTEM soll keine weitere unstrukturierte Datensammlung erzeugen. Ziel ist eine nachvollziehbare Entscheidungsgrundlage: Welche reale Angriffsfläche existiert, kann ein Angriffspfad die wichtigsten Geschäftsprozesse erreichen und welche Gegenmaßnahme senkt das Risiko mit angemessenem Aufwand? Ein erfolgreicher Prozess verbindet damit Security und Betrieb, statt deren Arbeit in getrennten Dashboards zu belassen.
CTEM 2026 beginnt mit einem belastbaren Asset-Inventar
Ohne verlässliche Asset-Daten lassen sich Scannerergebnisse kaum richtig bewerten. Ein Hostname sagt wenig darüber aus, ob ein System produktiv ist, Internetzugriff besitzt, sensible Daten verarbeitet oder ein kritischer Lieferant davon abhängt. Ergänzen Sie daher Inventare aus Active Directory, Cloud-Konten, Virtualisierung, Netzwerkmanagement und Endpoint-Management um Ansprechpartner und geschäftliche Kritikalität.
Bei der Erfassung unterscheiden Sie bekannte, verwaltete Anlagen von unbekannten extern sichtbaren Komponenten. Eine Subdomain oder öffentliche IP-Adresse kann einem alten Testsystem zugeordnet sein, das niemand mehr auf dem Radar hat. Führen Sie für ungeklärte Assets einen festen Zuordnungsprozess ein, statt sie einfach als „nicht zuordenbar“ aus Berichten herauszufiltern. Die Zahl ungeklärter Internet-Expositionen sollte im Zeitverlauf sinken.
Externe und interne Angriffsflächen getrennt betrachten
Eine öffentlich erreichbare Webanwendung ist anderen Bedrohungen ausgesetzt als ein isolierter Testserver. Trotzdem kann ein interner Dienst nach einer ersten Kompromittierung relevant werden, etwa weil ein Angreifer von einem Arbeitsplatzrechner aus auf ihn zugreifen kann. Deshalb sollten Sie äußere und innere Exposition unterscheiden, aber in derselben Risikobetrachtung zusammenführen. Bedenken Sie auch SaaS-Dienste, Identitäten und APIs.
Priorisieren Sie nicht allein anhand offener Ports. Ein SSL-Portal mit guter Absicherung kann weniger riskant sein als ein schlecht kontrollierter Managementzugriff über einen unauffälligen Dienst. Erfassen Sie Authentifizierung, MFA, Netzwerkherkunft, Patchstand, Identitätsrechte, übertragene Daten und mögliche Vertrauensbeziehungen. Ein priorisiertes Angriffsflächeninventar ist wertvoller als ein unkommentierter Internet-Scan.
CVSS, EPSS und CISA KEV richtig kombinieren
CVSS beschreibt die technischen Merkmale und Schwere einer Schwachstelle; ein hoher Wert zeigt aber nicht automatisch, dass eine Lücke aktiv ausgenutzt wird oder Ihr Unternehmen betrifft. Die von CISA veröffentlichte Liste Known Exploited Vulnerabilities (KEV) markiert CVEs mit bestätigter Ausnutzung nach den Kriterien der Behörde. Die EPSS-Werte von FIRST schätzen dagegen datenbasiert die Wahrscheinlichkeit einer Ausnutzung innerhalb der nächsten 30 Tage ab. Diese Signale beantworten unterschiedliche Fragen.
Eine sinnvolle Risikopriorisierung verwendet sie gemeinsam mit dem konkreten Asset-Kontext. Eine KEV-Schwachstelle auf einem von außen erreichbaren kritischen Server gehört häufig weit nach oben. Ein hoher EPSS-Wert bedeutet dagegen nicht automatisch, dass die Schwachstelle im eigenen Produkt ausnutzbar ist. Auch eine sehr schwere CVE auf einem abgeschalteten, nicht betroffenen System kann anders behandelt werden. Der Prozess muss die Entscheidung begründen können.
EPSS-Werte nicht als fertigen Risikoscore missverstehen
FIRST beschreibt EPSS ausdrücklich als Wahrscheinlichkeitssignal für bekannte CVEs, nicht als vollständige Risikobewertung. Der veröffentlichte Wert liegt zwischen 0 und 1 und bezieht sich auf einen Zeitraum von 30 Tagen. Ein EPSS-Wert von 0,20 bedeutet nicht, dass ein ganz bestimmter Unternehmensserver mit 20 Prozent Wahrscheinlichkeit erfolgreich kompromittiert wird. Das Modell beurteilt Ausnutzung im beobachteten Ökosystem und enthält keine Kenntnis Ihrer lokalen Schutzmaßnahmen.
Verwenden Sie den Wert zur Reihenfolge technischer Prüfungen. Dokumentieren Sie zusätzlich, ob der betroffene Dienst erreichbar, der verwundbare Codepfad aktiv und eine Gegenmaßnahme vorhanden ist. Prüfen Sie auch Änderungen im EPSS-Ranking, ohne aus einzelnen täglichen Schwankungen unüberlegte Notfallaktionen abzuleiten. Bei kritischen Systemen sind Auswirkungen und konkrete Bedrohungslage weiterhin ausschlaggebend.
Attack Paths statt isolierter Einzelbefunde bewerten
Eine mittelgroße Schwachstelle kann gefährlich werden, wenn sie an einem leicht erreichbaren System beginnt und anschließend den Zugriff auf einen sensiblen Dienst ermöglicht. Umgekehrt muss eine technische Lücke nicht den größten Schaden verursachen, wenn sie zuverlässig isoliert und der betroffene Dienst austauschbar ist. CTEM betrachtet deshalb nach Möglichkeit mehrstufige Angriffspfade und die Verbindung zwischen Assets, Identitäten, Konfiguration und Netzwerkzugang.
Erstellen Sie für ausgewählte kritische Dienste eine einfache Pfadbeschreibung. Beispiel: Externer Zugriff auf einen VPN-Dienst, Anmeldung mit kompromittierten Zugangsdaten, Zugriff auf ein administratives Segment und Änderung eines Backup-Jobs. Jeder Schritt besitzt eigene Kontrollen. Der Nutzen einer Maßnahme lässt sich daran bewerten, ob sie den gesamten Pfad wirksam unterbricht – und nicht nur einen sichtbaren Scannerbefund aus der Liste entfernt.
Vulnerability Scanning und Penetrationstests sinnvoll verzahnen
Automatisierte Scanner eignen sich für breite und wiederholbare Sichtbarkeit. Sie können jedoch Kontext falsch bewerten oder komplexe Angriffsketten nicht vollständig nachweisen. Ein Penetrationstest untersucht in vereinbartem Umfang, ob bestimmte Schwächen praktisch ausnutzbar sind. CTEM führt die Ergebnisse in einem dauerhaften Prozess zusammen: Scanner erkennen Veränderungen, Analysten priorisieren, Tests validieren ausgewählte Hypothesen und Betreiber schließen nachweislich die Sicherheitslücke.
Definieren Sie vor einem Test Scope, zulässige Verfahren und potenzielle Betriebsrisiken. Bei produktiven Systemen muss die Validierung so gestaltet sein, dass keine Daten beschädigt oder Services ungeplant unterbrochen werden. Ein Befund wird nicht allein deshalb als erledigt markiert, weil eine Firewallregel geändert wurde. Nach der Korrektur sollte eine angemessene unabhängige Prüfung bestätigen, dass der ursprünglich gefährliche Pfad nicht mehr besteht.
Mitigation vor Patch: Was tun, wenn ein Update nicht möglich ist?
Unternehmen können Sicherheitsupdates nicht immer sofort auf geschäftskritischen Systemen installieren. Gründe sind zertifizierte Fachanwendungen, Lieferantenfreigaben oder komplexe Abhängigkeiten. Dann sind risikomindernde Maßnahmen erforderlich: etwa die Einschränkung von Netzwerkzugriff, die Deaktivierung betroffener Funktionen, strengere Authentifizierung oder zusätzliche Überwachung. Solche Maßnahmen müssen den konkreten Angriffspfad adressieren und dürfen nicht nur allgemeine Sicherheitssymbole in einem Dashboard verbessern.
Jede Abweichung von der regulären Patchfrist benötigt eine verantwortliche Person, technische Begründung, Ablaufdatum und einen Plan zur endgültigen Korrektur. Fassen Sie Risikozusagen nicht als dauerhafte Freigabe auf. Sobald ein Hersteller einen kompatiblen Fix anbietet oder eine Umstellung möglich wird, sollte die ursprüngliche Ausnahme überprüft werden. Das Ziel ist überprüfbare Risikosenkung und langfristig die Beseitigung der Ursache.
Priorisierungsmatrix für kleine und mittlere Unternehmen
Für den Einstieg genügt ein überschaubares Schema mit wenigen Merkmalen: bestätigte aktive Ausnutzung, externe Erreichbarkeit, Geschäftsrelevanz, vorhandene Gegenmaßnahmen und technischer Behebungsaufwand. Daraus lassen sich Prioritätsklassen ableiten. Ein bekanntermaßen ausgenutzter Fehler in einem öffentlich erreichbaren administrativen System gehört in eine höhere Klasse als eine theoretische Schwachstelle in einer abgeschalteten Testumgebung.
Passen Sie die Reaktionsfristen an den eigenen Betrieb an und dokumentieren Sie genehmigte Ausnahmen. Vermeiden Sie eine einzige starre Zahl, die alle Konstellationen bestimmen soll. In der Praxis muss ein Incident-Owner bei neuen Bedrohungsinformationen eine Priorität ändern können, auch wenn der CVSS-Wert gleich bleibt. Jede Entscheidung sollte zu konkreter Maßnahme, Termin und anschließendem Prüfergebnis führen.
Kontinuierlicher Prozess: Einbindung in ITSM und Change Management
CTEM benötigt verbindliche Arbeitsabläufe. Wenn ein Exposure-Management-System ein Risiko meldet, muss es einem Asset, verantwortlichen Team und einem Ticket zugeordnet werden. Die Behebung kann ein Betriebssystemupdate, eine Konfigurationsänderung oder die Abschaltung einer Schnittstelle sein. Änderungen sollten über das reguläre Change-Verfahren erfolgen, damit Sicherheit nicht durch unkontrollierte Produktionsänderungen neue Ausfälle verursacht.
Ein Ticket gilt erst nach nachvollziehbarer Validierung als abgeschlossen. Benötigt eine Korrektur mehrere Sprints, dokumentieren Sie die temporäre Maßnahme und ihren Rest-Risikoanteil. Regelmäßige Gespräche zwischen Security, Infrastruktur und Fachbereichen verhindern, dass Risiken nur deshalb offen bleiben, weil sich kein Team für einen technischen Grenzbereich zuständig fühlt.
Kennzahlen, die tatsächliche Risikominderung zeigen
Die Gesamtzahl offener CVEs ist keine ausreichende Sicherheitskennzahl: Sie kann nach einem besseren Scan zunächst sogar steigen. Sinnvoller sind die Anzahl kritischer Internet-Expositionen, der Anteil geschlossener KEV-relevanter Befunde, die Zeit bis zur Erstbewertung sowie die Dauer bis zur bestätigten Korrektur. Ergänzen Sie den Anteil der Assets ohne Besitzer und die Zahl von Risikofreigaben, deren Frist abgelaufen ist.
Ein monatlicher Bericht sollte Unterschiede zwischen „gefunden“, „bewertet“, „technisch gemindert“ und „erfolgreich validiert“ zeigen. Diese Zustände dürfen nicht vermischt werden. Für die Geschäftsführung sind insbesondere die verbleibenden Angriffspfade zu wichtigen Geschäftsprozessen interessant. Die Visualisierung darf vereinfachen, aber nicht den technischen Nachweis ersetzen.
CTEM 2026: Ein realistischer 90-Tage-Start
Tage eins bis 30: Asset-Inventare konsolidieren und die kritischsten öffentlich erreichbaren Systeme identifizieren. Danach vorhandene Scannerergebnisse mit CISA KEV, EPSS und Geschäftsrelevanz verknüpfen. Tage 31 bis 60: priorisierte Risiken durch technische Teams überprüfen und Maßnahmen für die wichtigsten Angriffspfade umsetzen. Tage 61 bis 90: Validierung, Wiederholungsmessung und feste Schnittstellen zu Change- und Incident-Management etablieren.
Beginnen Sie lieber mit zwei oder drei wichtigen Geschäftsprozessen, etwa Fernzugriff, Microsoft-365-Administration und Datensicherung. Erst wenn die Zuordnung von Asset zu Risiko, Maßnahme und Prüfergebnis zuverlässig funktioniert, wird der Scope erweitert. Ein kleiner, wirklich gelebter CTEM-Zyklus ist wertvoller als eine teure Plattform, die lediglich neue ungeprüfte Alarmmengen produziert.
FAQ zu Continuous Threat Exposure Management
Ist CTEM identisch mit einem Schwachstellenscanner? Nein, Scanning liefert Daten, CTEM verbindet sie mit Kontext, Priorisierung und Wirksamkeitsprüfung. Was unterscheidet EPSS und KEV? EPSS schätzt zukünftige Ausnutzungswahrscheinlichkeit über einen 30-Tage-Horizont; KEV führt Schwachstellen mit bestätigter aktiver Ausnutzung nach CISA-Kriterien. Ersetzt CTEM einen Penetrationstest? Nein, kontrollierte Tests können ausgewählte Risiken validieren.
Benötigen kleine Unternehmen dafür eine teure Plattform? Nicht zwingend. Ein gepflegtes Inventar, nachvollziehbare Scanner, Threat-Informationen und disziplinierte Tickets sind ein guter Ausgangspunkt. Was ist die wichtigste Erfolgskennzahl? Die nachgewiesene Verringerung relevanter Angriffswege zu geschäftskritischen Anwendungen, nicht nur die Anzahl geschlossener Scanner-Tickets.
Fazit: Risiko reduzieren statt nur Tickets zählen
CTEM 2026 ist eine kontinuierliche Arbeitsweise, keine einmalige Produktinstallation. Asset-Inventar, Bedrohungssignale, echte Auswirkungen, verantwortliche IT-Teams und kontrollierte technische Validierung müssen zusammenspielen. Der größte Nutzen liegt in der transparenten Priorisierung tatsächlich relevanter Risiken und der regelmäßigen Überprüfung, ob Angriffsflächen nach Änderungen wirklich kleiner wurden.
Weiterführende Inhalte von GORTNET
- Active Directory Security Assessment
- Penetrationstest Ablauf und Ergebnisse
- GORTNET Cybersecurity Dienstleistungen
Für eine unabhängige Bestandsaufnahme von Schwachstellen und externen Angriffsflächen GORTNET kontaktieren.
Quellen und fachliche Grundlagen
- CISA: Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System
- FIRST: EPSS häufige Fragen
- NIST: National Vulnerability Database
Risikobewertungen sind kontextabhängig; Prioritäten und Fristen müssen für die tatsächliche Infrastruktur festgelegt werden. Der Artikel beschreibt einen defensiven Managementansatz.