Vulnerability Management

Vulnerability Scanning ist ein automatisierter Erkennungsvorgang: Ein Tool durchsucht definierte Hosts, IP-Ranges oder Applikationen nach bekannten CVEs und Fehlkonfigurationen und liefert einen Report. Dieser Vorgang kann einmalig stattfinden – vor einem Audit, nach einer Systemänderung – oder regelmäßig geplant sein. Das Ergebnis ist eine Liste von Befunden. Vulnerability Management ist dagegen der strukturierte, kontinuierliche Prozess, der Scanning als Datenquelle nutzt, aber weit darüber hinausgeht: Wer ist verantwortlich für die Behebung? Binnen welcher Frist? Was passiert, wenn die Frist nicht eingehalten wird? Wie wird dokumentiert, dass eine Schwachstelle geschlossen oder als Ausnahme akzeptiert wurde?

Der entscheidende Unterschied liegt in der Operationalisierung: Ein Schwachstellenscan erzeugt Daten. Vulnerability Management macht daraus Entscheidungen und Maßnahmen. Konkret bedeutet das: risikobasierte Priorisierung, bei der CVSS-Score allein nicht ausreicht – Asset-Kritikalität, Netzwerkexposition und aktive Exploitbarkeit (EPSS, CISA KEV) sind mindestens genauso wichtig. Definierte SLA-Klassen: kritische Schwachstellen innerhalb von 24–72 Stunden, hohe innerhalb von 7–14 Tagen. Automatisierter Ticket-Workflow in ITSM-Systemen (Jira, ServiceNow). Strukturiertes Ausnahme-Management für nicht sofort behebbare Schwachstellen. Und KPIs – Mean Time to Remediate, Patch Compliance Rate – die Fortschritt messbar und gegenüber Auditoren nachweisbar machen.

Wann brauchen Sie was? Ein einmaliger Schwachstellenscan ist sinnvoll als Einstieg, vor und nach größeren Infrastrukturänderungen oder wenn ein punktueller Audit-Nachweis gefordert ist. Ein vollständiges VM-Programm ist erforderlich, wenn kontinuierliche Sicherheitsverbesserung das Ziel ist – und wenn regulatorische Anforderungen es verlangen: NIS2 Artikel 21 fordert risikobasierte Maßnahmen mit messbarer Wirksamkeit, ISO 27001 Annex A.8.8 verlangt dokumentiertes Schwachstellenmanagement mit Behebungsnachweis, und DORA schreibt für Finanzunternehmen einen formalen ICT-Risikomanagementprozess vor. In allen drei Fällen reicht ein periodischer Scan als alleiniger Nachweis nicht aus.

Vulnerability Management (VM) ist der strukturierte, kontinuierliche Prozess zur Erkennung, Klassifizierung, Priorisierung und Behebung von Sicherheitsschwachstellen in IT-Systemen. Der Unterschied zu einem einmaligen Pentest ist fundamental: Ein Penetrationstest ist eine Momentaufnahme, die zeigt, wie das System heute aussieht. VM ist ein dauerhafter Prozess, der sicherstellt, dass neue Schwachstellen erkannt werden – bei jedem neuen CVE, jeder Konfigurationsänderung, jeder neuen Systemkomponente.

Ein vollständiges VM-Programm umfasst weit mehr als das Abonnement eines Vulnerability-Scanners. Es braucht vollständige Asset-Sichtbarkeit (man kann nicht scannen, was man nicht kennt), einen definierten Scan-Rhythmus (kontinuierlich für kritische Systeme, wöchentlich oder monatlich für andere), klare Priorisierungskriterien, Verantwortlichkeiten für die Behebung, SLAs für verschiedene Schwachstellenklassen, Ausnahme-Management für Schwachstellen, die nicht sofort behoben werden können, und KPIs zur Messung der Programm-Effektivität.

Viele Unternehmen haben Schwachstellenscanner im Einsatz, aber kein VM-Programm: Scans laufen unregelmäßig, Ergebnisse werden nicht priorisiert, Tickets werden erstellt aber nicht konsequent verfolgt, und Ausnahmen werden mündlich vereinbart. Das Ergebnis ist ein wachsender Backlog ohne klar messbare Risikoreduktion. Wir helfen Ihnen, aus einer Scan-Praxis ein funktionierendes Programm zu machen.

CVSS (Common Vulnerability Scoring System) ist ein nützliches Werkzeug zur Einschätzung der technischen Schwere einer Schwachstelle – aber als alleiniges Priorisierungskriterium unzureichend. Ein CVSS 9.8 auf einem isolierten internen System ist weniger dringlich als ein CVSS 6.5 auf einem öffentlich erreichbaren Webserver. Und eine Schwachstelle mit CVSS 7.0, für die ein Exploit-Kit existiert und die aktiv in Ransomware-Kampagnen ausgenutzt wird, ist kritischer als eine theoretische CVSS 9.0 ohne bekannte Ausnutzung.

Wir entwickeln risikobasierte Priorisierungsmodelle, die mehrere Faktoren kombinieren: CVSS-Score als Basisindikator, EPSS (Exploit Prediction Scoring System) für die Wahrscheinlichkeit aktiver Ausnutzung, CISA KEV (Known Exploited Vulnerabilities) als Signal für tatsächlich aktiv genutzte Schwachstellen, Asset-Kritikalität (was wäre der Schaden, wenn dieses System kompromittiert wird?), Netzwerk-Exposition (intern vs. DMZ vs. Internet-exponiert) und Kompensationsmaßnahmen (ist ein WAF oder IPS vorgelagert?).

Das Ergebnis ist eine priorisierte Arbeitsliste, die Ressourcen auf die tatsächlich riskantesten Schwachstellen lenkt – statt alle gleichmäßig zu behandeln. In einer durchschnittlichen Unternehmensumgebung gibt es Tausende offene CVEs; mit risikobasierter Priorisierung konzentriert sich die Arbeit auf die 1-5 %, die das reale Risikoprofil dominieren.

VM funktioniert nicht als isolierter Prozess. Die enge Integration mit Patch Management ist essenziell: VM identifiziert Schwachstellen, Patch Management schließt sie. Beide Prozesse brauchen dieselbe Asset-Inventarisierung, und das Ticketing-System verbindet sie. Wir stellen sicher, dass der Datenfluss zwischen VM-Plattform (Tenable, Qualys, Rapid7) und Patch-Management-Tools (SCCM, Intune, Ansible) automatisiert und ohne Reibungsverluste funktioniert.

Die Effektivität eines VM-Programms wird durch KPIs messbar. Wichtige Metriken sind: Mean Time to Remediate (MTTD) nach Schwachstellenklasse, Patch-Compliance-Rate (Anteil der Systeme ohne kritische offene Schwachstellen), Scan-Coverage (Anteil der inventarisierten Systeme, die tatsächlich gescannt werden), und Ausnahmen-Backlog (wie viele Schwachstellen sind als Ausnahme genehmigt und warum). Diese KPIs machen das Programm für das Management nachvollziehbar und für Auditoren nachweisbar.

VM-Programme scheitern oft nicht an der Technik, sondern an der Organisation: Wenn Verantwortlichkeiten unklar sind, SLAs nicht eingehalten werden und Eskalationswege nicht funktionieren, sammeln sich Schwachstellen an statt behoben zu werden. Wir helfen dabei, nicht nur die technischen Werkzeuge einzurichten, sondern auch die Governance-Strukturen, die das Programm langfristig wirksam halten.