Priorisierung und Behebung von CVE-Schwachstellen

Ihr Schwachstellenscanner hat gerade 4.000 offene CVEs in Ihrer gesamten Infrastruktur gemeldet. Sie verfügen über ein dreiköpfiges Team. Zu wissen, welche Schwachstellen zuerst behoben werden müssen und wie man sie effizient behebt, macht den Unterschied zwischen einem kontrollierten Risikomanagement und einer Sicherheitslücke aus, die nur darauf wartet, ausgenutzt zu werden.

Dieser Leitfaden beschreibt, wie erfahrene IT- und Sicherheitsteams die Priorisierung und Behebung von CVEs in der Praxis angehen: auf welche Bewertungssysteme man sich verlassen kann, wie man den geschäftlichen Kontext einbezieht und wie man einen wiederholbaren Arbeitsablauf aufbaut, der unter der Flut moderner Schwachstellenmeldungen nicht zusammenbricht.

Was die Priorisierung von CVEs tatsächlich bedeutet

Ein CVE (Common Vulnerabilities and Exposures) ist eine standardisierte Kennung für eine öffentlich bekannt gegebene Sicherheitslücke. Die National Vulnerability Database (NVD) verwaltet für jede einzelne eine Bewertung anhand des Common Vulnerability Scoring System (CVSS), das den Schweregrad auf einer Skala von 0 bis 10 einstuft.

Priorisierung ist der Prozess, bei dem entschieden wird, welche CVEs Ihr Team zuerst behebt und welche Sie akzeptieren, zurückstellen oder durch kompensierende Kontrollmaßnahmen abmildern. Das klingt einfach. Das Problem ist, dass der rohe CVSS-Wert nie dafür konzipiert wurde, das spezifische Risiko Ihres Unternehmens widerzuspiegeln, und ihn als alleinige Entscheidungsgrundlage heranzuziehen, führt zu verschwendeter Arbeit.

Eine Schwachstelle mit einem CVSS-Wert von 9,8 in einer Software, die nirgendwo in Ihrer Umgebung installiert ist, ist praktisch irrelevant. Eine Schwachstelle mit einem CVSS-Wert von 5,4 in einem öffentlich zugänglichen Dienst, der Zahlungsdaten verarbeitet, ist hingegen dringend. Bei der Priorisierung geht es darum, den Schweregrad der Schwachstelle der tatsächlichen Situation zuzuordnen.

Warum CVSS-Werte allein nicht ausreichen

CVSS misst den intrinsischen Schweregrad einer Schwachstelle unter idealen Ausnutzungsbedingungen. Dabei werden folgende Aspekte nicht berücksichtigt:

• Ausnutzbarkeit in der Praxis. Ob ein funktionierender Exploit tatsächlich existiert, öffentlich verfügbar ist und von Angreifern aktiv genutzt wird.
• Exposition der Ressourcen: Ob das anfällige System mit dem Internet verbunden, isoliert oder durch eine „Air Gap“ abgeschottet ist.
• Geschäftskritikalität. Ob auf dem betroffenen System Ihr Kernprodukt läuft, regulierte Daten gespeichert sind oder es sich um einen Testrechner in einer Entwicklungsumgebung handelt.
• Bestehende Kontrollmaßnahmen. Ob kompensierende Kontrollmaßnahmen (Netzwerksegmentierung, EDR, Anwendungs-Allowlisting) die Ausnutzbarkeit bereits verringern.

Aus diesem Grund hat sich die Cybersicherheits-Community weitgehend auf risikobasierte Rahmenwerke für das Schwachstellenmanagement verlagert, die auf dem CVSS aufbauen, anstatt es zu ersetzen.

Bewertungsrahmenwerke, die den realen Kontext einbeziehen

EPSS (Exploit Prediction Scoring System)

Das vom Forum of Incident Response and Security Teams (FIRST) gepflegte Exploit Prediction Scoring System (EPSS) nutzt maschinelles Lernen, um die Wahrscheinlichkeit abzuschätzen, mit der eine CVE innerhalb der nächsten 30 Tage in der Praxis ausgenutzt wird. Die EPSS-Werte reichen von 0 bis 1 (0 % bis 100 % Wahrscheinlichkeit).

Die Kombination aus einem hohen CVSS-Schweregrad und einem hohen EPSS-Wert ist ein deutliches Signal dafür, dass eine CVE sofortige Aufmerksamkeit verdient. Ein CVSS-Wert von 7,5 mit einem EPSS-Wert von 0,94 ist weitaus dringlicher als ein CVSS-Wert von 9,1 mit einem EPSS-Wert von 0,003.

CISA KEV (Katalog bekannter ausgenutzter Schwachstellen)

Der CISA-Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities Catalog, KEV) ist eine kuratierte Liste von CVEs, bei denen die CISA bestätigt hat, dass sie in der Praxis aktiv ausgenutzt werden. Bundesbehörden sind verpflichtet, KEV-Einträge innerhalb eines festgelegten Zeitrahmens zu beheben. Für nicht-föderale Organisationen sollte die Aufnahme in die KEV-Liste unabhängig von Ihrem standardmäßigen SLA einen beschleunigten Behebungsprozess auslösen.

CIS-Benchmarks und NIST SP 800-40

Die NIST-Sonderveröffentlichung 800-40 enthält Leitlinien für das Patch-Management in Unternehmen, die risikobasierte Priorisierungskriterien umfassen. Die CIS Critical Security Controls (insbesondere Kontrolle 7, „Continuous Vulnerability Management“) empfehlen, die Behebung von Schwachstellen anhand des CVSS-Werts, der Kritikalität der Ressourcen und der Bedrohungsinformationen in dieser Reihenfolge zu priorisieren.

Aufbau eines Workflows zur CVE-Priorisierung

Ein wiederholbarer Priorisierungsprozess umfasst in der Regel folgende Schritte:

1. Erfassen Sie Ihre Assets. Was Sie nicht sehen können, können Sie auch nicht priorisieren. Ein vollständiges, aktuelles Hardware-Inventar ist die Voraussetzung für jedes Schwachstellenmanagement-Programm. Jedes nicht verwaltete Gerät ist ein blinder Fleck.

2. Führen Sie kontinuierliche Schwachstellenscans durch. Geplante Scans verpassen das Zeitfenster zwischen der Veröffentlichung einer CVE und Ihrem nächsten Scanzyklus. Kontinuierliche oder nahezu in Echtzeit durchgeführte Scans schließen diese Lücke. Eine vollständige Aufschlüsselung finden Sie in „Vulnerability Scanning: A Practitioner’s Guide“.

3. Filtern Sie zunächst nach CISA-KEV. Jede CVE auf der KEV-Liste, die Ihre Umgebung betrifft, rückt an den Anfang der Warteschlange. Keine Ausnahmen.

4. Bewerten Sie die verbleibenden CVEs anhand des kombinierten Risikos. Verwenden Sie dazu CVSS + EPSS + Kritikalität der Assets + Expositionsgrad. Manche Teams erstellen eine einfache gewichtete Bewertung in einer Tabellenkalkulation; andere nutzen eine spezielle Plattform für das Schwachstellenmanagement.

5. Weisen Sie SLA-Stufen zu. Eine gängige Struktur:

- Kritisch (CVSS 9,0+ oder in der KEV-Liste aufgeführt): Behebung innerhalb von 24–72 Stunden

- Hoch (CVSS 7,0–8,9, hoher EPSS-Wert): Behebung innerhalb von 7–14 Tagen

- Mittel (CVSS 4,0–6,9): Behebung innerhalb von 30–60 Tagen

- Niedrig (CVSS unter 4,0): Behebung im nächsten geplanten Patch-Zyklus oder Akzeptanz mit dokumentierter Begründung

6. Dokumentieren Sie Ausnahmen formell. Wenn Sie die Behebung nicht innerhalb der SLA-Frist vornehmen können, dokumentieren Sie die Ausgleichsmaßnahme, die geschäftliche Begründung und das Überprüfungsdatum. Dies ist für jedes Compliance-Rahmenwerk (SOC 2, ISO 27001, FedRAMP) unverzichtbar.

Behebung von CVEs: Patches sind eine Option, aber nicht die einzige

Behebung bedeutet, das durch eine CVE verursachte Risiko auf ein akzeptables Maß zu reduzieren. Das Installieren von Patches ist der gängigste Ansatz, doch zu den Optionen gehören:

• Anwendung des Hersteller-Patches. Dies ist der bevorzugte Weg, sofern ein Patch vorhanden ist und ohne Beeinträchtigung abhängiger Systeme bereitgestellt werden kann.
• Konfigurationsänderung. Einige CVEs sind nur unter bestimmten Konfigurationen ausnutzbar. Durch eine Absicherung der Konfiguration wird die Ausnutzbarkeit ohne Patch beseitigt.
• Ausgleichende Kontrollmaßnahmen. Netzwerksegmentierung, WAF-Regeln oder die Deaktivierung einer betroffenen Funktion können die Ausnutzbarkeit verringern, wenn kein Patch verfügbar ist oder dessen sofortige Bereitstellung nicht sicher ist.
• Akzeptanz des Risikos. Bei CVEs mit geringem Schweregrad auf nicht kritischen, isolierten Systemen ist eine formelle Risikoakzeptanz mit entsprechender Dokumentation eine legitime Option.

Abhilfemaßnahmen müssen auch Tests berücksichtigen. Die Bereitstellung eines Betriebssystem-Patches auf 3.000 Endgeräten ohne schrittweisen Rollout führt dazu, dass am Dienstagmorgen die gesamte Infrastruktur ausfällt. Ein standardmäßiger stufenweiser Einsatz: Canary-Gruppe (1–5 % der Geräteflotte), Pilotgruppe (10–15 %), flächendeckender Einsatz.

CVE-Priorisierung in Apple-Umgebungen

Apple-Geräteflotten erfordern besondere Überlegungen. Apple behebt Schwachstellen in macOS, iOS und iPadOS durch Betriebssystem-Updates und „Rapid Security Responses“ (RSR). Im Gegensatz zu Software von Drittanbietern können Sie einen CVE-Patch nicht auf eine Apple-Betriebssystemkomponente anwenden, ohne das vollständige Betriebssystem-Update oder den RSR zu installieren.

Das bedeutet, dass Ihr Patch-Rhythmus für Apple-Geräte an Ihre MDM-Bereitstellungsstrategie gebunden ist. Verzögerte Betriebssystem-Updates führen zu einem wachsenden Rückstau an ungepatchten CVEs. Der Ausgangspunkt ist ein flottenweiter Überblick über Betriebssystemversionen und installierte Softwareversionen. Wenn Sie mit den Grundlagen der Apple-Geräteverwaltung nicht auf dem neuesten Stand sind, wird sich die Lücke zwischen Bekanntgabe und Bereitstellung schneller vergrößern, als Ihr Team dies manuell nachverfolgen kann.

Apple veröffentlicht zu jedem Update Sicherheitshinweise, die Verweise auf CVE-IDs enthalten. Durch den Abgleich dieser Hinweise mit der aktuellen Verteilung der Betriebssystemversionen in Ihrem Gerätepark können Sie genau feststellen, wie weit jedes einzelne Gerät hinterherhinkt.

Wie Iru die Priorisierung und Behebung von CVEs angeht

Iru wurde speziell für Apple-Geräteflotten entwickelt, was bedeutet, dass die CVE-Sicherheitslücken unter macOS, iOS, iPadOS und tvOS in der Plattform oberste Priorität haben und nicht nur eine nachträgliche Überlegung sind.

Iru überwacht kontinuierlich die Betriebssystemversionen und die installierte Software aller Geräte in Ihrer Flotte. Wenn Apple ein Sicherheitsupdate veröffentlicht, zeigt Iru an, auf welchen Geräten anfällige Betriebssystemversionen laufen, und ordnet diese den in der Veröffentlichung behobenen CVEs zu. Sie sehen Ihre Sicherheitsrisiken konkret dargestellt: nicht nur „Update verfügbar“, sondern „X Geräte laufen mit macOS-Versionen, die von CVE-2025-XXXX betroffen sind, das auf der CISA-KEV-Liste steht“.

Die Durchsetzung von Korrekturmaßnahmen erfolgt über die Compliance-Engine von Iru. Sie können eine Mindestversion für das Betriebssystem festlegen, eine Frist für die Umsetzung setzen und eskalierende Aufforderungen an die Endnutzer konfigurieren, bevor die strenge Durchsetzung greift. Schrittweise Rollouts sind in den Bereitstellungs-Workflow integriert, sodass Sie zunächst eine Testgruppe ansprechen, die Ergebnisse validieren und dann eine flächendeckende Bereitstellung vornehmen können, ohne eigene Skripte schreiben zu müssen.

Auf der Softwareseite ermöglicht die Bibliothek mit verwalteten App-Konfigurationen von Iru, dass Sie anfällige Anwendungen von Drittanbietern in Ihrem gesamten Gerätepark aktualisieren können, ohne manuell auf Geräteebene eingreifen zu müssen. In Kombination mit den Integrationen von Iru für Gerätemanagement und Sicherheit erhalten Sie neben den Durchsetzungstools auch Informationen zum Kontext der Sicherheitslücken, sodass Sie von einer einzigen Plattform aus darauf reagieren können.

Die Wahl des richtigen Zeitplans für die Behebung von Schwachstellen in Ihrer Geräteflotte

Der richtige Rhythmus hängt von der Risikotoleranz, den Compliance-Verpflichtungen und der operativen Kapazität Ihres Unternehmens ab. Hier einige praktische Richtwerte:

• Unternehmen, die SOC 2 Typ II unterliegen, verpflichten sich in der Regel, kritische Sicherheitslücken innerhalb von 30 Tagen zu beheben, wobei viele Auditoren mittlerweile eine Frist von 14 Tagen oder weniger für KEV-gelistete CVEs erwarten.
• FedRAMP High verlangt die Behebung kritischer CVEs innerhalb von 30 Tagen und von Schwachstellen mit hohem Schweregrad innerhalb von 90 Tagen.
• CIS-Kontrolle 7.4 empfiehlt, Patches nach Möglichkeit automatisiert bereitzustellen, um menschliche Verzögerungen in der Behebungspipeline zu reduzieren.

Die eigentliche Einschränkung ist die Teamkapazität. Ein zweiköpfiges IT-Team, das 500 Endgeräte verwaltet, kann nicht jede CVE wöchentlich manuell nachverfolgen und beheben. Automatisierung, klare SLA-Stufen und Tools, die priorisierte Maßnahmen aufzeigen, sind der Schlüssel dafür, wie kleinere Teams eine vertretbare Sicherheitslage aufrechterhalten können.

Wenn Sie Ihr Programm aufbauen oder optimieren, beginnen Sie mit der CISA-KEV-Liste, integrieren Sie EPSS zur Priorisierung und automatisieren Sie die Betriebssystem-Patches für Ihre Apple-Flotte. Diese Kombination behebt die Schwachstellen mit der höchsten Wahrscheinlichkeit und den größten Auswirkungen bei minimalem manuellem Aufwand.

Sind Sie bereit, die Lücke zwischen der Offenlegung von CVEs und deren Behebung in Ihrer Apple-Flotte zu schließen? Fordern Sie eine Demo an und erfahren Sie, wie die kontinuierliche Compliance und die automatisierte Patch-Durchsetzung von Iru in der Praxis funktionieren.