Vulnerability Management ist ein elementares Werkzeug, um die Sicherheit in einem System bzw. einer Umgebung gewährleisten zu können. Durch das Zusammentragen relevanter Informationen soll die Grundlage für Entscheidungen getroffen werden. Was sich auf den ersten Blick einfach anhört, stellt sich bei näherer Betrachtung als aufwändige und komplexe Aufgabe heraus. Dieser Beitrag beleuchtet die verschiedenen Aspekte und wie diese angegangen werden können, um ein professionelles Vulnerability Management etablieren zu können.

Um Vulnerability Management betreiben zu können, müssen in einem ersten Schritt Informationen zu Schwachstellen (engl. vulnerabilities) gesammelt werden. In den 1990er Jahren waren Security-Mailinglisten, Researcher und Hersteller haben dort ihre Erkenntnisse veröffentlich, die Hauptquelle hierfür. Diese gelten aber seit Jahren als archaisch und sind über die Zeit hinweg buchstäblich ausgetrocknet. Durch die zunehmende Professionalisierung von Cybersecurity orientierte man sich fortan an den offiziellen Advisories, die durch die Hersteller betroffener Produkte herausgegeben wurden.

Sammeln von Sicherheitslücken

Das Zusammentragen von Informationen zu Schwachstellen ist enorm aufwändig, da es nicht unüblich ist, dass in einer Umgebung mehrere Hundert oder gar Tausend verschiedene Produkte zum Einsatz kommen. Mit der Einführung des CVE-Programms wurde eine Standardisierung und Zentralisierung erreicht. Ursprünglich ausschliesslich durch MITRE bewirtschaftet, werden dort veröffentlichte Schwachstellen mit eindeutigen Identifikatoren, den sogenannten CVEs, versehen. Seit einigen Jahren nehmen verschiedene CVE Numbering Authorities (CNA) am Projekt teil, die im Rahmen ihres Scopes ebenfalls CVEs zuweisen können. In erster Linie handelt es sich dabei um die Hersteller selbst, die entsprechende Hoheit über ihre Produkte haben. Es gibt aber auch herstellerunabhängige CNA, wie zum Beispiel CISA ICS-CERT und VulDB, die CVEs an verschiedenen Produkttypen zuweisen können.

Die Anzahl der veröffentlichten Schwachstellen hat in den vergangenen Jahrzehnten stetig zugenommen. Wurden im Jahr 2020 noch knapp über 18’000 Schwachstellen katalogisiert, kündigt sich die Prognose für das Jahr 2025 bei rund 48’000 Schwachstellen an. Das ist mehr als eine Verdoppelung in 5 Jahren. Die Gründe hierfür sind vielfältig: Einerseits schreitet die Technologisierung voran, die ein Mehr an Komplexität und Angriffsfläche mitbringt. Andererseits werden Schwachstellen konsequenter gesucht und dokumentiert. Die Aufgabe des Vulnerability Managements wird dadurch aber definitiv nicht einfacher.

Viele Nutzer pflegen den CVE-Stream zu heranzuziehen, um über aktuelle Schwachstellen auf dem Laufenden zu bleiben. Damit wird ein solides Grundgerüst gewährleistet. Die durch NIST betriebene NVD (National Vulnerability Database) übernimmt die Daten von CVE und reichert diese mit zusätzlichen Attributen an. In erster Linie sind ihre CPE-Definitionen (Zuweisung betroffener Produkte) und CVSS-Einschätzungen (Berechnung des Risikos) sehr geschätzt. Doch NVD kommt mit dem erhöhten Aufkommen neuer Einträge seit Jahren nicht mehr zurecht. Aus diesem Grund wird die Bearbeitung teilweise erst Jahre später oder gar nicht mehr vorgenommen. Dass auch das CVE-Programm immer wieder durch Budgetprobleme eingeschränkt wird, führt zu einem fragilen, trägen und unzuverlässigen Konstrukt.

Die schiere Menge der täglich gemeldeten Schwachstellen macht es unumgänglich, mit einem professionellen Partner zusammenzuarbeiten. Es gibt Anbieter wie VulDB, die Daten verschiedener Quellen aggregieren und bei jeder Veröffentlichung die unmittelbare Verfügbarkeit dieser Daten gewährleisten. Ebenso werden darin Schwachstellen dokumentiert, die keine CVE erhalten, da sie durch die gegebenen CNA Operational Rules von MITRE ausgeschlossen werden. Durch diese zusätzliche Abdeckung und die zeitnahe Anreicherung mit weiteren Informationen kann sehr unkompliziert auf relevanten Daten zugegriffen werden. Der Zugriff kann dabei wahlweise über das Webfrontend oder zwecks Automatisierung über die API stattfinden.

Zentralisiertes Vulnerability Management

Bei grösseren Unternehmen ist in der Regel ein dediziertes Vulnerability Management Team für die Beobachtung von Schwachstellen verantwortlich. In kleineren Unternehmen kann dies direkt durch einzelne Abteilungen oder Administratoren gemacht werden. Verschiedene Quellen werden dabei auf Schwachstellen beobachtet, die für das Unternehmen relevant sein können. Naheliegende Beispiele sind:

• Herstellerseiten
• Mailinglisten
• Verwundbarkeitsdatenbanken
• News-Seiten
• Soziale Netze

Das manuelle Beobachten und Analysieren der Quellen über einen Webbrowser ist einfach und komfortabel. Es ist aber nicht skalierbar und wird deshalb in professionellen Umgebungen nur bei dedizierten Recherchen bevorzugt. Stattdessen werden die Daten automatisiert über eine API aggregiert. Dies kann zum Beispiel in Splunk oder einem Ticketing-System geschehen. Von dort aus findet dann die Weiterverarbeitung der lokalen Daten statt. Dies kann sowohl automatisiert (z.B. Filtern und Priorisieren) oder manuell erfolgen (z.B. Zuweisung an Teams).

Ermitteln betroffener Produkte

Die Daten müssen in einem frühen Schritt auf der Basis eines Software-Inventars des Unternehmens auf betroffene Produkte gefiltert werden. Schwachstellen, die für eine Organisation relevant sind, werden in einem nächsten Schritt den jeweiligen Produkt-Teams zugewiesen und durch diese abgearbeitet. Dies können Teams für Produkte (z.B. Windows), Hersteller (z.B. Microsoft) oder Produkttypen (z.B. Betriebssysteme) sein.

Um zu wissen, welche Schwachstellen das Unternehmen überhaupt betreffen könnten, muss ein möglichst exaktes Filtern nach Produkten stattfinden können. Diese Herausforderung beginnt mit dem Vorhandensein einer aktuellen Produkteliste. Dies ist eigentlich eine simple Aufgabe, die sich aber als erstaunlich komplex erweist. Mit höchster Disziplin müssen sämtliche Produkte im Unternehmen während der sogenannten Asset Discovery identifiziert und dann dokumentiert werden. Im Idealfall wird die aktuelle Versionierung oder gar der Patchstand festgehalten. Sobald dieser geändert wird (z.B. durch Updates), müsste die Liste nachgeführt werden. Nur die wenigsten Unternehmen weisen diesbezüglich einen hohen Maturitätsgrad auf. Gezeigt ist ein Beispiel der verschiedenen Generationen von Windows-Clients.

Oftmals wird die Notwendigkeit des Erstellens und peniblen Nachführens einer solchen Liste nicht verstanden und die erforderliche Dokumentation vernachlässigt. Es gibt zwar Software-Lösungen, die durch Automatisierung eine Inventarisierung vereinfachen sollen. Die Schwierigkeit der Installation und des Betriebs solcher Produkte darf aber nicht unterschätzt werden. Nachweislich bleibt ein aktuelles Software-Inventar eine elementare Grundlage für professionelles Vulnerability Management.

Das Assoziieren von Schwachstellen mit Produkten erfolgt im Idealfall vollautomatisch. Hierzu wurde CPE (Common Platform Enumeration) eingeführt, das eine systematische und automatische Identifikation von Produkten zulässt. Das Nachführen des zugrundeliegenden Dictionaries ist sehr aufwändig, weshalb NIST die neu erforderlichen Einträge oft träge oder gar nicht zur Verfügung stellt. Zudem treten weitere Herausforderungen auf, wie unterschiedliche Schreibweisen, das Umbenennen von Produkten oder Anpassungen bei Firmenübernahmen. Die Einfachheit und Nützlichkeit von CPE funktioniert auf dem Papier hervorragend, wird aber in Bezug auf die Nutzung in der Realität stark überschätzt.

Risikobeurteilung

Erfahrene Vulnerability Management Teams führen eine erste Risikobeurteilung der gesammelten Schwachstellen durch, bevor diese an den jeweiligen Produkte-Teams zugewiesen werden. Es kann aber auch sein, dass die Risikobeurteilung den Produkte-Teams überlassen wird. Es ist jedoch nicht empfohlen, dass diese ausschliesslich eine solche Risikobewertung vornehmen. Denn gerne wird die Einfachheit im Betrieb bevorzugt und deshalb Schwachstellen geringer bewertet, als dass es nötig wäre.

Es gibt verschiedene Metriken, wie das Risiko oder der Schweregrad einer Schwachstelle bestimmt werden kann. Klassischerweise kommt CVSS (Common Vulnerability Scoring System) zum Tragen, das sich als Industriestandard etabliert hat. Durch diesen wird ein Wert von 0.0 bis 10.0 generiert, wobei ein hoher Wert einen hohen Schweregrad ausweist. Als Grundlage für die Berechnung wird ein Vektor genommen, der die Attribute einer Schwachstelle zusammenfasst. Dazu gehören Voraussetzungen und Auswirkungen einer erfolgreichen Attacke. Mit dem Base Vector wird der grundlegende Schweregrad der Schwachstelle berechnet, der sich über die Zeit nicht ändert. Beim erweiterten Temp Vector werden Aspekte berücksichtigt, die sich über Zeit ändern können. Wie zum Beispiel die Verfügbarkeit eines Exploits oder das Vorhandensein einer Gegenmassnahme.

CVSS steht mittlerweile als Version 4 zur Verfügung, die einige grundlegende terminologische, strukturelle und mathematische Anpassungen eingeführt hat und als umstritten gilt. Obwohl CVSS sehr hilfreich ist, wird die Fähigkeit zur Standardisierung überschätzt. Unterschiedliche Interpretationen können zu verschiedenen Vektoren und damit zu unterschiedlichen Scores führen. VulDB führt unter anderem genau deswegen die CVSS-Daten verschiedener Quellen auf. Zudem wird ein Meta-Score berechnet, der eine Harmonisierung der verschiedenen Quellen ermöglicht.

Zusätzlich werden ermittelte und berechnete Exploit-Preise ausgewiesen. Dies hilft zu erkennen, wie grosses Interesse böswillige Akteure am Ausnutzen einer spezifischen Schwachstelle haben. In diesen Berechnungen werden neue Erkenntnisse bedeutend schneller zur Verfügung gestellt, als mit CVSS.

Das Mitberücksichtigen des Known Exploited Vulnerabilities Catalog (KEV), der durch CISA bewirtschaftet wird, hilft schnell zu identifizieren, für welche Schwachstellen ein zielgerichtetes oder breitflächiges Exploiting bekannt geworden ist. Diese Schwachstellen müssen mit einem Mehr an Aufmerksamkeit bearbeitet werden, da das Risiko einer konkreten Kompromittierung nachgewiesen ist und jederzeit eintreten kann.

Bearbeiten der Schwachstellen

Die Produkteverantwortlichen sollen dann in einem nächsten Schritt die Schwachstelle bearbeiten. Hierbei haben sich typische Remediation-Timelines etabliert, die sich je nach Branche unterscheiden können:

Eine aufgenommene Schwachstelle kann verschiedene Zustände haben, die jeweils nachzuführen sind:

Das Resultat dieser Bearbeitung wird in der Regel an das Vulnerability Management Team zurückgemeldet. Dieses führt dann eine formale oder gar technische Kontrolle (z.B. Security Audit oder Penetration Test) durch, um die korrekte Abarbeitung als solche dokumentieren zu können.

Dabei ist wichtig sämtliche Entscheidungen und Schritte zu dokumentieren. Dies bedeutet, dass auch Meldungen dokumentiert werden müssen, die als Not Applicable klassifiziert oder vor einer Meldung im Rahmen des regulären Vulnerability Management-Prozesses als Fixed zurückgelassen werden konnten. Dies hat zwei Gründe: Einerseits wird durch einen solchen Audit Trail die Nachvollziehbark gewährleistet. Missverständnisse oder Irrtümer können so nachträglich nachvollzogen werden. Andererseits hilt eine lückenlose Dokumentation dabei, die mehrfache Bearbeitung der gleichen Schwachstellen zu verhindern.

Fazit

Ohne Vulnerability Management kann kein System sicher betrieben werden. Durch das Zusammentragen von Schwachstellen, dem Abgleichen mit dem eigenen Software-Inventar und einer Priorisierung kann die Sicherheit einer Umgebung massgeblich verbessert werden. Je nach Grösse eines Unternehmens ist es unablässig, ein eigenständiges Vulnerability Management Team zu etablieren, das diese Aufgabe zentralisiert und professionalisiert. Die stete Zunahme veröffentlichter Schwachstellen führt dazu, dass auch kleinere Unternehmen diesen Weg beschreiten müssen, um das weitreichende und komplexe Datenaufkommen in den Griff zu kriegen. Die Wahl des richtigen Partners, der bei dieser Aufgabe unterstützen kann, ist unerlässlich.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://cyberscoop.com/cve-program-funding-crisis-nvd-cisa-alternatives/
• https://nvd.nist.gov/products/cpe
• https://nvd.nist.gov/vuln/search/
• https://open.spotify.com/episode/4vf75rbipOpNEq9Pkv3968?si=ZVyCAvXQRhKPb1J-sIZDFg
• https://vuldb.com/?kb.api
• https://vuldb.com/de/
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.cisa.gov/topics/industrial-control-systems
• https://www.cve.org/
• https://www.cve.org/resourcessupport/allresources/cnarules
• https://www.first.org/cvss/
• https://www.scip.ch/?labs.20161013
• https://www.scip.ch/?labs.20240314