Vulnerability Threat Intelligence & KI: So entwickelt Holm Security Schwachstellentests

Holm Security nutzt KI, um Entwürfe für Schwachstellentests aus Vulnerability Threat Intelligence zu destillieren und diese dann mit dem Security-Research-Team zu validieren, bevor die Tests in Ihrer Umgebung zum Einsatz kommen.

Irgendwo da draußen veröffentlicht ein Sicherheitsforscher gerade Details zu einer Schwachstelle, die gestern noch gänzlich unbekannt war. Eine CVE-Nummer wird vergeben, die Sicherheitsmeldung (Advisory) geht online und ab diesem Moment tickt die Uhr für jedes Unternehmen, das das betroffene Asset einsetzt.

Zwischen der Veröffentlichung der Meldung und dem Auftauchen der Schwachstelle im Bericht eines Unternehmens liegt jedoch ein weiterer Arbeitsschritt, denn eine Veröffentlichung ist noch keine Erkennung. Jemand muss den eigentlichen Test schreiben – jene Logik, die prüft, ob genau diese Schwachstelle in einem bestimmten Asset vorhanden ist. Wie schnell das geschieht, ist zu einem der aufschlussreichsten Kriterien bei der Bewertung einer Schwachstellenmanagement-Plattform geworden.

Dieses Zeitfenster so klein wie möglich zu halten, ist die Hauptaufgabe unseres Security-Research-Teams und genau hier hat KI unsere Arbeitsweise grundlegend verändert. In den folgenden Abschnitten gehen wir ein bisschen tiefer auf den Prozess ein: von der Erstveröffentlichung irgendwo im Internet bis zum validierten Test in Ihrer Umgebung.

Die ersten 24 Stunden einer Schwachstelle

Es lohnt sich, den Weg einer einzelnen Schwachstelle in ihren ersten 24 Stunden zu genauer zu betrachten, denn der zeitliche Ablauf ist selten so geordnet, wie man annehmen würde.

Sie taucht irgendwo auf, und dieses „irgendwo“ ist keineswegs immer eine offizielle Datenbank. Es kann ein Hersteller-Advisory sein, ein Thread in einem Security-Forum oder ein Bericht in einem IT-Sicherheitsmedium Stunden, bevor die offiziellen Datenbanken nachziehen. Innerhalb eines Tages kann ein öffentlich zugänglicher Proof-of-Concept-Code (PoC) auftauchen, was die Lage schlagartig verändert. Innerhalb weniger Tage taucht dieselbe Schwachstelle womöglich schon in ersten Ransomware-Kampagnen auf.

Multiplizieren Sie das nun mit der Vielzahl anderer Schwachstellen, die am selben Tag exakt denselben Weg nehmen. Das ist das eigentliche Problem, das wir lösen müssen: Eine kontinuierliche Flut an Schwachstellen mit KI  zu kanalisieren, während Cyberkriminelle diese nutzen, um Sicherheitslücken schneller zu finden und auszunutzen.

Über 30 Quellen für Vulnerability Threat Intelligence im Blick

Unser Security-Research-Team überwacht dafür mehr als 30 Quellen. Keine einzelne Quelle ist schnell und gleichzeitig umfassend genug, um sich allein auf sie zu verlassen. Daher muss die Abdeckung breit aufgestellt sein, um schnell reagieren zu können. Zu unseren Quellen gehören:

Offizielle und behördliche Quellen

• CISA Known Exploited Vulnerabilities (KEV) Katalog
• National Vulnerability Database (NVD)
• CVE.org
• European Union Vulnerability Database (EUVD)
• Nationale CERTs

Herstellerquellen

• Sicherheitsmeldungen der Hersteller (Vendor Advisories)

 Exploit-Quellen 

• Metasploit
• Exploit-DB

Community Intelligence

• Vulmon
• Vulners

Security-News & Foren

• BleepingComputer
• The Hacker News

Der Mix ist entscheidender als die reine Anzahl. Oft wird eine Schwachstelle von Sicherheitsforschern in Foren diskutiert, bevor sie in einer Datenbank präzise erfasst wurde. Öffentlicher Exploit-Code kann einen Routinebefund über Nacht zur dringlichsten Aufgabe machen.

Aber: Der CISA-KEV-Katalog nimmt hierbei eine Sonderrolle ein, da er zeigt, dass eine Schwachstelle nicht nur theoretischer Natur ist, sondern bereits aktiv gegen reale Unternehmen eingesetzt wird.

Prioritäten: Was wird zuerst getestet?

Der reine Schweregrad (Severity Score) erweist sich oft als unzureichendes Kriterium für die Priorisierung, wie jeder weiß, der schon einmal eine ellenlange Schwachstellenliste abarbeiten musste.

Eine als „kritisch“ eingestufte Schwachstelle, die niemand ausnutzt und die in einem kaum verbreiteten Produkt steckt, hat eine geringere Priorität als eine „mittlere“ Schwachstelle, die Ransomware-Akteure genau diese Woche aktiv ausnutzen. Die Kluft zwischen der theoretischen Schwere einer Lücke und dem, was in der Praxis passiert, entscheidet darüber, ob man Schwachstellen lediglich bewertet oder die reale Risikoexposition versteht. Genau das ist der Kernansatz von risikobasiertem Schwachstellenmanagement (Risk-Based Vulnerability Management).

Unsere Triage gewichtet die tatsächliche Ausnutzung (Exploitation) stärker als den rein rechnerischen Score. Wir prüfen: Ist die Schwachstelle im CISA KEV gelistet? Existiert funktionierender, öffentlicher Exploit-Code? Steht sie in Verbindung mit Ransomware-Aktivitäten? Und wie weit ist das betroffene Produkt in der Praxis verbreitet?

In Fachkreisen wird dies oft als Debatte „CVSS vs. EPSS“ geführt. In der täglichen Praxis ersetzt jedoch kein Score das konkrete Wissen darüber, was Angreifer aktuell gegen Unternehmen einsetzen.

Die Erstellung des Tests

Sobald eine Schwachstelle an der Reihe ist, wird die Arbeit schnell konkret. Das betroffene Produkt und die genauen Versionsbereiche müssen präzise eingegrenzt werden. Die passende Erkennungsmethode muss gewählt werden und der Test muss die Schwachstelle zuverlässig identifizieren, ohne das zu prüfende Asset zu beeinträchtigen oder zu stören.

Hier übernimmt die KI den Großteil der harten Arbeit: Sie liest Advisories, extrahiert die betroffenen Versionen, entwirft die Testlogik und bewältigt so Datenmengen, die ohne Automatisierung in der Warteschlange liegen würden. Das Ergebnis dieses Prozesses ist ein automatisierter Testentwurf.

Die Vaildierung

Jeder Test wird zunächst automatisch geprüft und anschließend vor der Freigabe von einem Security Researcher begutachtet. Die wichtigste Prüfung vergleicht den Test mit der zugrunde liegenden Sicherheitsmeldung. Fehler äußern sich fast immer in leicht fehlerhaften Versionsbereichen, was dazu führen kann, dass der Test bereits gepatchte Systeme fälschlicherweise meldet oder noch verwundbare Systeme übersieht. Solche Tests werden korrigiert und erneut geprüft, bevor sie freigegeben werden.

Tests, die eine Schwachstelle aktiv ausnutzen (aktive Prüfungen), führen wir zusätzlich in unserer Laborumgebung an einem real verwundbaren System aus. Die Freigabe erfolgt erst, wenn der Test die Schwachstelle auf dem anfälligen System zuverlässig erkennt und auf einem identischen, bereits gepatchten System keinerlei Befund meldet.

Wichtig ist: Ein Security Researcher entscheidet letztlich, ob ein Test bereit für den Einsatz ist. Er analysiert Advisory und Testlogik im Zusammenhang, beurteilt die Richtigkeit der Erkennung und gibt den Test final frei.

Was die KI übernimmt & was der Mensch leistet

Die Arbeitsteilung ist klar geregelt: KI sorgt für Skalierbarkeit, der Mensch bringt die Urteilskraft und Expertise ein. Die KI überwacht kontinuierlich alle Quellen, strukturiert Advisories in den unterschiedlichsten Formaten, entwirft Testlogiken und hebt dringliche Fälle hervor. Das ist die Arbeit, die früher das Arbeitstempo jedes Research-Teams bremste.

Experten entscheiden weiterhin, wann ein Testentwurf fehlerhaft ist, analysieren, warum ein System in der Praxis anders reagiert als im Advisory beschrieben, und entwickeln Tests für Produkte, deren Dokumentation lückenhaft, veraltet oder widersprüchlich ist.

Die Bedeutung für Ihren Schwachstellen-Report

Zwei Unternehmen können Scans laufen lassen und identische Assets besitzen und dennoch ein völlig unterschiedliches Bild ihrer Risikolage erhalten. Der Unterschied liegt selten im Scan-Vorgang selbst. Er liegt darin, wie schnell eine neu veröffentlichte Schwachstelle vom Plattformanbieter in eine prüfbare Regel übersetzt wird, nach welchen Kriterien die Priorisierung erfolgt und wie gründlich dieser Prozess qualitätsgesichert wurde, bevor die Ergebnisse bei Ihnen ankommen.

Solche Details werden Kaufinteressenten selten offengelegt, aber genau deshalb haben wir sie hier zusammengefasst. Es lohnt sich, zu verstehen, welche Prozesse hinter den Zahlen auf Ihrem Dashboard stehen, ganz gleich, von welchem Anbieter sie stammen. Wenn Sie das nächste Mal Plattformen für Exposure und Vulnerability Management vergleichen oder eine Lizenz verlängern, sollten Sie folgende drei Fragen stellen:

• Woher stammen die Bedrohungsinformationen zur Schwachstelle?
• Nach welchen Kriterien wird entschieden, welche Schwachstellen zuerst abgedeckt werden?
• Wer prüft die Funktionsfähigkeit eines Tests, bevor Sie sich darauf verlassen?

Erfahren Sie mehr darüber, wie Holm Security neue Schwachstellen über all Ihre Assets hinweg identifiziert und priorisiert: Zum Demo Video.

FAQ

1. Was ist Vulnerability Threat Intelligence?

   Vulnerability Threat Intelligence bezeichnet Bedrohungsinformationen rund um eine spezifische Schwachstelle um zu bestimmen, welche Schwachstellen aktuell tatsächlich relevant sind: Was wurde veröffentlicht? Was wird aktiv ausgenutzt? Existiert öffentlicher Exploit-Code? Und welche Ihrer Assets sind betroffen? Sie verwandelt eine unübersichtliche Liste von Befunden in eine nachvollziehbare, fundierte Priorisierung.
   
   

2. Welche Schwacshtellen-Quellen überwacht Holm Security?

   Mehr als 30 Quellen, darunter CISA KEV, NVD, CVE.org, EUVD, nationale CERTs, Hersteller-Advisories, Metasploit, Exploit-DB, Vulmon, Vulners sowie IT-Sicherheitsmedien und Foren wie BleepingComputer und The Hacker News.
   
   

3. Erstellt KI Schwachstellentest?

   Ja, KI erstellt die Entwürfe und übernimmt die wiederkehrende Analyse im Hintergrund. Wir validieren jedoch jeden einzelnen Test durch Experten, bevor er live geht. Unser Security-Research-Team kümmert sich um manuelle Analysen, produktspezifische Besonderheiten und all jene Sonderfälle, die die Automatisierung nicht abdecken kann.
   
   

4. Warum reicht der CVSS-Schweregrad allein nicht zur Priorisierung aus?

   Der CVSS-Schweregrad beschreibt lediglich das theoretische Schadenspotenzial einer Schwachstelle, nicht jedoch, ob sie tatsächlich ausgenutzt wird. Eine Schwachstelle mit mittlerem Schweregrad, die in aktiven Ransomware-Kampagnen genutzt wird, erfordert ein deutlich schnelleres Handeln als eine kritische Lücke, für die es keinerlei Angriffsaktivitäten gibt.