Die meisten Programme zum Schwachstellenmanagement bezeichnen sich selbst als „kontinuierlich“. Nur wenige tun dies tatsächlich. Der Unterschied ist entscheidend: Ein Programm, das zwar wöchentlich Scans durchführt, sich aber als „kontinuierlich“ bezeichnet, weckt ein trügerisches Vertrauen, da zwischen den Zyklen Sicherheitslücken bestehen bleiben, während die Führungskräfte davon ausgehen, dass der Schutz lückenlos ist.
Das kontinuierliche Schwachstellenmanagement (Continuous Vulnerability Management, CVM) ist ein fortlaufender, automatisierter Prozess zur Erkennung, Analyse, Priorisierung und Behebung von Sicherheitslücken in der gesamten IT-Infrastruktur eines Unternehmens. Im Gegensatz zu regelmäßigen Scan- und Berichtszyklen gewährleistet CVM einen Echtzeit-Überblick über den Zustand der Systeme und den Status der Sicherheitslücken, wodurch sich das Zeitfenster verringert, in dem Angreifer neu bekannt gewordene Schwachstellen ausnutzen können.
Dieser Artikel bietet einen diagnostischen Rahmen zur Beurteilung, ob Ihr bestehendes Programm dem Betriebsstandard entspricht, den der Begriff „kontinuierlich“ impliziert, und behandelt dabei die spezifischen Bedingungen, Kennzahlen und Koordinationsstrukturen, die wirklich kontinuierliche Programme von solchen unterscheiden, die lediglich häufig durchgeführt werden.
Was „kontinuierlich“ eigentlich bedeutet und warum die meisten Programme diese Voraussetzung nicht erfüllen
Die meisten Programme, die sich als „kontinuierlich“ bezeichnen, laufen nach wie vor in wöchentlichen oder monatlichen Scanzyklen. Sie führen die Priorisierung stapelweise durch, erstellen Tickets manuell und gehen davon aus, dass die Behebung erfolgreich war, ohne dies zu überprüfen. Unterdessen verändert sich die Angriffsfläche „ “ ( ) ständig: Neue Ressourcen werden in Betrieb genommen, Konfigurationen weichen vom Soll ab, und neu bekannt gewordene CVEs schaffen Sicherheitslücken, die durch wöchentliche Scan-Zyklen nicht geschlossen werden können.
Mit den periodischen Programmen „ “ können Sie Scans planen, Prioritäten für Stapel festlegen und Tickets manuell erstellen. Kontinuierliche Programme sorgen für eine Echtzeit-Überwachung des Systemzustands, lösen bei veränderten Bedingungen Priorisierungsmaßnahmen aus und überprüfen die Behebung der Probleme durch geschlossene Regelkreise.
Ein wirklich kontinuierliches Programm erfüllt alle folgenden Bedingungen:
- Neue Vermögenswerte werden innerhalb von Stunden und nicht erst nach Tagen erfasst und inventarisiert
- Neu bekannt gewordene Sicherheitslücken werden anhand des vollständigen Bestandsverzeichnisses im Rahmen eines festgelegten SLA bewertet
- Der Sanierungsstatus wird programmgesteuert überprüft und nicht einfach vorausgesetzt
Die meisten Programme erfüllen mindestens eine dieser Eigenschaften nicht, was in der Regel darauf zurückzuführen ist, wo sie auf dem Reifegradspektrum der Überwachung angesiedelt sind.
Drei Stufen der Überwachungskontinuität: periodisch, hochfrequent und in Echtzeit
Wenn Sie verstehen, wo sich Ihr Programm auf dem Spektrum der kontinuierlichen Schwachstellenüberwachung einordnet, lässt sich besser erkennen, was „kontinuierlich“ tatsächlich kostet und welche Lücken noch bestehen.
Stufe 1: Regelmäßige Überprüfung. Geplante Scans werden wöchentlich, monatlich oder vierteljährlich durchgeführt. Die Latenzzeit bei der Erkennung von Sicherheitslücken wird in Tagen bis Wochen gemessen. Zwischen den Zyklen bestehen Deckungslücken. Dieser Ansatz eignet sich für stabile Umgebungen mit geringen Veränderungen, lässt jedoch Schwachstellen außer Acht, die im Laufe des Zyklus auftreten.
Level 2: Hochfrequenz-Scannen. Tägliche oder nahezu tägliche Scan-Zyklen reduzieren die Erkennungsverzögerung auf wenige Stunden. Die Abdeckung in dynamischen Umgebungen verbessert sich zwar, doch kurzlebige Ressourcen wie Container und automatisch skalierte Cloud-Instanzen (einschließlich Workloads, die in Kubernetes-Clustern ausgeführt werden und möglicherweise innerhalb eines einzigen Scan-Intervalls gestartet und beendet werden) können weiterhin zwischen den Scan-Fenstern existieren und unentdeckt bleiben.
Level 3: – Agentenbasierte Zustandsüberwachung in Echtzeit. Persistente Agenten melden kontinuierlich den Status und die Konfiguration der Ressourcen. Die Erkennungsverzögerung sinkt auf wenige Minuten. Temporäre und wieder online gehende Ressourcen werden abgedeckt. Der Nachteil liegt im Aufwand für die Bereitstellung und Verwaltung der Agenten.
| Stufe | Erkennungsverzögerung | Vermögensdeckung | Optimale Passform |
|---|---|---|---|
| Periodisch | Tage bis Wochen | Lücken zwischen den Zyklen | Stabile Umgebungen mit geringen Veränderungen |
| Hochfrequenz | Öffnungszeiten | Es fehlen kurzlebige Vermögenswerte | Eine dynamische, aber berechenbare Infrastruktur |
| Echtzeit | Protokoll | Umfasst Offline- und kurzlebige Ressourcen | Große, verteilte oder sich rasch verändernde Umgebungen |
Die meisten Unternehmensprogramme werden auf Stufe 1 oder 2 betrieben und gehen davon aus, dass sie „kontinuierlich“ sind. Die Single-Agent-Architektur von Tanium liefert Zustandsdaten in Echtzeit, wodurch die Latenzverzögerung beseitigt wird, die bei planmäßigen Schwachstellen-Scans von „ “ auftritt. Die Frage ist nicht, welches Niveau das „beste“ ist. Es kommt darauf an, welche Stufe dem Risikoprofil und der Veränderungsgeschwindigkeit Ihrer Umgebung entspricht.
Die Überwachungsstufe bestimmt, wie schnell Sie Schwachstellen aufspüren können. Was als Nächstes geschieht, entscheidet darüber, ob es von Bedeutung ist, sie zu finden.
Wo CVM-Programme in Unternehmen scheitern: Die Koordinationslücke zwischen IT und SecOps
Eine Erkennung ohne Abhilfemaßnahmen ist lediglich kostspielige Sensibilisierung. Der größte einzelne Störfall bei der Geschäftskontinuität im Bereich CVM in Unternehmen ist kein technologisches Problem. Es handelt sich um ein Koordinationsproblem, das die Teams daran hindert, erkannte Schwachstellen in dem vom Programm geforderten Tempo zu beheben. Diese Koordinationslücke hat konkrete Folgen: Untersuchungen zeigen immer wieder, dass viele Datenpannen nicht auf unentdeckte Schwachstellen zurückzuführen sind, sondern auf bekannte Schwachstellen, die ungepatcht blieben, weil niemand für die Abstimmung zwischen den Bereichen Sicherheit und IT verantwortlich war.
Sicherheitsteams decken Schwachstellen auf. Die Behebung von Problemen hängt von IT-Betriebsteams ab, die unterschiedliche Prioritäten, unterschiedliche SLAs und unterschiedliche Änderungskontrollprozesse haben. Die Lücke zwischen „Wir haben den Fehler gefunden“ und „Wir haben ihn behoben“ ist der Bereich, in dem Risiken lauern.
Fehler bei der Integration des Ticketings. Wenn bei der Erfassung von Sicherheitslücken die manuelle Erstellung von Tickets erforderlich ist, kommt es häufig zu Verzögerungen im Umfang von mehreren Tagen. Integriertes Ticketing funktioniert anders: Aus den Befunden werden automatisch Tickets generiert, denen der Schweregrad, der Asset-Kontext sowie Anleitungen zur Behebung beigefügt sind. Manuelle Übergaben verursachen Reibungsverluste, die sich bei Tausenden von Befunden summieren.
Fehlausrichtung bei SLA. Die Sicherheitsabteilung definiert die Kritikalität anhand des CVSS-Werts oder des Risikowerts. Die IT-Abteilung legt die Priorität anhand der Verfügbarkeit von Änderungsfenstern und der Auswirkungen auf den Geschäftsbetrieb fest. Ohne einheitliche SLA-Stufen verbleiben kritische Sicherheitslücken in Warteschlangen, während sich die Teams über die Terminplanung streiten.
Eine praktische SLA-Struktur könnte wie folgt aussehen:
- Stufe 1 (kritisch, wird aktiv ausgenutzt): SLA für die Behebung innerhalb von 24 Stunden
- Stufe 2 (hoch, Sicherheitslücke ausnutzbar): 7-Tage-SLA (bei großem Umfang durch automatisierte Patches erreichbar; je nach Komplexität der Umgebung anzupassen)
- Stufe 3 (mittel/niedrig): Akzeptiertes Risiko oder geplantes Wartungsfenster
Unklarheiten hinsichtlich der Eigentumsverhältnisse. Wenn niemand durchgängig die Verantwortung für das Ergebnis der Fehlerbehebung trägt, verharren Schwachstellen in den Ticket-Warteschlangen. Ein klar definierter Behebungsprozess beantwortet drei Fragen: Wer ist für das Ticket verantwortlich? Wem gehört die Verifizierung? Wer ist für die Ausnahme verantwortlich, wenn die Behebung aufgeschoben wird?
Wie sieht also ein wirklich kontinuierliches Programm eigentlich aus? Im nächsten Abschnitt wird dies in fünf überprüfbare Bedingungen unterteilt.
Die fünf Bedingungen, die ein wirklich kontinuierliches Programm erfüllt
Betrachten Sie die folgenden Punkte bitte als Checkliste und nicht als Lebenszyklus. Jede Bedingung ist entweder erfüllt oder nicht erfüllt. Teilgutschriften führen nicht zu einer Verringerung des Risikos.
1. Vollständige Bestandsaufnahme der Vermögenswerte in Echtzeit
Das Programm führt ein Bestandsverzeichnis unter current-state-inventory.html ( ), das kurzlebige, abgelegene und offline befindliche Ressourcen erfasst. Keine CMDB, die der Realität um Tage oder Wochen hinterherhinkt.
Test: Können Sie innerhalb einer Stunde bestätigen, ob eine neu bekannt gewordene kritische CVE Auswirkungen auf eine Ressource in Ihrer Umgebung hat? Sollte die Antwort lauten: „Wir müssten zunächst einen Scan durchführen“, liegt eine Lücke in der Kontinuität vor.
2. Ereignisgesteuerte Erkennung
Neue Sicherheitslücken lösen Erkennungsabläufe unmittelbar nach ihrer Bekanntgabe aus, nicht erst beim nächsten Scan-Zeitfenster. Dies erfordert eine aktive Integration mit den Bedrohungsinformationen von „ “ sowie mit Sicherheitshinweisen von Anbietern, darunter CISA-KEV-Updates, NVD-Veröffentlichungen und anbieterspezifische Bulletins wie den „Microsoft Patch Tuesday“ und Sicherheitshinweise zu Linux-Distributionen, damit bei Bekanntwerden von Sicherheitslücken automatisch eine Bewertung der Ressourcen eingeleitet wird, anstatt auf einen geplanten Scan zu warten.
Test: Wenn eine kritische CVE veröffentlicht wird, wie lange dauert es, bis Ihr Programm alle Ressourcen daraufhin überprüft? Die Öffnungszeiten gelten durchgehend. „Days“ kommt häufig vor. „Weeks“ ist periodisch.
3. In den Arbeitsablauf integrierte kontextbezogene Priorisierung
Bei der Priorisierung werden die Kritikalität der Ressourcen, Anzeichen für Ausnutzbarkeit wie EPSS und CISA KEV sowie Bedrohungsinformationen (einschließlich neuer Bedrohungen , die möglicherweise noch keine hohen CVSS-Werte aufweisen, jedoch in der Praxis bereits aktiv ausgenutzt werden) herangezogen. Das „Exploit Prediction Scoring System“ (EPSS) schätzt die Wahrscheinlichkeit, dass eine Sicherheitslücke innerhalb von 30 Tagen in der Praxis ausgenutzt wird, und liefert damit einen zukunftsorientierten Hinweis, den der CVSS-Schweregrad allein nicht erfassen kann. Dies ist die Website von „ “ zum risikobasierten Schwachstellenmanagement, auf der die Methodik erläutert wird.
4. Korrektur mit Closed-Loop-Verifizierung
Jede Korrekturmaßnahme wird programmgesteuert überprüft. Die Sicherheitslücke wird erst dann als „behoben“ gekennzeichnet, wenn eine Nachprüfung die Behebung bestätigt hat. Der Artikel „ “ zur automatisierten Behebung von Sicherheitslücken behandelt verschiedene Implementierungsansätze.
5. Kontinuierliche Messung und Berichterstattung
Das Programm erfasst seine eigenen Leistungskennzahlen und berichtet diese in festgelegten Abständen an die Beteiligten. Nicht nur, wenn die Wirtschaftsprüfer danach fragen. Falls Sie die Frage „Wie lange dauert es im Durchschnitt, kritische Sicherheitslücken zu beheben?“ nicht beantworten können, Ohne die Erstellung eines benutzerdefinierten Berichts liefert das Programm Berichte auf Abruf und führt keine kontinuierliche Messung durch.
Die Nichterfüllung auch nur einer einzigen Bedingung führt zu einem Risiko. Ein Programm mit einwandfreier Erkennung, aber ohne Überprüfung erfasst lediglich Aktivitäten, nicht jedoch Ergebnisse.
Von den fünf Voraussetzungen ist die Überprüfung diejenige, die die meisten Teams gänzlich auslassen. Schauen wir uns einmal an, warum dies von Bedeutung ist.
Validierung: Der CVM-Schritt, den die meisten Programme überspringen
Die meisten Teams kennzeichnen Sicherheitslücken als „behoben“, sobald ein Patch bereitgestellt wird, und nicht erst, wenn bestätigt ist, dass die Sicherheitslücke geschlossen wurde. Diese Lücke zwischen „wir haben die Korrektur umgesetzt“ und „die Korrektur hat tatsächlich funktioniert“ ist die Ursache für falsches Vertrauen.
Vor der Sanierung
Bestätigung vor der Sanierung
Bevor Sie eine Sicherheitslücke zur Behebung zuweisen, vergewissern Sie sich, dass es sich bei dem vom Scanner festgestellten Befund um eine tatsächliche, ausnutzbare Sicherheitslücke handelt. Es handelt sich weder um ein falsch-positives Ergebnis noch um einen Konfigurationsfehler. Dieser Schritt deckt zudem Fehlkonfigurationen auf, die von Scannern als Schwachstellen identifiziert werden: Probleme, die möglicherweise eher eine Konfigurationsänderung als einen Patch erfordern und die falsch weitergeleitet werden, wenn die Triage vor der Behebung übersprungen wird. Wird dieser Schritt übersprungen, werden IT-Ressourcen verschwendet und das Vertrauen in das VM-Programm wird mit der Zeit untergraben.
Nachdem der Fix bereitgestellt wurde
Überprüfung nach Abschluss der Sanierungsmaßnahmen
Nachdem ein Sicherheitspatch für „ “ ( ) oder eine Konfigurationsänderung bereitgestellt wurde, überprüfen Sie programmgesteuert, ob die Sicherheitslücke tatsächlich geschlossen wurde. Ein erneuter Scan oder eine agentenbasierte Zustandsprüfung bestätigt, dass die Sicherheitslücke auf dem System nicht mehr besteht. „Das Ticket ist geschlossen“ ist keine Bestätigung.
Für hochwertige Vermögenswerte
Adversarische Validierung
Bei hochwertigen Vermögenswerten oder entscheidenden Meilensteinen bei Sanierungsmaßnahmen bieten Penetrationstests eine Ebene der Validierung durch simulierte Angreifer, die durch automatisierte Überprüfungen nicht ersetzt werden kann. Programmatische Nachprüfungen bestätigen, dass eine bestimmte Schwachstelle behoben wurde; ein gezielter Test geht noch einen Schritt weiter. Automatisierte Prüfungen bestätigen, dass ein Vorgang abgeschlossen ist. Sie können nicht bestätigen, dass die Strahlenbelastung nicht mehr besteht.
Wenn eine Sanierung nicht möglich ist
Ausnahmebehandlung
Für Sicherheitslücken, die nicht behoben werden können – wie beispielsweise bei Altsystemen oder geschäftskritischen Anwendungen mit Änderungssperren –, legen Sie ein formelles Ausnahmeverfahren fest. Halten Sie die Risikoakzeptanz, die kompensierenden Kontrollmaßnahmen, die Häufigkeit der Überprüfungen und die Ablaufdaten schriftlich fest. Ausnahmen ohne Ablaufdatum führen zu einer dauerhaften Gefährdung.
Ein CVM-Programm, das die Wirksamkeit von Abhilfemaßnahmen nicht nachweisen kann, misst lediglich die Auslastung und nicht die Sicherheit.
Die Überprüfung gibt Aufschluss darüber, ob einzelne Korrekturen erfolgreich waren. Kennzahlen geben Aufschluss darüber, ob das Programm selbst funktioniert. So können Sie den Unterschied erkennen.
So können Sie feststellen, ob Ihr CVM-Programm funktioniert
Nur anhand von Kennzahlen lässt sich ein Programm, das wirklich kontinuierlich ist, von einem unterscheiden, das lediglich häufig stattfindet. Verfolgen Sie die folgenden Punkte, berichten Sie regelmäßig darüber und nutzen Sie sie, um Verbesserungen voranzutreiben. Zusammengenommen vermitteln diese Indikatoren der Unternehmensleitung einen messbaren Überblick über die Sicherheitslage der Organisation: nicht nur eine Momentaufnahme offener Tickets, sondern eine Trendlinie, die aufzeigt, ob das Programm das Cyberrisiko im Laufe der Zeit tatsächlich verringert.
| Metrisch | Was damit gemessen wird | Gesunder Richtwert |
|---|---|---|
| Prozentuale Scanabdeckung | Anteil der bekannten Vermögenswerte, die aktiv überwacht werden | Nahezu 100 %, mit dokumentierten Ausnahmen |
| Stunden zwischen der Veröffentlichung der CVE und der Bestätigung der Auswirkungen | Stunden für kritische CVEs, nicht Tage | |
| Durchschnittliche Zeit bis zur Fehlerbehebung (MTTR) | Zeit von der Erkennung bis zum bestätigten Abschluss, nach Schweregrad | Innerhalb festgelegter SLA-Stufen |
| Falsch-positiv-Rate | Prozentualer Anteil der Befunde, die nicht verwertbar sind | Im Laufe der Zeit abnehmend |
| Ausfallquote | Prozentualer Anteil der Feststellungen, bei denen das Risiko akzeptiert wurde, im Vergleich zu den behobenen Mängeln | Stabil oder rückläufig – alles dokumentiert |
| Validierungsrate der Sanierungsmaßnahmen | Prozentualer Anteil der programmatisch überprüften „gebehebten“ Feststellungen | Nahezu 100 % bei „kritisch/hoch“ |
Die Schwachstellenalterung ist eine optionale siebte Kennzahl: Wie lange bleiben Schwachstellen im Laufe der Zeit in der gesamten Umgebung unbehoben? Eine ausgewogene Verteilung tendiert zu einem raschen Abschluss, wobei für jede Schweregradstufe ein festgelegtes maximal zulässiges Alter und klare Vorgaben für die Fristen zur Behebung vorliegen.
Wenn die Unternehmensleitung Daten zur Anfälligkeit erst dann einsehen kann, wenn die Compliance-Abteilung dies verlangt, dient das Programm lediglich der Berichterstattung auf Anfrage und dient weder der kontinuierlichen Messung noch dem proaktiven Risikomanagement.
Anhand von Kennzahlen lässt sich feststellen, ob das Programm funktioniert. Sie berücksichtigen nicht die betrieblichen Gegebenheiten, die die Umsetzung erschweren. Wie ein Programm diese Anforderungen erfüllt, ändert sich, wenn die Umgebung selbst komplex und verteilt ist.
CVM in komplexen und regulierten Umfeldern
Komplexe Umgebungen befreien ein Programm nicht von den zuvor definierten Kontinuitätsbedingungen. Sie führen zu betrieblichen Einschränkungen, denen das Programm Rechnung trägt.
- Verteilte und Offline-Endpunkte: Remote-Agenten können unter Umständen nur zeitweise verbunden sein. Kontinuierliche Programme bewältigen dies durch die Synchronisierung des Systemzustands bei der Wiederherstellung der Verbindung, durch in einer Warteschlange gespeicherte Korrekturmaßnahmen sowie durch die Überwachung von Abdeckungslücken bei Assets, die über einen festgelegten Schwellenwert hinaus offline sind.
- OT/IT-konvergierte Endgeräte: Scans können den Betrieb von OT-Systemen stören. Kontinuierliche Programme passen sich durch passive Überwachung, agentenlose oder schreibgeschützte Agentenmodi – sofern die OT-Umgebung dies zulässt –, separate Erkennungs- und Behebungsabläufe für OT-Ressourcen sowie explizite Ausschlussrichtlinien mit Ausgleichskontrollen an.
- Regulierte Branchen (NIST, PCI DSS, HIPAA): CVM erstellt auditfähige Nachweise, die auf Compliance-Rahmenwerke abgestimmt sind. Dies geschieht durch kontinuierliche Nachweiserfassung, automatisierte Zuordnung von Befunden zu Kontrollanforderungen sowie ein dokumentiertes Ausnahmemanagement unter Berücksichtigung des regulatorischen Kontexts.
Der Kontinuitätsstandard bleibt unverändert. Die Implementierung passt sich an.
Nachdem die Komplexität der Umgebung nun berücksichtigt wurde, stellt sich abschließend die Frage, wie sich CVM in alle anderen Komponenten Ihres Sicherheits- und IT-Stacks einbinden lässt.
Einbindung von CVM in Ihre bestehenden Sicherheits- und IT-Arbeitsabläufe
Ein fortlaufendes Programm lässt sich in Ihre bestehenden Sicherheits- und IT-Tools integrieren, anstatt diese zu ersetzen. Sein Wert hängt von der Qualität der Integration ab.
- SIEM/SOAR: Die Ergebnisse der Schwachstellenanalyse fließen in die Arbeitsabläufe des Sicherheitsbetriebs ein – durch automatisierte Warnmeldungen bei kritischen Befunden, erweiterte Kontextinformationen in SIEM-Ereignissen sowie SOAR-Playbooks, die Maßnahmen zur Fehlerbehebung und Konfiguration auslösen.
- ITSM/Ticketing: Die Abhilfemaßnahmen fließen in den Änderungsmanagementprozess der IT ein. Hier gelten die SLA- und Ticketing-Anforderungen aus dem Abschnitt „Koordinationslücke“.
- CI/CD- und DevOps-Pipelines: In Unternehmen mit kurzen Release-Zyklen werden Schwachstellenprüfungen in die Bereitstellungspipelines integriert, anstatt sie erst nach der Bereitstellung durchzuführen. In einem DevSecOps-Modell werden durch „Shift-Left“-Scans Sicherheitsbefunde bereits während der Entwicklungsphase aufgedeckt.
- Patch-Management: Ein kontinuierliches Programm ist auf einen funktionierenden Patch-Management-Workflow angewiesen, um Feststellungen in behobene Sicherheitslücken umzusetzen. Die Installation von Betriebssystem-Patches deckt den größten Teil der IT-Infrastruktur ab; die Installation von Anwendungs-Patches betrifft Software von Drittanbietern, Browser und Office-Suiten, auf die ein erheblicher Anteil der ausgenutzten Sicherheitslücken entfällt, die jedoch häufig aus den auf das Betriebssystem ausgerichteten Arbeitsabläufen ausgeschlossen werden. Ohne strukturierte Patching-Prozesse für „ “ , die beide Ebenen abdecken, sammeln sich Erkennungsdaten an, ohne dass Abhilfemaßnahmen ergriffen werden.
- Endpunktmanagement: Die CVM-Plattform tauscht Daten mit der Infrastruktur des Endpunktmanagements aus oder nutzt dieselbe Agenteninfrastruktur. Dadurch entfallen separate Scan-Agenten, und die Behebung von Schwachstellen kann über dieselbe Konsole erfolgen, die die Schwachstelle erkannt hat.
Wie Tanium das kontinuierliche Schwachstellenmanagement unterstützt
Alles oben Genannte beschreibt, welche Voraussetzungen ein kontinuierliches Programm erfüllen muss. Gerade in der Zeitspanne zwischen der Erkennung einer Sicherheitslücke und der Bestätigung ihrer Behebung verlieren die meisten Programme an Kontinuität – und genau hier entscheidet die Plattformarchitektur darüber, ob das Programm tatsächlich die erwarteten Ergebnisse liefert.
Diagnosetools decken das Problem auf. Die Behebung hängt von einem anderen Team, einem anderen Werkzeug und einer anderen Prioritätenliste ab. Diese Weitergabe, die sich bei Tausenden von Befunden wiederholt, ist es, die ein „kontinuierliches“ Programm in ein periodisches verwandelt.
Die „ “ Tanium Autonomous IT Platform schließt diese Lücke, indem sie Erkennung, Priorisierung, Behebung und Überprüfung auf der Grundlage eines einzigen Datensatzes vereint. Sicherheits- und IT-Teams arbeiten auf der Grundlage derselben Endpunktdaten in Echtzeit, wodurch die Verzögerung zwischen „Wir haben es entdeckt“ und „Wir haben es behoben“ entfällt. Sobald eine kritische CVE bekannt wird, ist Tanium so konzipiert, dass es den Teams nahezu sofortige Transparenz hinsichtlich der Behebung ( ) und der Abhilfe (Remediation) über die gesamte Umgebung hinweg bietet, um ihnen zu ermöglichen, direkt von der Identifizierung zur Behebung überzugehen.
In der Praxis spiegelt sich dies über den gesamten Lebenszyklus des CVM wider:
- Echtzeit-Bestandsübersicht ersetzt veraltete Scan-Daten: Tanium ruft den aktuellen Status direkt von den Endgeräten ab und erfasst dabei sowohl verwaltete als auch nicht verwaltete Geräte sowie solche, die nach einer Offline-Phase wieder eine Verbindung herstellen. Das bedeutet, dass der Bestandsverzeichnis den aktuellen Stand widerspiegelt und nicht den Stand zum Zeitpunkt des letzten Erfassungszeitraums.
- Die Behebung erfolgt dort, wo die Erkennung stattfindet: Die Ergebnisse fließen direkt in die Patching- und Konfigurationsabläufe innerhalb derselben Plattform ein. Keine manuelle Erstellung von Tickets, keine Verzögerungen bei der Weiterleitung, keine Unklarheiten hinsichtlich der Zuständigkeit zwischen Sicherheitsabteilung und IT.
- Die Closed-Loop-Verifizierung bestätigt nicht nur die Bereitstellung, sondern auch die Behebung von Problemen: Tanium überprüft die Behebung programmgesteuert, ohne einen erneuten Scan einplanen zu müssen. Agentenbasierte Zustandsdaten bestätigen, ob der Sicherheitsrisiko-Zustand weiterhin besteht; daher wird ein Sicherheitsrisiko erst dann als behoben markiert, wenn die Korrektur am Endpunkt bestätigt wurde. Nicht, wenn der Ticketverkauf endet.
Die erstmalige Bereitstellung von Agenten in einer großen Flotte erfordert Planung, insbesondere in Umgebungen mit strengen Änderungskontrollen; der damit verbundene laufende Betriebsaufwand wird jedoch dadurch ausgeglichen, dass die Wartung mehrerer Scan- und Behebungstools entfällt.
Das sind keine theoretischen Unterscheidungen. Recovery Centers of America nutzte Tanium, um 400 000 Sicherheitslücken auf seinen 2 200 Endgeräten aufzudecken – Sicherheitslücken, die zuvor unentdeckt geblieben waren. Tanium half dem Unternehmen daraufhin, diese Zahl innerhalb von etwas mehr als zwei Wochen um 80 Prozent zu senken. RCA nutzte zudem die Integration von Tanium in ServiceNow, um separate Tools zusammenzuführen und Endpunktdaten in Echtzeit in die Arbeitsabläufe für das Ticketing, das Änderungsmanagement und das Anlagenmanagement einzuspeisen. Lesen Sie die Fallstudie „“.
Die einheitliche Plattformarchitektur von Tanium behebt das strukturelle Problem, das die meisten CVM-Programme daran hindert, echte Kontinuität zu erreichen: die Lücke zwischen Erkennung und verifizierter Behebung.
Durch die Pflege von Echtzeitdaten zum Status der Endgeräte und die Möglichkeit für Sicherheits- und IT-Teams, Probleme über ein einziges System hinweg zu erkennen, zu priorisieren, zu beheben und zu überprüfen, beseitigt Tanium die Koordinationsverzögerungen und den Aufwand durch den Wechsel zwischen verschiedenen Tools, die „kontinuierliche“ Programme zu nur gelegentlich durchgeführten Maßnahmen machen. Unternehmen erlangen die operative Fähigkeit, innerhalb weniger Stunden festzustellen, ob eine neu bekannt gewordene CVE Auswirkungen auf ihre Umgebung hat, und programmgesteuert zu bestätigen, wann die Behebung abgeschlossen ist – dies sind die beiden Voraussetzungen, die kontinuierlich umgesetzte Programme von bloßen Bestrebungen unterscheiden.
Häufig gestellte Fragen zum kontinuierlichen Schwachstellenmanagement
Echte Kontinuität hängt davon ab, dass die Lücke zwischen der Erkennung und der nachgewiesenen Behebung geschlossen wird. Die folgenden Fragen befassen sich mit den häufigsten Defiziten, auf die Teams bei der Bewertung oder dem Aufbau eines CVM-Programms stoßen.
Was versteht man unter kontinuierlichem Schwachstellenmanagement?
Das kontinuierliche Schwachstellenmanagement ist ein fortlaufender, automatisierter Prozess zur Erkennung, Analyse, Priorisierung und Behebung von Sicherheitslücken in der gesamten IT-Infrastruktur eines Unternehmens, der in Echtzeit einen Überblick über den Zustand der Ressourcen und den Schwachstellenstatus gewährleistet, anstatt sich auf regelmäßige Scan-Zyklen zu verlassen.
Wie lässt sich ein kontinuierliches Schwachstellenmanagement in bestehende Sicherheitstools integrieren?
Das kontinuierliche Schwachstellenmanagement lässt sich über SIEM/SOAR-Plattformen für automatisierte Warn- und Reaktionsabläufe, ITSM-/Ticketing-Systeme zur Nachverfolgung von Korrekturmaßnahmen, Patch-Management-Plattformen für die automatisierte Bereitstellung und Überprüfung sowie eine Endpunktmanagement-Infrastruktur in bestehende Sicherheits- und IT-Tools integrieren, um redundante Agenten zu vermeiden und die Erkennung sowie Behebung von Schwachstellen auf einem einzigen Datensatz zu bündeln.
Wie fügt sich ein kontinuierliches Schwachstellenmanagement in eine Cybersicherheitsstrategie ein?
Ein kontinuierliches Schwachstellenmanagement dient als operative Ebene, die die Sicherheitsstrategie in eine messbare Risikominderung umsetzt, indem es einen Echtzeit-Überblick über die Angriffsfläche gewährleistet, Abhilfemaßnahmen auf der Grundlage der Ausnutzbarkeit und des geschäftlichen Kontexts priorisiert und eine kontinuierliche Messung von Expositionstrends ermöglicht, die als Grundlage für umfassendere Risikomanagemententscheidungen dienen.
Inwiefern verbessert ein kontinuierliches Schwachstellenmanagement die Sicherheitslage?
Ein kontinuierliches Schwachstellenmanagement verbessert die Sicherheitslage, indem es den Zeitraum zwischen der Offenlegung einer Schwachstelle und ihrer nachgewiesenen Behebung verkürzt, Lücken in der Abdeckung beseitigt, die durch regelmäßige Scans entstehen, und der Unternehmensleitung messbare Belege für die Risikominderung liefert – unter anderem anhand von Kennzahlen wie der mittleren Zeit bis zur Erkennung (Mean Time to Detection, MTTD), der mittleren Zeit bis zur Behebung ( , MTTR) sowie Trends zur Verweildauer von Schwachstellen.
Wie messen Sie den Erfolg eines kontinuierlichen Schwachstellenmanagements?
Der Erfolg wird daran gemessen, ob das Programm die Exposition im Laufe der Zeit nachweislich verringert. Die sechs zuvor in diesem Artikel behandelten Kernkennzahlen (Prozentsatz der Scan-Abdeckung, durchschnittliche Zeit bis zur Erkennung, durchschnittliche Zeit bis zur Behebung, Falsch-Positiv-Rate, Ausnahmerate und Validierungsrate der Behebung) liefern die messbaren Belege. Ein Programm ist erfolgreich, wenn die Führungskräfte eine Trendlinie erkennen können, die immer kürzere Risikofenster anzeigt, und nicht nur eine Momentaufnahme der offenen Tickets.
Kontinuierliches Schwachstellenmanagement ist keine Produktkategorie. Es handelt sich um einen betrieblichen Standard. Die Frage ist nicht, ob Ihre „ “-Tools Scans durchführen. Es geht darum, ob Ihr Programm Ihnen sofort sagen kann, welche Ressourcen gefährdet sind und ob die gestrigen Korrekturen tatsächlich gewirkt haben. Das ist der Unterschied zwischen „häufig“ und „kontinuierlich“.
Die einheitliche Plattform von Tanium bietet Sicherheits- und IT-Teams die Echtzeit-Transparenz und die geschlossene Verifizierung, die zur Erfüllung dieses Standards erforderlich sind, und beseitigt so die Koordinationslücken, die die meisten Programme daran hindern, echte Kontinuität zu erreichen. Vereinbaren Sie eine individuelle Vorführung, um zu erfahren, wie sich die Lösung in Ihrer Umgebung einsetzen lässt:.
