Widerstand gegen Veränderungen gibt es immer, vor allem, wenn man glaubt, dass die bestehenden Prozesse effizient und effektiv sind. Viele Unternehmen denken so über ihre Verfahren zur Softwareverwaltung, bis es zu einer Sicherheitsverletzung oder einem Zwischenfall kommt und sie sich fragen müssen, was sie falsch gemacht haben.

Die Realität ist, dass die meisten Patch-Management-Programme auf Annahmen und Empfehlungen beruhen und nicht auf Fakten über aktiv ausgenutzte Schwachstellen. Risikobasiertes Patch-Management ist die Antwort auf dieses Problem.

In diesem Artikel finden Sie:

Die Probleme mit der typischen Prioritätensetzung

Aktualisierungen von Softwarefunktionen, Sicherheitskorrekturen, Fehlerbehebungen, Leistungsverbesserungen und viele andere Arten von Softwareversionen gibt es seit den Anfängen der Softwareindustrie. Die Anbieter ordnen jedem dieser Punkte einen Schweregrad oder eine andere Bewertung zu, um den Kunden mitzuteilen, was ihrer Meinung nach am wichtigsten ist.

Leider gibt es keinen Industriestandard für diese Einstufungen, so dass wir auf der Grundlage von Empfehlungen die Versionen für den Einsatz auf unseren Systemen vergleichen und priorisieren müssen. Hinzu kommt, dass solche Bewertungen nur selten aktualisiert werden, um dem aktiven Bedrohungskontext Rechnung zu tragen, selbst wenn sich die Schwachstellen ändern.

Übersehen einer aktiv ausgenutzten Sicherheitslücke

Das ist zwar besser als gar nichts, aber die Schweregrade der Sicherheitslücken werden von den Anbietern oft zu niedrig angesetzt. Nehmen wir die Sicherheitslücke Follina (CVE-2022-30190), die im Mai 2022 veröffentlicht wurde. Diese Sicherheitslücke im Microsoft Windows Support Diagnostic Tool (MSDT) ermöglicht die Ausführung von Remotecode.

Follina wurde mehrere Monate lang angegriffen, bevor Microsoft schließlich mit mehreren Updates reagierte. Erschreckenderweise stufte Microsoft diese Sicherheitslücke nur mit dem CVSS v3-Rating 7.8 und dem Schweregrad Wichtig ein. Wenn Sie nur nach dem Schweregrad „kritisch“ patchen, haben Sie diese Schwachstelle übersehen und eine große Lücke in Ihrer Angriffsfläche hinterlassen.

Schlimmer noch: Der CVSS-Wert von Follina blieb bei 7,8, selbst nachdem bekannt wurde, dass die Sicherheitslücke aktiv ausgenutzt wurde, um Bisamware Ransomware zu verbreiten, wodurch Unternehmen, die die Sicherheitslücke übersehen hatten, einem noch größeren Risiko ausgesetzt waren.

Ivanti Neurons for Vuln KB
Informationen über die Ransomware-Bedrohung im Zusammenhang mit CVE-2022-30190, angezeigt in Ivanti Neurons for VULN KB

CVSS-Mängel

Die Schweregrade werden mit CVSS-Scores von FIRST „ergänzt“. Jedem CVE wird eine CVSS-Nummer zugewiesen, wie zum Beispiel die 7.8 für CVE-2022-30190 im obigen Beispiel.

Eines der Hauptziele bei der Berechnung der CVSS-Nummer ist die Standardisierung, damit alle CVEs einheitlich bewertet werden und genau verglichen werden können. Je höher der CVSS-Score für eine Schwachstelle und den zugehörigen Patch ist, desto kritischer ist sie in den meisten Umgebungen zu implementieren.

Bei Software-Updates, die mehrere CVEs abdecken, wird normalerweise der höchste CVSS-Wert für die Priorisierung herangezogen. Aber ist dieser Wert überhaupt richtig?

Die Ergebnisse einer Analyse der CVSS-Scores in einem kürzlich erschienenen Artikel zeigen, dass es bei fast 20 % der CVSS-Scores (25.000) eine Diskrepanz gibt. Diese Analyse basierte auf einem Vergleich der in der NIST National Vulnerability Database (NVD) gemeldeten Werte mit den von den Anbietern selbst gemeldeten Werten.

Unstimmigkeiten beim Anbieter-Schweregrad

Ein wichtiger Punkt ist, dass die Hersteller in der Vergangenheit ihre eigene Terminologie für den Schweregrad verwendet haben (z. B. kritisch, wichtig). Die Einstufung des Schweregrads durch den Hersteller als Prioritätsmechanismus kann gut funktionieren, wenn alle Patches eines bestimmten Herstellers verglichen werden, bietet aber nicht immer einen genauen Vergleich von Patches verschiedener Hersteller. Viele verwenden sogar eine völlig andere Terminologie.

Ebenso ist die Schwere des Problems bei den Anbietern nicht immer ein positiver Indikator. Viele Zero-Day-Schwachstellen werden von Microsoft nur als wichtig eingestuft, haben aber hohe CVSS-Werte. Sie sehen, dass das Patchen nach Schweregrad und CVSS für die Priorisierung auf Annahmen und Empfehlungen beruht und zu einer anfälligen Umgebung führen kann.

Warum sollten aktive Exploits Vorrang vor anderen Priorisierungsmethoden haben?

Nach Angaben der US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) ist eine aktiv ausgenutzte Schwachstelle „eine Schwachstelle, für die es verlässliche Beweise gibt, dass ein Akteur ohne Erlaubnis des Systembesitzers bösartigen Code auf einem System ausgeführt hat“. Für den Laien ist eine aktiv ausgenutzte Sicherheitslücke eine Schwachstelle, die von einem Angreifer genutzt wurde, um einen Cyberangriff zu starten. Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Um das Risiko eines Angriffs auf Ihr Unternehmen zu minimieren, müssen Sie daher aktiv ausgenutzten Sicherheitslücken Vorrang vor allen anderen einräumen. Das ist eine gute Nachricht, denn die meisten Sicherheitslücken werden nicht aktiv ausgenutzt und stellen daher ein geringes bis gar kein Risiko für Ihr Unternehmen dar. Diejenigen, die ausgenutzt wurden, können Sie durch risikobasiertes Patch-Management identifizieren.

Was ist risikobasiertes Patch-Management?

Laut dem Ultimate Guide to Risk-Based Patch Management:

„Die risikobasierte Verwaltung von Patches geht über den Schweregrad des Herstellers und die grundlegenden CVSS-Scores hinaus, um die spezifischen Sicherheitslücken zu identifizieren und zu qualifizieren, die das größte Risiko für ein Unternehmen darstellen.

Als Erweiterung der risikobasierten Verwaltung von Sicherheitslücken bringt es einen realen Risikokontext in den Patch-Management-Prozess ein, indem es Updates mit bekannten Sicherheitslücken einbezieht, die für die Sicherheitslage eines Unternehmens am wichtigsten sind.“

Wie kann mein Unternehmen ein risikobasiertes Patch-Management einführen?

Für Unternehmen, die bereit sind, einen risikobasierten Ansatz für die Patch-Verwaltung zu wählen, ist der CISA Known Exploited Vulnerabilities (KEV)-Katalog ein guter Ausgangspunkt. Die CISA hat mit der Einführung der Binding Operational Directive 22-01 zusammen mit ihrem KEV-Katalog einen großen Schritt nach vorn gemacht, um die Priorisierung von Sicherheitslücken zu unterstützen. Als der Katalog ursprünglich veröffentlicht wurde, enthielt er etwa 200 aktiv ausgenutzte Sicherheitslücken. Inzwischen ist die Zahl auf fast 900 gestiegen.

Die CISA erstellt die Liste mit dem Wissen, dass die darin enthaltenen Sicherheitslücken von aktiven Bedrohungen ausgenutzt werden. Allerdings hat die Liste auch ihre Schwächen, da sie derzeit 131 Sicherheitslücken im Zusammenhang mit Ransomware nicht enthält.

Ist der CISA KEV-Katalog die einzige verfügbare Ressource für risikobasiertes Patch-Management?

Unternehmen mit einer ausgereifteren risikobasierten Patch-Verwaltung nutzen fortschrittliche Methoden zur Risikobewertung anstelle von CVSS oder zusätzlich zu CVSS. Diese Methoden weisen jeder Sicherheitslücke, die in der Umgebung eines Unternehmens identifiziert wird, eine Punktzahl zu und ermöglichen es den Unternehmen, ihren risikobasierten Ansatz über die CISA KEV hinaus zu erweitern.

Viele Anbieter im Bereich der risikobasierten Verwaltung von Sicherheitslücken haben eigene Scoring-Methoden entwickelt, die das tatsächliche Risiko einer Sicherheitslücke darstellen. Sie tun dies, indem sie dynamische Risikobewertungen liefern, die aktiv ausgenutzte Sicherheitslücken extra gewichten.

Das Vulnerability Risk Rating (VRR) von Ivanti hat Follina beispielsweise eine Punktzahl von 10 zugewiesen, eine Punktzahl, die das von dieser Sicherheitslücke ausgehende Risiko genauer darstellt als die CVSS-Punktzahl von 7,8.

Ivanti's VRR rating of Follina.
Der Unterschied zwischen den VRR- und CVSS v3-Scores und den Schweregraden für CVE-2022-30190, wie in Ivanti Neurons for VULN KB gezeigt.

Warum es der perfekte Zeitpunkt für die Einführung eines risikobasierten Patch-Managements ist.

Wenn Sie das Gefühl haben, dass Sie mit Systemaktualisierungen in Verzug geraten sind oder von neuen Systemen und Anwendungen in Ihrem Unternehmen überfordert sind, ist jetzt der perfekte Zeitpunkt, um ein risikobasiertes Patch-Management einzuführen.

Selbst wenn Sie das Gefühl haben, dass Sie über ein solides Programm auf der Grundlage von Schweregradbewertungen und CVSS-Scores verfügen, ist es an der Zeit, den Widerstand gegen Veränderungen zu beseitigen und einen neuen Prozess zu starten, bevor Ihr Unternehmen durch eine Datenverletzung aufgrund einer ausgenutzten Sicherheitslücke geschädigt wird.

Beginnen Sie mit dem CISA KEV, um Ihre Updates zu priorisieren und ein Budget für eine risikobasierte Verwaltung von Sicherheitslücken und Patches vorzusehen. Mit den richtigen Tools können Sie schnell die Systeme mit dem höchsten Risiko identifizieren, die zuerst gepatcht werden müssen, und dann die Liste abarbeiten, um sicherzustellen, dass Ihre Systeme sicher sind.

Möchten Sie den ersten Schritt tun? In diesem eBook finden Sie einen Leitfaden für die Implementierung eines modernen risikobasierten Patch-Management-Programms.