Die Behebung von Sicherheitslücken gehört zu den Bereichen der Cybersicherheit, die den größten operativen Aufwand erfordern. Das Aufspüren von Schwachstellen ist jedoch selten der Punkt, an dem Programme Schwierigkeiten haben. Für viele Organisationen besteht die eigentliche Herausforderung darin, Abhilfemaßnahmen konsequent umzusetzen und innerhalb enger Zeitvorgaben zu überprüfen, ob diese wirksam sind.
Dieser Artikel konzentriert sich auf die Umsetzungsmechanismen: die Umwandlung einer nach Prioritäten geordneten Liste in einen Bereitstellungsplan, die Entscheidung, wann eine Behebung und wann eine Risikominderung vorzunehmen ist, die sichere Steuerung der Automatisierung, die teamübergreifende Koordination sowie die Überprüfung, ob die Korrekturen die Sicherheitslücke geschlossen haben. Das Verständnis des gesamten Prozesses zur Behebung von Schwachstellen – und nicht nur einzelner Schritte – ist das, was Programme, die Risiken konsequent reduzieren, von solchen unterscheidet, die zwar Aktivitäten generieren, jedoch keine messbaren Ergebnisse erzielen.
Was die Behebung von Sicherheitslücken konkret beinhaltet
Die verschiedenen Arten von Schwachstellen, auf die Ihr Programm stößt – darunter Softwarefehler, Fehlkonfigurationen und andere Sicherheitslücken –, erfordern jeweils unterschiedliche Maßnahmen zur Behebung. Die Behebung von Sicherheitslücken ist der Prozess, bei dem diese Sicherheitsschwächen in Systemen, Anwendungen oder Konfigurationen nach ihrer Identifizierung und Priorisierung beseitigt werden.
Es handelt sich hierbei um die Ausführungs- und Validierungsphasen des Lebenszyklus des Schwachstellenmanagement- s „ “, in denen priorisierte Befunde in Korrekturmaßnahmen und validierte Ergebnisse umgesetzt werden. Im weiteren Kontext der Cybersicherheit stellt die Behebung von Schwachstellen die entscheidende Brücke zwischen der Erkenntnis, welche Bereiche gefährdet sind, und der Risikominderung dar.
Obwohl dies theoretisch einfach ist, verlieren die meisten Programme genau an dieser Stelle an Boden.
Sanierungsmaßnahmen scheitern häufig, wenn die Arbeitsabläufe zur Identifizierung, Priorisierung und Umsetzung nicht miteinander verzahnt sind. Ihr Scanner hat eine kritische CVE-Schwachstelle aufgedeckt. Der Befund wird in einem Sicherheits-Dashboard angezeigt, während der IT-Betrieb über ein separates Ticket-System arbeitet, ohne dass eine einheitliche Übergabe zwischen den beiden Systemen stattfindet. Die Tage vergehen. Die Sicherheitslücke bleibt bestehen, und diese Verzögerung verlängert unmittelbar das Zeitfenster, in dem Angreifer sie ausnutzen können.
Die Übergabe zwischen IT und SecOps stellt eine weitere häufige Schwachstelle dar. Sicherheitsteams ermitteln und priorisieren. Der IT-Betrieb ist für die Systeme verantwortlich und führt Fehlerbehebungen durch. Ohne einen gemeinsamen Überblick sowohl über den Bereitstellungsstatus als auch über die Validierungsergebnisse werden Tickets auf beiden Seiten vorzeitig geschlossen. Ohne eine entsprechende Abstimmung können selbst Schwachstellen, deren Priorität klar festgelegt wurde, weiterhin ungeschützt bleiben.
Dann gibt es noch die Validierungslücke. Ein Patch wird bereitgestellt. Das Ticket wird geschlossen. Aber ist die Sicherheitslücke tatsächlich vom Endgerät verschwunden, oder ist sie über einen anderen Weg weiterhin erreichbar oder ausnutzbar? Viele Programme kennzeichnen Probleme erst dann als gelöst, wenn Maßnahmen ergriffen wurden, und nicht erst, nachdem überprüft wurde, ob die Korrektur das beabsichtigte Ergebnis erzielt hat.
Sobald die Schwachstellen priorisiert sind, verlagert sich der Schwerpunkt von der Entscheidung, was wichtig ist, hin zur zuverlässigen Umsetzung von Korrekturmaßnahmen in großem Maßstab.
Umwandlung einer nach Priorität geordneten Liste von Sicherheitslücken in einen Maßnahmenplan
Sie verfügen über eine nach Schweregrad geordnete Liste von Sicherheitslücken. Der nächste Schritt besteht darin, diese Liste in abgestimmte Maßnahmen umzusetzen.
Entscheidungen zur Reihenfolge
Prioritätswerte dienen als Anhaltspunkt für die Reihenfolge, legen diese jedoch nicht zwingend fest. Vor der Sequenzierung lohnt es sich zudem, Fehlalarme herauszufiltern: Scan-Ergebnisse, die nicht die tatsächliche Gefährdung in Ihrer Umgebung widerspiegeln, führen zu einer übermäßigen Auslastung Ihrer Warteschlange und lenken die Sanierungsmaßnahmen in die falsche Richtung. Ein CVSS-Wert von 9,8 auf einem isolierten Testserver hat in Ihrer Bereitstellungswarteschlange eine niedrigere Priorität als ein CVSS-Wert von 7,5 auf einem Domänencontroller.
Bei der Priorisierung werden der Schweregrad mit der Kritikalität der Ressourcen, der Exposition (z. B. internetseitig vs. intern), Signalen für aktive Ausnutzung sowie betrieblichen Einschränkungen wie Wartungsfenstern und Systemabhängigkeiten kombiniert. Im Wesentlichen handelt es sich hierbei um eine Risikobewertung auf der Ebene der Sicherheitslücken, bei der die Wahrscheinlichkeit einer Ausnutzung gegen die potenziellen geschäftlichen Auswirkungen eines erfolgreichen Angriffs abgewogen wird.
Quellen für „Threat Intelligence“ , wie beispielsweise der „Known Exploited Vulnerabilities“ (KEV)-Katalog der CISA und die Bewertungen des „Exploit Prediction Scoring System“ (EPSS), helfen dabei, festzustellen, welche Schwachstellen derzeit aktiv ausgenutzt werden. Die Ergebnisse Ihres Scanners sollten mit einer Schwachstellendatenbank, wie beispielsweise der National Vulnerability Database (NVD), abgeglichen werden, um sicherzustellen, dass die CVE-Metadaten, Schweregradbewertungen und Abhilfemaßnahmen aktuell sind und im Kontext korrekt interpretiert werden. Kritische Sicherheitslücken, die sowohl „aktiv ausgenutzt“ werden als auch „ein kritisches System betreffen“, sollten ganz oben auf Ihrer Prioritätenliste stehen.
Der KEV-Katalog der CISA legt Abhilfemaßnahmenfristen für Bundesbehörden fest, wobei viele kritische Probleme je nach Ausnutzungsrisiko innerhalb festgelegter Fristen behoben werden müssen.
Die Priorisierung allein garantiert noch keine effiziente Umsetzung. Wirksame Abhilfemaßnahmen erfordern eine Zuordnung der festgestellten Schwachstellen zu den spezifischen Patches, Konfigurationsänderungen oder Updates, die zu deren Behebung erforderlich sind. Ohne diese Verknüpfung verschwenden Teams häufig Zeit damit, CVEs in umsetzbare Korrekturmaßnahmen umzuwandeln. Plattformen, die Schwachstellendaten direkt mit Abhilfemaßnahmen verknüpfen – wie beispielsweise , das fehlende Patches identifiziert, , die mit aktiven Schwachstellen in Verbindung stehen –, können Reibungsverluste zwischen Sicherheits- und IT-Teams verringern und die Zeit bis zur Behebung verkürzen, indem sie priorisierte Risiken im selben Workflow in umsetzbare Arbeitsaufgaben umwandeln.
Sobald die Entscheidungen zur Reihenfolge getroffen sind, verlagert sich die Ausführungsplanung auf die Zuständigkeiten und die Ressourcenplanung.
Ressourcen- und Eigentumsverteilung
Klären Sie vor der Bereitstellung des ersten Patches, wer für die Umsetzung der einzelnen Prioritätsstufen verantwortlich ist. Zero-Day-Sicherheitslücken stellen die höchste Prioritätsstufe dar und erfordern in der Regel einen beschleunigten Arbeitsablauf mit verkürzten Zeitplänen. Artikel der Kategorie „Critical“ erfordern häufig eine beschleunigte Genehmigung von Änderungen im Rahmen des „ “ ( ) sowie dedizierte Ressourcen. Aufgaben mittlerer Priorität werden möglicherweise in die wöchentlichen Wartungsfenster gebündelt.
Jeder Eintrag in Ihrer Warteschlange erzeugt in der Regel ein ITSM-Ticket oder wird einem solchen zugeordnet, wobei der Umfang, die betroffenen Assets, die Frist und die Genehmigungsanforderungen bereits ausgefüllt sind. Dieses Ticket dient als zentrale Koordinationsstelle zwischen dem Sicherheitsbereich und dem IT-Betrieb. Bei Problemen mit hohem Schweregrad dient es zudem als Kommunikationsprotokoll für die Beteiligten, die Einblick in den Fortschritt der Behebung und die Zeitpläne benötigen.
Beispiel-Workflow: Ein CVSS- 9,8 -CVE-Eintrag erscheint auf der CISA-KEV-Liste unter 09 Uhr . Bei der Prioritätseinstufung wird er der Kategorie „kritisch“ zugeordnet. Es wird automatisch ein ITSM-Ticket mit der Liste der betroffenen Anlagen erstellt. Ring 1 wird auf 50 Pilot-Endgeräten bereitgestellt. Ein Validierungs-Rescan wird in festgelegten Intervallen durchgeführt, die je nach Werkzeug und Umfang häufig zwischen einigen Stunden und einem Tag liegen. Ring 2 wird in der Produktion bereitgestellt. Für den Abschluss sind Prüfungsnachweise erforderlich, die die Behebung bestätigen.
Nachdem ein Einsatzplan vorliegt, muss als Nächstes entschieden werden, welche Art von Reaktion für die jeweilige Schwachstelle geeignet ist.
Abhilfe, Milderung oder Ausnahme
Nicht jede Sicherheitslücke wird auf dieselbe Weise behandelt. Die Entscheidung hängt von der Verfügbarkeit von Korrekturen, betrieblichen Einschränkungen und der Risikotoleranz ab.
| Antworttyp | What it does | Wann sollte man es verwenden? |
|---|---|---|
| Behebung | Beseitigt die Sicherheitslücke an der Quelle | Es liegt ein Hersteller-Patch vor, der im Rahmen Ihres SLA bereitgestellt werden kann. |
| Risikominderung | Verringert die Ausnutzbarkeit, ohne die eigentliche Ursache zu beseitigen | Es ist noch kein Patch verfügbar, oder die Bereitstellung erfordert umfangreiche Tests |
| Ausnahme | Nimmt das Risiko formell in Kauf, ohne es zu beheben oder zu mindern | Entweder ist die Stilllegung des Systems geplant, oder Ausgleichsmaßnahmen reduzieren das Risiko auf ein akzeptables Maß |
Gerade bei der Wahl der richtigen Antwortart treten bei Programmen häufig Probleme auf. Vermeiden Sie es, standardmäßig auf Patches zurückzugreifen, wenn dies aufgrund betrieblicher Einschränkungen nicht praktikabel ist, und vermeiden Sie es, standardmäßig Ausnahmen zuzulassen, wenn eine Lösung verfügbar ist.
Die Behebungs n stellen, sofern durchführbar, die umfassendste Lösung dar, da sie die Schwachstelle an der Quelle beseitigen. Dazu gehören das Installieren von Patches, das Absichern von Konfigurationen oder das Ersetzen nicht mehr unterstützter Software; um dies jedoch in großem Maßstab erfolgreich umzusetzen, sind zudem Koordination, Tests und eine konsequente Vorgehensweise bei der Bereitstellung erforderlich.
en zur Schadensminderung verschaffen Zeit. Dies verringert die Ausnutzbarkeit, ohne das zugrunde liegende Problem zu beseitigen, und begrenzt den Schadensumfang, während die Teams auf einen Patch oder den Abschluss der Validierung warten. Dies macht es aus operativer Sicht nützlich, birgt jedoch Risiken, wenn es als langfristige Lösung betrachtet wird.
Ausnahmen führen zu technischer Verschuldung. Die Akzeptanz einer Schwachstelle verlagert die Verantwortung auf die Unternehmensführung: die Dokumentation der Begründung, die Aufrechterhaltung von Ausgleichskontrollen und die regelmäßige Überprüfung der Entscheidung im Laufe der Zeit. Ohne diese Disziplin neigen akzeptierte Risiken dazu, sich unbemerkt anzuhäufen.
Durchführung von Sanierungsmaßnahmen in großem Umfang
Die Bereitstellung von Korrekturen auf Tausenden von Endgeräten, ohne dass es dabei zu Ausfällen kommt, erfordert einen disziplinierten Ansatz und nicht nur die entsprechenden Tools.
Anwendung von Hersteller-Patches
Die Bereitstellung von Patches erfolgt schrittweise. Beziehen Sie den Patch, bereiten Sie ihn für die Verteilung vor und testen Sie ihn in einer Nicht-Produktionsumgebung, bevor Sie ihn flächendeckend einführen. Ein effektives Patch-Management für „ “ stellt sicher, dass dieser Prozess wiederholbar und überprüfbar ist und nicht nur reaktiv auf einzelne CVEs reagiert, sobald diese auftreten.
Die Pilotgruppe erkennt Probleme frühzeitig. Sollte ein Patch eine Anwendungsabhängigkeit beeinträchtigen, die Funktionalität stören oder zu Leistungseinbußen führen, möchten Sie dies bei 50 Endpunkten erfahren, nicht bei 5 000. Durch Pausen zwischen den Klingelzeichen können Sie Stabilitätssignale beobachten, bevor Sie fortfahren.
Nicht verbundene oder offline befindliche Endpunkte stellen eine besondere Herausforderung dar. Viele Plattformen ermöglichen es Teams, Korrekturmaßnahmen im Voraus festzulegen, doch deren Ausführung hängt weiterhin davon ab, dass der Endpunkt die Verbindung wiederherstellt und diese Anweisungen empfängt. Bis zur Wiederherstellung der Verbindung sind die ungeschützten Endpunkte weiterhin einem Risiko ausgesetzt.
Behebung von Konfigurationsfehlern
Die Behebung von Konfigurationsfehlern geht über das bloße „Ändern der Einstellung“ hinaus. Sie erkennen Abweichungen von Ihrer Basislinie, erstellen Skripte oder setzen die Korrektur über Richtlinien durch und überprüfen, ob die Änderung auch nach der anschließenden Anwendung der Richtlinien bestehen bleibt.
Zu den gängigen Zielen gehören:
- Standard-Anmeldedaten: Werkseitig voreingestellte Benutzernamen und Passwörter, die Angreifer als Erstes ausprobieren
- Unnötig offene Ports: Netzwerkzugangspunkte, die die Angriffsfläche vergrößern
- Zu großzügige Zugriffskontrollen: Einstellungen, die einen umfassenderen Zugriff gewähren, als die Benutzer benötigen
Jedes dieser Muster stellt eine häufige Sicherheitslücke dar, nach der Angreifer aktiv suchen und die sie ausnutzen; daher ist die Absicherung der Konfiguration eine der wirksamsten Abhilfemaßnahmen, die den meisten Teams zur Verfügung stehen. Konfigurationsmanagement-Tools setzen Änderungen in großem Umfang durch, doch erst die Überprüfung bestätigt, dass diese Änderungen tatsächlich umgesetzt wurden.
Aktualisierung oder Austausch von Software, deren Lebensdauer abgelaufen ist
Für Software, deren Lebenszyklus beendet ist (End-of-Life, EOL), werden keine Sicherheitspatches mehr von „ “ bereitgestellt:. Unter „Behebung“ versteht man das Upgrade auf eine unterstützte Version, den Austausch der Software oder deren vollständige Außerbetriebnahme. Dies gilt gleichermaßen für kommerzielle und Open-Source-Komponenten. In vielen Umgebungen sind Open-Source-Bibliotheken, deren Lebenszyklus abgelaufen ist (EOL), in Anwendungen eingebettet, die bei regulären Patch-Zyklen leicht übersehen werden können.
Die EOL-Sanierung ist betrieblich komplex. Die Abhängigkeitszuordnung zeigt, was bei einem Upgrade nicht mehr funktioniert. Durch Tests wird sichergestellt, dass die neue Version in Ihrer Umgebung funktioniert. Mit der Freigabe durch die Geschäftsleitung wird das Zeitfenster für die Produktionsumstellung bestätigt. Trotz ihrer Komplexität sind EOL-Schwachstellen besonders wirkungsvolle Ziele für Abhilfemaßnahmen, da sie ein anhaltendes Sicherheitsrisiko darstellen.
Einführung von Ausgleichsmaßnahmen
Wenn eine direkte Abhilfemaßnahme nicht sofort durchführbar ist, verringern Ausgleichskontrollen das Risiko in der Zwischenzeit. Dies ist besonders wichtig für Systeme, die sensible Daten speichern oder verarbeiten, da eine ungeschützte Offenlegung hier über das technische Risiko hinaus auch regulatorische und geschäftliche Konsequenzen nach sich ziehen kann. Maßnahmen wie Netzwerksegmentierung, Zugriffsbeschränkungen und eine verstärkte Überwachung tragen dazu bei, die laterale Bewegung einzudämmen, die Angriffsfläche zu verringern und die Erkennung zu verbessern, falls es zu einem Missbrauch kommt.
Auch wenn Ausgleichsmaßnahmen häufig nur vorübergehender Natur sind, können sie in manchen Fällen langfristig bestehen bleiben und erfordern eine kontinuierliche Überwachung, um angesichts sich ändernder Rahmenbedingungen ihre Wirksamkeit zu bewahren. Es ist wichtig, diese zusammen mit den Ausnahmen zu erfassen, sie regelmäßig zu überprüfen und durch dauerhafte Abhilfemaßnahmen zu ersetzen, sobald eine Lösung verfügbar ist.
Steuerung der automatisierten Fehlerbehebung
Automatisierung beschleunigt die Umsetzung. Zudem kann es Fehlkonfigurationen oder fehlgeschlagene Patches innerhalb weniger Minuten auf Tausende von Endgeräten übertragen. Die Lösung liegt nicht in einer geringeren Automatisierung. Es handelt sich um eine durch „ “ gesteuerte Automatisierung: Geschwindigkeit im Gleichgewicht mit Kontrollmechanismen, die Probleme erkennen, bevor sie den Produktionsmaßstab erreichen.
Vertrauensbewertung und Einsatztauglichkeit
Das Konfidenzbewertungs liefert datengestützte Kontextinformationen, die Teams dabei unterstützen, die Sicherheit eines Patches oder einer Konfigurationsänderung vor der Einführung zu bewerten. Anstatt Entscheidungen automatisch zu treffen, unterstützt es das Urteilsvermögen des Bedieners, indem es Signale wie frühere Erfolgsfälle bei der Bereitstellung, Stabilitätsergebnisse und Auswirkungen auf die Leistung aufzeigt.
Änderungen mit höherer Zuverlässigkeit eignen sich möglicherweise besser für eine breitere Einführung, während Änderungen mit geringerer Zuverlässigkeit in der Regel eine zusätzliche Validierung, Tests oder eine ausdrückliche Genehmigung gemäß den Richtlinien der Organisation erfordern.
Ringbasierte Bereitstellung als Risikomanagement
Ring-Bereitstellung : Die Einführung erfolgt schrittweise in immer größeren Endgerätegruppen. Ein typisches Muster: „Canary“ (5–10 Endpunkte), „Pilot“ (50–200), „Broad“ (die übrigen).
Die Pause zwischen den Klingelzeichen spielt eine Rolle. Sie achten auf Fehlerquoten bei Patches, Kompatibilitätsfehler bei Anwendungen und Anzeichen für die Stabilität der Endgeräte. Die Fehlerschwellenwerte pro Ring legen fest, wann der Vorgang angehalten oder rückgängig gemacht werden soll. Klare Eskalationskriterien legen fest, wer befugt ist, eine Bereitstellung voranzutreiben oder zu stoppen.
Die Ring-Bereitstellung ist der Mechanismus, der dazu beiträgt, die Automatisierung auf Unternehmensebene sicherer zu gestalten.
Playbook-basierte Ausführung
Playbooks definieren die Logik für automatisierte Korrekturmaßnahmen, einschließlich der Art der anzuwendenden Korrektur, des Umfangs der Zielauswahl und des Ablaufs der Bereitstellung über Endpunktgruppen hinweg.
Die Umsetzung umfasst häufig Genehmigungsschritte und schrittweise Einführungen, sodass die Teams Änderungen überprüfen und die Ergebnisse validieren können, bevor eine breitere Einführung erfolgt.
Die Umsetzung von Playbooks lässt sich zudem in bestehende Arbeitsabläufe integrieren, darunter Ticket- und Änderungsmanagementprozesse, sodass Korrekturmaßnahmen und Genehmigungen mit den bestehenden Arbeitsabläufen der Teams in Einklang stehen.
Das Koordinationsproblem zwischen IT und SecOps
Zu wissen, was behoben werden muss und wie man es behebt, ist noch keine Garantie dafür, dass das Problem tatsächlich behoben wird. Die Störung tritt in der Regel an der Schnittstelle zwischen Sicherheits- und IT-Betrieb auf.
Wo die Übergabe fehlschlägt
Sicherheitsteams identifizieren Schwachstellen und ordnen ihnen Prioritäten zu. Die IT-Betriebsteams sind für die Systeme verantwortlich und führen Fehlerbehebungen durch. Ohne einen gemeinsamen Überblick über den Fortschritt der Bereitstellung, die Validierungsergebnisse und die Verantwortlichkeiten der zuständigen Stellen können Korrekturmaßnahmen als abgeschlossen erscheinen, bevor die Fehlerbehebungen tatsächlich bestätigt wurden, wodurch Sicherheitslücken bestehen bleiben und die Prüfungsnachweise unvollständig sind.
Zu den konkreten Schwachstellen zählen:
- Die Sicherheitsabteilung schließt ein Ticket, wenn eine Korrektur als „empfohlen“ eingestuft wird: Die IT-Abteilung hat diese jedoch noch nicht implementiert.
- Die IT-Abteilung schließt ein Ticket, sobald ein Patch „bereitgestellt“ wurde: Die Sicherheitsabteilung hat noch nicht überprüft, ob die Korrektur die Sicherheitslücke geschlossen hat.
- Keine gemeinsam genutzte Warteschlange: Security arbeitet auf Basis eines Schwachstellenscanners von . Die IT arbeitet mit einem Ticketing-System im Rahmen des IT-Service-Managements (ITSM). Es gibt keine automatisierte Übersetzung zwischen diesen beiden Sprachen.
- Unstimmigkeit bezüglich des SLA: „ “ Security erwartet, dass kritische CVEs innerhalb von 48 Stunden behoben werden. Die IT-Abteilung verfügt über wöchentlich stattfindende Zeitfenster für das Änderungsmanagement.
Gerade bei der Übergabe zwischen IT und SecOps geraten viele Abhilfemaßnahmen ins Stocken – nicht, weil es den Teams an guten Absichten mangelt, sondern weil die Arbeitsabläufe nicht aufeinander abgestimmt sind.
ITSM-Integration als Koordinationsschicht
Die Integration von ITSM-Workflows spielt eine entscheidende Rolle bei der Überbrückung der Übergabelücke. Es kann so konfiguriert werden, dass bei der Erkennung von Sicherheitslücken ITSM-Tickets erstellt oder diesen zugeordnet werden, wobei Umfang, Priorität und Frist bereits ausgefüllt sind. Der Bereitstellungsstatus wird von der IT an das Sicherheitsteam zurückgemeldet.
Eine gemeinsame Transparenz ist für ausgereifte Programme unverzichtbar. Beide Teams können den aktuellen Stand der Behebung einer Sicherheitslücke in Echtzeit einsehen. Die Genehmigungsabläufe erstrecken sich über beide Teams: Wer erteilt vor der Bereitstellung die Genehmigung, wer bestätigt sie im Anschluss.
Modelle des gemeinsamen Eigentums
Leistungsstarke Programme legen die Rechenschaftspflicht ausdrücklich fest. Eine gemeinsame SLA für die Behebung von Störungen, die zwischen den SecOps- und IT-Verantwortlichen vereinbart wurde, legt die Erwartungen fest. Eskalationswege dienen der Behandlung von Terminüberschreitungen. Eine einzige zuverlässige Informationsquelle erfasst den Status der Behebung.
Kennzahlen zeigen auf, wo Engpässe bestehen. Die nach Phasen aufgeschlüsselte durchschnittliche Zeit bis zur Behebung (MTTR) (von der Erkennung bis zur Ticketerstellung vs. von der Ticketerstellung bis zur Bereitstellung vs. von der Bereitstellung bis zur Validierung) zeigt genau auf, ob Verzögerungen bei der Identifizierung oder bei der Umsetzung entstehen.
Überprüfung, ob die Korrekturmaßnahme erfolgreich war
Ein installierter Patch bedeutet nicht zwangsläufig, dass die Sicherheitslücke behoben ist. Die Validierung dient dazu, zu bestätigen, ob die Exposition tatsächlich verringert oder beseitigt wurde und nicht nur im Rahmen des Prozesses berücksichtigt wurde.
Viele Programme schließen Sicherheitslücken, nachdem Maßnahmen ergriffen wurden, und nicht erst, nachdem überprüft wurde, ob die Korrektur funktioniert hat. Diese Unterscheidung führt zu einem trügerischen Vertrauen in die Sicherheitslage und zu Lücken in den Prüfungsnachweisen.
Die Validierung erfordert in der Regel ein Schwachstellenscan unter der betroffenen Endgeräte oder die Überprüfung des Endgerätestatus nach der Bereitstellung des Patches. Vergewissern Sie sich nach dem Patchen, dass die CVE bei Scans nicht mehr auftaucht und dass die Sicherheitslücke nicht mehr vorhanden oder erreichbar ist. Überprüfen Sie bei Konfigurationsänderungen, ob die Einstellung beibehalten wurde und nicht durch eine nachfolgende Richtlinienanwendung überschrieben wurde.
In verteilten Umgebungen sollten Sie alle betroffenen Ressourcen überprüfen – nicht nur eine Stichprobe –, um sicherzustellen, dass die Korrekturmaßnahmen lückenlos durchgeführt werden. In anderen Umgebungen erfordert die Validierung zudem die Bestätigung, dass die Abhilfemaßnahme direkt auf den ursprünglichen Sicherheitsmangel abzielte und nicht lediglich eine Änderung bewirkte.
Diese Unterscheidung ist von Bedeutung: „Ergriffene Maßnahme“ bedeutet den Abschluss des Prozesses. „Tatsächliche Risikominderung“ ist das Ergebnis, auf das es im Hinblick auf Compliance, Prüfungsnachweise und die allgemeine Sicherheitslage ankommt.
Nachdem die Validierung abgeschlossen ist, stellt sich abschließend die Frage, wie Sie messen können, ob Ihr Programm funktioniert.
Bewertung des Erfolgs von Sanierungsmaßnahmen
Anhand von Kennzahlen können Sie erkennen, ob Ihre Abhilfemaßnahmen greifen und wo Sie eingreifen müssen, wenn dies nicht der Fall ist.
Durchschnittliche Zeit bis zur Behebung
Die MTTR misst die „ “-Zeit, die vom Erkennen einer Sicherheitslücke oder der Erstellung eines Tickets (je nach Programmdefinition) bis zur validierten Behebung verstrichen ist, und wird nach Schweregradstufen erfasst.
Ein steigender MTTR bei Artikeln der Kritikalitätsstufe deutet auf eine Störung an einer Stelle im Arbeitsablauf hin. Ein Vergleich der Zeit von der Erkennung bis zur Ticketerstellung, der Zeit von der Ticketerstellung bis zur Bereitstellung sowie der Zeit von der Bereitstellung bis zur Validierung zeigt, ob die Verzögerung auf die Priorisierung, die Ausführung oder die Validierung zurückzuführen ist. Die auf Programmebene erfasste MTTR verschleiert, an welcher Stelle Verzögerungen auftreten. Teilen Sie es nach Phasen auf.
Sanierungsabdeckungsquote
Die Abdeckungsrate gibt den Prozentsatz der identifizierten Schwachstellen an, die innerhalb des von Ihnen festgelegten Zeitraums behoben wurden.
Eine hohe MTTR in Verbindung mit einer hohen Erfassungsrate deutet auf eine systematische Langsamkeit hin, jedoch nicht auf ein Versagen der Triage. Eine niedrige Erfassungsquote deutet auf Probleme bei der Priorisierung oder auf Kapazitätsengpässe bei den Ressourcen hin. Erfassen Sie die Deckungsquote nach Anlageklasse. Die Tatsache, dass kritische Ressourcen eine geringere Abdeckung aufweisen als Standard-Endpunkte, deutet auf ein Problem bei der Priorisierung hin.
SLA-Einhaltungsquote
Die SLA-Einhaltung misst die Einhaltung festgelegter Fristen für die Behebung von Störungen nach Schweregradstufen. Übliche Service-Level-Ziele (SLOs) lauten wie folgt: „kritisch“ innerhalb von 24–48 Stunden, „hoch“ innerhalb von 7–14 Tagen, „mittel“ innerhalb von 30 Tagen.
Die Muster von SLA-Verstößen nach Schweregrad zeigen genau auf, in welcher Phase Ihres Ausführungsworkflows die Ressourcen nicht ausreichen oder die Steuerung unzureichend ist. Die Einhaltung der SLA ist der wichtigste Maßstab bei Compliance-Prüfungen. Regulatorische Rahmenbedingungen und interne Sicherheitsvorgaben legen häufig je nach Schweregrad spezifische Fristen für die Behebung fest. Nur dokumentierte Nachweise sowohl der Bereitstellung als auch der Validierung – und nicht lediglich der Abschluss eines Tickets – erfüllen diese Anforderungen.
Anhand der MTTR können Sie erkennen, wie langsam Sie sind. Die Erfassungsquote gibt Aufschluss darüber, wie vollständig Ihre Daten sind. Anhand der SLA-Einhaltung können Sie erkennen, in welchen Bereichen Sie Ihre Verpflichtungen nicht erfüllen. Jedes Sanierungsprogramm, das ohne alle drei Komponenten auskommt, misst lediglich die Ergebnisse und nicht den Zustand der Umsetzung. Diese Lücke vergrößert sich im Laufe der Zeit, da ständig neue Sicherheitslücken entdeckt werden.
Wie Tanium dazu beiträgt, die Behebung von Sicherheitslücken zu beschleunigen
Die in diesem Artikel beschriebenen Lücken bei der Umsetzung – darunter eine uneinheitliche Tool-Landschaft, Verzögerungen bei der Übergabe und eine eingeschränkte Validierung – sind häufig auf unzusammenhängende Arbeitsabläufe und eine unvollständige Transparenz über alle Endpunkte hinweg zurückzuführen.
Die „ “ Tanium Autonomous IT Platform unterstützt die Verknüpfung von Workflows zur Erkennung von Schwachstellen, Korrekturmaßnahmen und Validierung durch Echtzeit-Transparenz und Kontrolle der Endgeräte, wodurch die Abhängigkeit von fragmentierten Tools verringert wird.
In der Praxis zeigt sich dies anhand von Funktionen* wie beispielsweise:
- Echtzeit-Transparenz der Endgeräte in Kombination mit bedarfsorientierten Schwachstellen- und Konfigurationsanalysen: Umfasst Betriebssysteme, Anwendungen und Konfigurationen und wird durch regelmäßig aktualisierte Inhaltsbibliotheken unterstützt
- Echtzeit-Warnmeldungen zu kritischen und neu auftretenden Sicherheitslücken: Bereitgestellt über Tanium Guardian , gestützt auf die Forschungsergebnisse des Vulnerability Emergency Response Team (VERT) innerhalb der Tanium-Konsole, häufig einschließlich empfohlener Abhilfemaßnahmen und Anleitungen
- Integrierte Behebungsabläufe: Reagieren Sie auf erkannte Schwachstellen und leiten Sie Behebungsabläufe direkt auf derselben Plattform ein, um den Wechsel zwischen verschiedenen Tools zu reduzieren
- Vertrauenswerte: Nutzen Sie Kennzahlen wie Installationserfolgsraten, Stabilitätsergebnisse und Auswirkungen auf die Leistung, um fundierte Entscheidungen bezüglich der Patch-Installation zu treffen, bevor Sie diese in größerem Umfang bereitstellen.
- Schrittweise, ringbasierte Bereitstellung: Beginnt mit einer kleinen Endpunktgruppe, überprüft die Ergebnisse und skaliert die Einführung, sobald jede Phase die Erfolgskriterien erfüllt
- Playbooks für Low-Code- und No-Code-Automatisierung: nutzt Tanium Automate zur Steuerung von Endpunkt- und Korrektur-Workflows unter Aufsicht des Betreibers
- Funktionen zur Validierung nach der Bereitstellung: . Diese helfen dabei, den Patch-Status zu überprüfen und Systeme zu identifizieren, bei denen Korrekturmaßnahmen nicht wie erwartet angewendet wurden.
- Integration mit „ “, „ServiceNow“ und anderen wichtigen Workflows: Bietet IT- und Sicherheitsteams Zugriff auf einheitliche Endpunktdaten innerhalb bestehender Prozesse
- Anwendungsfälle für die Konfigurationsprüfung und das Schwachstellenmanagement: In Übereinstimmung mit gängigen Rahmenwerken wie PCI, HIPAA und SOX
- zur Transparenz bei der Behebung: Zeigt behebbare Schwachstellen, fehlende Patches und den Bereitstellungsstatus an, um Sicherheits- und Betriebsteams dabei zu unterstützen, den Fortschritt bei der Behebung zu verfolgen und die Umsetzung zu koordinieren
*Die beschriebenen Funktionen und Ergebnisse basieren auf der Tanium-Produktdokumentation, validierten Kundenfallstudien und der praktischen Anwendung. Die tatsächlichen Ergebnisse können je nach Bereitstellungsumgebung, Konfiguration und Reifegrad der Organisation variieren.
Mit Tanium lässt sich die Validierung in dieselben Arbeitsabläufe integrieren, die auch für die Umsetzung von Korrekturmaßnahmen verwendet werden. Teams können den Status von Endgeräten überprüfen, beispielsweise den Stand der Patch-Installation oder Konfigurationsänderungen, und die Sicherheitsrisiken neu bewerten, um zu beurteilen, ob die Abhilfemaßnahmen das beabsichtigte Ergebnis erzielt haben.
Dieser Wandel – weg von der bloßen Erfassung von Sanierungsmaßnahmen hin zur Bestätigung der Risikominderung – ist es, was ausgereifte Programme von reaktiven Programmen unterscheidet.
Die meisten Compliance-Tools zeigen Ihnen auf, was nicht in Ordnung ist. Nur wenige geben Ihnen Anweisungen, wie Sie damit umgehen sollen, und fast keine ermöglichen es Ihnen, direkt auf demselben Bildschirm Maßnahmen zu ergreifen. Die Transparenz bei der Behebung von Sicherheitslücken in Tanium Comply sorgt hier für Abhilfe. In den „ Tech Talks“ Nr. 121 mit dem Titel „“ erläutert Margie Sills, Risk & Compliance Domain Architect bei Tanium, wie die Funktion Schwachstellen mit umsetzbaren Patches verknüpft, die nach ihrer Wirkung auf die Risikominderung geordnet sind, und wie Teams nahtlos von der Erkennung zur Behebung übergehen können, ohne das Tool wechseln oder auf eine Übergabe warten zu müssen.
Häufig gestellte Fragen zur Behebung von Sicherheitslücken
Die Durchführung von Sanierungsmaßnahmen wirft praktische Fragen auf, die sich nicht ohne Weiteres in die Prozessdokumentation einordnen lassen. Im Folgenden finden Sie häufig gestellte Fragen, die Teams oft stellen, wenn sie die Ergebnisse der Analyse in konkrete Maßnahmen umsetzen.
Mein Schwachstellenscanner hat Hunderte von CVEs ermittelt. Wo soll ich anfangen?
Der CVSS-Wert allein reicht für die Einstufung nicht aus. Ein CVSS 7,5 auf Ihrem Domänencontroller stellt ein Ausführungsziel mit höherer Priorität dar als ein CVSS 9,0 auf einem isolierten Testsystem.
Filtern Sie Ihre Liste anhand zweier Kriterien: Status der aktiven Ausnutzung (CISA-KEV- und EPSS-Signale) und Kritikalität der Ressourcen. Elemente, die sich an der Schnittmenge zwischen „in der Praxis aktiv ausgenutzt“ und „auf einer kritischen Ressource“ befinden, bilden Ihre erste Ausführungswarteschlange.
Warum reicht der CVSS-Wert nicht aus, um zu entscheiden, welche Probleme zuerst behoben werden sollten?
CVSS misst die grundlegende Schwere und die umgebungsbedingte Schwere unter definierten Bedingungen, berücksichtigt jedoch weder eine aktive Ausnutzung noch den geschäftlichen Kontext. Die Bewertung berücksichtigt die Ausnutzbarkeit und die Auswirkungen unter für den Angreifer idealen Bedingungen, ohne dabei zu berücksichtigen, ob die Sicherheitslücke in der Praxis aktiv ausgenutzt wird oder ob das betroffene System für Ihr Unternehmen von Bedeutung ist.
Ein CVSS-Wert von 9,8 für Software, die in Ihrer Umgebung nicht ausgeführt wird, hat eine geringere Priorität als ein CVSS-Wert von 6,5 für ein System, das aktiv ausgenutzt wird und mit dem Internet verbunden ist. Eine effektive Reihenfolge der Ausführung kombiniert den CVSS-Wert mit dem EPSS-Wert (Wahrscheinlichkeit einer Ausnutzung) und der Kritikalität der Ressourcen und stützt sich nicht allein auf den Schweregrad.
Inwiefern unterscheidet sich die Sanierung von der Schadensminderung?
Bei der Behebung wird die Schwachstelle an der Quelle durch Patches oder Konfigurationskorrekturen behoben, während bei der Risikominderung die Ausnutzbarkeit vorübergehend durch Maßnahmen wie Netzwerksegmentierung oder Zugriffsbeschränkungen verringert wird, bis eine dauerhafte Lösung verfügbar ist.
Was ist ein Beispiel für die Behebung einer Sicherheitslücke?
Das Anwenden eines vom Hersteller bereitgestellten Patches zur Behebung einer bekannten CVE, die Absicherung einer falsch konfigurierten Firewall-Regel oder die Aktualisierung von Software, deren Lebenszyklus abgelaufen ist, auf eine unterstützte Version gelten allesamt als Abhilfemaßnahmen, da sie die Sicherheitslücke an der Quelle beheben und nicht lediglich das Risiko mindern.
Bei der Behebung von Sicherheitslücken geht es nicht nur darum, diese zu beseitigen, sondern auch darum, sicherzustellen, dass das Risiko tatsächlich verringert wurde. Lösungen, die Priorisierung, Umsetzung und Validierung zu einem durchgängigen „ “-Workflow verbinden , sind besser in der Lage, Sicherheitslücken zu minimieren und mit den sich ständig weiterentwickelnden Cyberbedrohungen Schritt zu halten.
Vereinbaren Sie eine Demo , um zu erfahren, wie Sie die Behebung von Sicherheitslücken in Ihrer gesamten Umgebung mit Tanium optimieren und validieren können.
