In vielen Lehrbüchern wirkt Schwachstellenmanagement überraschend einfach. Systeme werden regelmäßig gescannt, Schwachstellen erkannt, priorisiert und anschließend behoben. Der Prozess ist klar strukturiert und lässt sich in wenigen Schritten erklären. In der Praxis zeigt sich oftmals ein anderes Bild.
Organisationen verfügen meist über mehrere Scanner, Monitoring-Systeme oder Security-Tools, die kontinuierlich Hinweise auf mögliche Schwachstellen liefern. Technisch funktioniert die Erkennung in den meisten Fällen bereits gut. Die eigentliche Herausforderung beginnt nach dem Bericht der erkannten Schwachstellen.
Die Frage lautet selten, ob Schwachstellen gefunden werden. Die Frage lautet, was mit den Ergebnissen passiert.
Zwischen Security-Team, IT-Betrieb und Entwicklung bestehen Prozesse, die sich teilweise über Jahre hinweg etabliert haben. Jedes Team kann eigene Werkzeuge nutzen, Abläufe und Verantwortlichkeiten definieren. Genau hier beginnt die oft zeitaufwendige Arbeit im Schwachstellenmanagement.
Wenn Ergebnisse mehrere Teams betreffen
In vielen Organisationen sind mehrere Teams an der Bearbeitung von Schwachstellen beteiligt. Security-Teams führen Scans durch, der IT-Betrieb betreibt die Infrastruktur und Entwicklungsteams verantworten Anwendungen und Plattformen.
Eine erkannte Schwachstelle muss daher zunächst dem richtigen System, dem richtigen Produkt und letztlich auch dem richtigen Team zugeordnet werden. In der Praxis nimmt diese Zuordnung oftmals viel Zeit in Anspruch.
Scanner liefern technische Ergebnisse. Verantwortlichkeiten innerhalb einer Organisation sind jedoch organisatorisch gewachsen. Systeme wurden über Jahre aufgebaut, Dienste migriert oder neue Anwendungen eingeführt. Die ursprüngliche Dokumentation existiert teilweise nicht mehr oder liegt in unterschiedlichen Systemen verteilt vor.
Die Folge kann eine Reihe von Rückfragen zwischen Teams sein. Wer betreibt den betroffenen Dienst? Handelt es sich um ein internes System, eine Anwendung, die für Kunden aus dem Internet verfügbar ist oder eine Plattform eines externen Dienstleisters? Bis diese Fragen geklärt sind, vergeht oft mehr Zeit als für die eigentliche Behebung der Schwachstelle.
Doch wer weiß in der eigenen Organisation eigentlich zuverlässig, welches Team für ein betroffenes System verantwortlich ist?
Die Herausforderung der Integration
Viele Organisationen haben im Laufe der Zeit leistungsfähige Security-Tools eingeführt. Schwachstellenscanner, Container-Scanner, Dependency-Analysen oder Cloud-Security-Plattformen liefern wertvolle Ergebnisse. Die Schwierigkeit liegt selten in der Nutzung dieser Werkzeuge, sondern in deren Zusammenspiel.
Jedes Tool liefert eigene Berichte, eigene Formate und eigene Priorisierungen. Ergebnisse werden exportiert, in Ticketsysteme übertragen oder per E-Mail weitergeleitet. In manchen Fällen landen Reports als Datei in einem Projektordner oder werden manuell in eine Liste übernommen. Die eigentliche Herausforderung besteht darin, diese unterschiedlichen Quellen zusammenzuführen und den Ergebnissen organisatorischen Kontext zu geben. Ohne diese Verbindung bleiben viele Ergebnisse isolierte Informationen, deren Relevanz erst mühsam ermittelt werden muss.
Doch wie lassen sich Ergebnisse aus verschiedenen Scannern und Tools sinnvoll zusammenführen, wenn jedes System seine eigene Sicht auf Schwachstellen liefert?
Scan-Flut statt klarer Prioritäten
Mit zunehmender Automatisierung wächst auch die Menge an Ergebnissen. Moderne Scanner erkennen tausende potenzielle Schwachstellen in kurzer Zeit. Für Security-Teams entsteht dadurch eine neue Herausforderung. Die technische Erkennung funktioniert effizient, die Bearbeitung der Ergebnisse hingegen erfordert Zeit und Abstimmung.
Ein Teil der Ergebnisse betrifft Systeme, die bereits ersetzt wurden. Andere betreffen Komponenten, die von einem externen Dienstleister betrieben werden. Wieder andere sind technisch korrekt erkannt, stellen jedoch im konkreten Einsatz kaum ein Risiko dar. Ohne zusätzlichen Kontext entsteht schnell eine Situation, in der Security-Teams große Mengen an Erkennungen sichten und sortieren müssen, bevor eine sinnvolle Priorisierung möglich wird.
Doch welche Schwachstellen benötigen tatsächlich sofortige Aufmerksamkeit und welche können warten?
Fehlender Kontext zur Bewertung
Scanner liefern in der Regel technische Informationen zu einer erkannten Schwachstelle. Dazu zählen beispielsweise eine CVE-Nummer, ein CVSS-Wert oder Hinweise auf mögliche Auswirkungen. Für eine wirkungsvolle Priorisierung reichen diese Informationen jedoch selten aus. Entscheidend ist die Frage, welches System tatsächlich betroffen ist und welche Rolle dieses System in der Organisation spielt. Eine Schwachstelle auf einem isolierten Testsystem hat eine andere Bedeutung als dieselbe Schwachstelle auf einem öffentlich erreichbaren Service.
Hinzu kommt eine weitere Herausforderung: In vielen Fällen muss zunächst intern ermittelt werden, welche geschäftliche oder organisatorische Bedeutung ein betroffenes System überhaupt hat. Ohne diesen organisatorischen Kontext wird die Bewertung schwierig. Security-Teams verbringen daher viel Zeit damit, technische Ergebnisse mit Informationen aus Inventaren, Dokumentationen oder anderen Systemen abzugleichen.
Doch wie lässt sich eine Schwachstelle sinnvoll priorisieren, wenn wichtige Informationen über betroffene Systeme oder deren Bedeutung fehlen?
Wenn Ergebnisse zugeteilt werden
In manchen Organisationen entsteht im Laufe der Zeit ein pragmatischer Umgang mit dieser Situation. Ergebnisse werden exportiert, in Tabellen gesammelt, über Ticketsysteme, E-Mails oder Meetings verteilt. Listen werden ergänzt, kommentiert und in regelmäßigen Abständen aktualisiert. Informationen zu einer Schwachstelle finden sich teilweise im Ticket-System, teilweise in einer Tabelle und teilweise im E-Mail-Verlauf zwischen mehreren Beteiligten.
Mit steigender Anzahl an Systemen und Teams wird dieser Ansatz zunehmend aufwendig. Hinzu kommt die Behandlung von False-Positives. Scanner erkennen Schwachstellen auf Basis technischer Muster, die im konkreten Systemkontext nicht immer zutreffen. Wird eine Erkennung einmal als False-Positive bewertet, taucht sie bei späteren Scans häufig erneut auf. Für betroffene Teams bedeutet das eine wiederholte Bewertung derselben Erkennung. In manchen Organisationen filtert das Security-Team solche Fälle vor, um andere Teams zu entlasten. Damit verschiebt sich der zusätzliche Aufwand jedoch lediglich an eine andere Stelle im Prozess.
Doch wo lässt sich verlässlich nachvollziehen, ob eine Schwachstelle bereits bewertet, behoben oder als False-Positive eingestuft wurde, wenn Informationen über mehrere Systeme und Kommunikationskanäle verteilt sind?
Eine zentrale Koordination für das Schwachstellenmanagement mit VulnDex
Die beschriebenen Herausforderungen entstehen in vielen Organisationen unabhängig von Größe oder Branche. Mit zunehmender Anzahl an Systemen, Teams und eingesetzten Security-Werkzeugen wächst der organisatorische Aufwand rund um das Schwachstellenmanagement deutlich.
Die etablierten Prozesse und Werkzeuge haben in vielen Organisationen lange gut funktioniert und sich im Alltag bewährt. In manchen Umgebungen funktioniert dieses Vorgehen auch heute noch zufriedenstellend. Mit zunehmender Anzahl an Systemen, Teams und Sicherheitswerkzeugen steigt jedoch der Aufwand für Abstimmung, Priorisierung und Nachverfolgung von Schwachstellen merklich an. Aus genau diesen praktischen Erfahrungen heraus entstand die Idee für VulnDex.
Ziel ist es, insbesondere Security-Teams und in weiterer Folge die gesamte Organisation dabei zu unterstützen, Ergebnisse aus unterschiedlichen Quellen zusammenzuführen, organisatorischen Kontext sichtbar zu machen und eine klare Zuordnung zu Systemen, Produkten und verantwortlichen Teams zu ermöglichen.
Die Koordination und Zusammenführung von Scanner-Ergebnissen bildet einen wichtigen Teil der Plattform. Darüber hinaus liefert VulnDex weitere Hinweise auf Schwachstellen, etwa durch CVE-Watchlists, die Beobachtung eingesetzter Software über Beacons, die Auswertung von Software Bills of Materials (SBOM), die Analyse extern erreichbarer Systeme sowie durch ergänzende Vulnerability Intelligence.
Gerade im Kontext aktueller regulatorischer Anforderungen gewinnt eine strukturierte Sicht auf eingesetzte Software zunehmend an Bedeutung. Die Verwaltung und Auswertung von SBOMs unterstützt beispielsweise Anforderungen aus dem Cyber Resilience Act, während eine nachvollziehbare Nachverfolgung von Schwachstellen Organisationen zusätzlich dabei hilft, Vorgaben aus NIS2 oder ISO 27001 im Schwachstellenmanagement wirkungsvoll umzusetzen.
Am Ende bleibt das Ziel jedoch unverändert: weniger Zeit mit dem Sortieren und Zuordnen von Schwachstellen verbringen und mehr Zeit für Maßnahmen, die Sicherheit tatsächlich verbessern.
