Schwachstellenscans lassen sich heute in vielen Umgebungen automatisieren. Scanner laufen regelmäßig, neue Ergebnisse werden erzeugt und Berichte stehen meist innerhalb weniger Minuten bis Stunden bereit. Ob eine einzelne Erkennung oder Tausende – die Frage danach bleibt gleich: Was ist jetzt dringend und wichtig?
In der Praxis bedeutet das häufig mehrere Schritte: Ein Security Team sichtet die Ergebnisse und bewertet zusätzlich zum Bericht die technische Schwere einer Schwachstelle. Anschließend prüft das verantwortliche Team, ob das betroffene System tatsächlich relevant ist und ob die Schwachstelle überhaupt zutrifft. Manchmal zeigt sich dabei, dass eine Funktion gar nicht genutzt wird oder eine Komponente zwar vorhanden ist, jedoch anders konfiguriert wurde.
Dieser zusätzliche Kontext ist ein wichtiger Bestandteil der Bewertung für die Priorisierung. Neben technischen Metriken wie CVSS oder EPSS spielt auch das betroffene System eine Rolle. Ist das System direkt aus dem Internet erreichbar? Handelt es sich um ein isoliertes System? Kann es überhaupt aktualisiert werden oder handelt es sich möglicherweise um ein False Positive?
Weshalb CVSS allein selten ausreicht
Viele Schwachstellen werden zunächst über ihren CVSS Score bewertet. Der Score liefert eine standardisierte Einschätzung der technischen Schwere einer Schwachstelle. In die Bewertung fließen unter anderem Faktoren wie die erforderliche Zugriffsmöglichkeit, die Komplexität eines Angriffs, notwendige Privilegien sowie mögliche Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit ein. Der CVSS-Bewertungsstandard selbst wird regelmäßig weiterentwickelt.
Das ist ein hilfreicher Ausgangspunkt. Gleichzeitig beschreibt der CVSS Score nur einen Teil der Realität.
Im CVSS Base Score bleiben folgende Faktoren grundsätzlich unberücksichtigt:
- Ist ein Exploit bereits verfügbar?
- Wird eine Schwachstelle aktuell aktiv ausgenutzt?
- Existiert das betroffene System überhaupt im eigenen Umfeld?
- Ist das System direkt aus dem Internet erreichbar oder handelt es sich um ein isoliertes System?
Eine Schwachstelle mit hohem CVSS Score kann daher im eigenen Umfeld kaum relevant sein, während eine andere Schwachstelle mit niedrigerem Score in einer bestimmten Situation deutlich kritischer werden kann.
Der CVSS-Score liefert somit in erster Linie ein erstes Indiz für den technischen Schweregrad einer Schwachstelle.
Weitere Signale für eine fundierte Priorisierung
Um Schwachstellen besser bewerten zu können, betrachten viele Organisationen zusätzliche Informationen. Diese liefern Hinweise darauf, welche Schwachstellen aktuell besonders relevant sein könnten. Dazu zählen beispielsweise das Exploit Prediction Scoring System (EPSS), verfügbare Exploits oder Proof of Concept Exploits, erhöhte Aufmerksamkeit in Security Blogs oder Medien, Warnungen durch nationale CERTs sowie die Aufnahme einer Schwachstelle in den CISA Known Exploited Vulnerabilities (KEV) Catalog. Auch der Bezug zum eigenen organisatorischen Umfeld – etwa betroffene Systeme oder deren Erreichbarkeit – kann ein wichtiges Merkmal für die Priorisierung sein.
Wahrscheinlichkeit einer Ausnutzung: Das EPSS
Eine weitere Ergänzung zum CVSS-Score ist der EPSS-Score. EPSS steht für Exploit Prediction Scoring System und wird von der Organisation FIRST bereitgestellt. Der Wert schätzt die Wahrscheinlichkeit, dass eine Schwachstelle innerhalb der nächsten 30 Tage tatsächlich ausgenutzt wird. Die Berechnung basiert unter anderem auf beobachteten Angriffen sowie auf Eigenschaften der Schwachstelle selbst, etwa ob sie aus der Ferne ausnutzbar ist oder welche Voraussetzungen ein Angriff benötigt.
Während CVSS in erster Linie den technischen Schweregrad beschreibt, liefert EPSS ein zusätzliches Signal dafür, wie wahrscheinlich eine praktische Ausnutzung ist. Dadurch kann der Score helfen, Schwachstellen zu erkennen, die zwar technisch weniger kritisch wirken, in der Praxis jedoch häufiger angegriffen werden.
EPSS ersetzt jedoch keine eigene Risikoanalyse. Der Wert berücksichtigt weder die konkrete Umgebung einer Organisation noch bestehende Schutzmaßnahmen. In Kombination mit anderen Informationen kann er jedoch ein hilfreicher Hinweis für die Priorisierung sein.
Verfügbare Exploits oder Proof-of-Concepts
Ein weiterer wichtiger Hinweis ist die Verfügbarkeit von Exploits oder sogenannten Proof of Concepts (PoC). Ein PoC zeigt, dass eine Schwachstelle tatsächlich ausgenutzt werden kann und dient häufig als Demonstration für Sicherheitsforscher oder Entwickler.
In der Praxis tauchen solche PoCs häufig in GitHub Repositories, Security Blogs oder auf Konferenzen auf. Sobald ein funktionierender Beispiel Exploit öffentlich verfügbar ist, sinkt in vielen Fällen die Hürde für Angreifer, eine Schwachstelle auszunutzen.
Für die Priorisierung ist daher weniger entscheidend, ob ein PoC existiert, sondern wie leicht sich daraus ein praktischer Angriff ableiten lässt. Wird eine Schwachstelle aktiv in Exploit Kits integriert oder tauchen automatisierte Angriffswerkzeuge auf, steigt die Relevanz deutlich.
Die Verfügbarkeit von Exploits liefert damit ein wichtiges Signal: Sie zeigt, ob eine Schwachstelle nur theoretisch existiert oder ob bereits Werkzeuge im Umlauf sind, die eine Ausnutzung in der Praxis erleichtern.
Berichterstellung und aktuelle Erwähnungen
Einige Schwachstellen erhalten zeitweise besondere Aufmerksamkeit. Sie werden in Security Blogs analysiert, in Medien erwähnt oder intensiv in Research Communities diskutiert.
Solche Signale können darauf hinweisen, dass eine Schwachstelle besonderes öffentliches Interesse erhält, sich neue Angriffsmöglichkeiten entwickeln oder aktiv ausgenutzt werden. Erwähnungen können auch ältere Schwachstellen betreffen und so wieder neue Relevanz gewinnen.
Unabhängige Warnungen vertrauenswürdiger Einrichtungen
Ein weiterer Aspekt für die Priorisierung sind Warnungen vertrauenswürdiger Einrichtungen zu einer Schwachstelle. Eine bekannte Quelle ist der CISA Known Exploited Vulnerabilities (KEV) Catalog. Dieser wird von der U.S. Cybersecurity and Infrastructure Security Agency (CISA) gepflegt und enthält Schwachstellen, für die eine aktive Ausnutzung bereits beobachtet wurde.
Eine weitere Quelle sind Berichte und Warnungen nationaler CERTs oder CSIRTs sowie des CERT-EU. Diese Organisationen veröffentlichen regelmäßig Advisories oder Warnungen zu Schwachstellen, die aktuell ausgenutzt werden oder eine besondere Relevanz für Organisationen haben können.
Der organisatorische Kontext: Betrifft uns diese Schwachstelle überhaupt?
Scanner liefern Ergebnisse zu konkreten Systemen oder Softwarekomponenten. Gleichzeitig werden täglich neue CVEs veröffentlicht, die potenziell Tausende Produkte betreffen können. Damit stellt sich eine grundlegende Frage: Betrifft uns diese Schwachstelle überhaupt und wenn ja, ist es ein kritisches System? Technische Scanergebnisse allein beantworten diese Frage meist nicht vollständig. Ein Bericht zeigt zwar, dass eine bestimmte Softwareversion betroffen sein könnte. Ob die Schwachstelle tatsächlich relevant ist, hängt jedoch stark vom jeweiligen System und seiner Nutzung ab.
Eine wichtige Voraussetzung für diese Bewertung ist daher eine Übersicht über die eigenen Systeme, Produkte und Services. Ebenso relevant ist die Frage nach der Kritikalität: Welche Systeme unterstützen zentrale Geschäftsprozesse? Welche sind experimentell oder isoliert betrieben?
Erst wenn Schwachstellen mit konkreten Systemen, Verantwortlichkeiten und deren Bedeutung für die Organisation verknüpft werden, lässt sich einschätzen, ob eine gemeldete Schwachstelle tatsächlich Priorität erhält.
Fehlt dieser organisatorische Kontext, entsteht schnell ein großer Strom an Informationen, der schwer einzuordnen ist. Schwachstellen erscheinen dann als lange Liste technischer Berichte, ohne klar erkennen zu lassen, welche davon für die eigene Organisation tatsächlich relevant sind. In weiterer Folge kann eine Schwachstelle ein System betreffen, aber die konkret betroffene Funktion wird nicht genutzt. Dies kann auch zu einer anderen Priorität bei der Behandlung der Schwachstelle führen.
Exposure: Wie ist das System erreichbar?
Ein weiterer wichtiger Kontextfaktor ist die Frage, ob ein System direkt aus dem Internet erreichbar ist. Eine Schwachstelle auf einem öffentlich erreichbaren Dienst kann grundsätzlich einfacher ausgenutzt werden als auf einem System, das nur in einer isolierten Testumgebung oder ausschließlich über interne Netze zugänglich ist.
Sind zwei unterschiedliche Systeme von derselben Schwachstelle betroffen, kann ihre Priorität daher stark variieren. Ein öffentlich erreichbarer Service, etwa ein Web Dienst oder eine API, erhält häufig eine höhere Aufmerksamkeit als ein internes System, das nur für einen begrenzten Nutzerkreis erreichbar ist. Dabei geht es nicht nur um klassische Server im Internet. Auch VPN Zugänge, Remote Management Interfaces oder Dienste mit indirekter Erreichbarkeit können eine Rolle spielen. Für die Priorisierung ist daher entscheidend, wie ein System tatsächlich erreichbar ist und welche Angriffswege realistisch bestehen.
Kontext als Grundlage für priorisierte Entscheidungen
Eine fundierte Priorisierung entsteht erst, wenn technische Informationen mit organisatorischem Kontext kombiniert werden. Dazu gehören beispielsweise:
- technische Bewertungen wie CVSS
- zusätzliche Signale wie EPSS oder verfügbare Exploits
- aktuelle Aufmerksamkeit in der Sicherheitscommunity
- Warnungen und Berichte vertrauenswürdiger Einrichtungen
- der organisatorische Kontext betroffener Systeme
- Informationen über Internet-Erreichbarkeit
Erst durch diese Kombination entsteht ein vollständigeres Bild, das eine gezielte Priorisierung ermöglicht. Je nach Bedarf können weitere Informationen ergänzt werden, etwa zur Kritikalität eines Systems, zu bestehenden Schutzmaßnahmen oder zu organisatorischen Abhängigkeiten.
Dieser erweiterte Kontext wird häufig als Vulnerability Intelligence bezeichnet. Er ergänzt technische Scanergebnisse um Informationen, die helfen zu verstehen, welche Schwachstellen für die eigene Organisation tatsächlich relevant sind und welche zuerst betrachtet werden sollten.
