Im ersten Teil des Beitrags ging es um die organisatorische Seite des Problems: Ein Dashboard mit 50.000 unpriorisierten Schwachstellen ist kein Sicherheitsnachweis, sondern eine Bestandsaufnahme des operativen Stillstands. Wenn klare Verantwortlichkeiten fehlen und niemand fristenbasierte Regeln vorgegeben hat, hilft auch kein neuer Scanner.
Nehmen wir jedoch an, die Hausaufgaben sind gemacht und die Führungsebene zieht mit dem IT-Infrastruktur-Team an einem Strang. Dann stehen die Administratoren am Montagmorgen vor der ganz praktischen Frage: Wo fangen wir an und wie fischt man aus fünfstelligen Trefferlisten die Handvoll echter Bedrohungen heraus, die dem Geschäftsbetrieb gefährlich werden könnten?
Die Lösung liegt in einer intelligenten Triage und der richtigen Toolchain. Mit den passenden Mechanismen lässt sich der Berg aus 50.000 Meldungen im Alltag auf wenige Dutzend konkrete Arbeitspakete reduzieren.
1. Deduplizierung – Erst aufräumen, dann bewerten
Die schiere Masse an Meldungen im Dashboard entsteht meistens durch einen Denkfehler im Reporting. Klassische Scanner zählen jedes Vorkommen einer Schwachstelle auf jedem einzelnen System als separaten Befund.
Um dieses Problem zu lösen, kommen Plattformen zur Schwachstellen-Aggregation wie vulsight.io ins Spiel. Sie schalten sich als zentrale Anlaufstelle über bestehende Scanner-Feeds (z. B. Cyberwatch) und filtern den Datenstrom systematisch. Wenn ein veralteter Browser auf 1.200 Laptops installiert ist, meldet ein Scanner 1.200 Fehler. Eine Aggregationsplattform fasst diese Punkte zu einem einzigen Arbeitspaket zusammen und aus 1.200 Zeilen im Dashboard wird eine klare Aufgabe für das Client-Management: „Browser-Update paketieren und ausrollen“.
Oft laufen mehrere Sicherheitstools parallel, zum Beispiel ein EDR-Agent auf den Servern und ein netzwerkbasierter Scanner. Finden beide dieselbe Sicherheitslücke auf demselben Host, verfälscht das die Statistik. vulsight.io erkennt diese Überschneidungen anhand eindeutiger Asset-IDs (wie Hostnamen oder MAC-Adressen) und führt sie automatisch zusammen.
Über logische Gruppierungen landen die generierten Aufgaben direkt bei den passenden Teams, etwa getrennt nach Linux-Infrastruktur, Windows-Clients oder Netzwerkelementen.
Schon nach dieser technischen Bereinigung schrumpft die scheinbar unlösbare Datenmenge dramatisch zusammen.
2. Der dreidimensionale Risikofilter
Wenn die Duplikate entfernt sind, reicht der reine CVSS-Score einer gefundenen Schwachstelle immer noch nicht aus. Er ist in erster Linie nur eine statische, theoretische Bewertung der veröffentlichten Schwachstelle.
In der Praxis kombiniert man drei Perspektiven, um das reale Risiko zu ermitteln:
Dimension A – Die reale Bedrohungslage
Wir müssen von theoretischen Schwachstellen zu realen Angriffsszenarien kommen. Vulnerability Manager wie Cyberwatch reichern die Daten mit weltweiten Bedrohungsinformationen an:
- CISA KEV – Known Exploited Vulnerabilities: Der Katalog der US-Sicherheitsbehörde CISA führt Schwachstellen, die nachweislich von Angreifern ausgenutzt werden. Eine Lücke mit einem CVSS-Wert von 7.2, die aktiv im Umlauf ist, hat immer Vorrang vor einer theoretischen 9.8er-Lücke, für die es weltweit keinen Exploit gibt.
- EPSS – Exploit Prediction Scoring System: Dieses Modell berechnet täglich die Wahrscheinlichkeit, mit der eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird.
Dimension B – Die Erreichbarkeit
Eine noch so kritische Lücke richtet keinen Schaden an, wenn der betroffene Dienst isoliert ist. Deshalb sollte man sich zur Einschätzung die folgenden Fragen stellen:
- Ist das System direkt aus dem Internet erreichbar?
- Verhindern Firewalls oder Netzsegmentierung den Zugriff auf den verwundbaren Port?
- Läuft der betroffene Dienst überhaupt im Speicher?
Dimension C – Der Geschäftskontext
Ein System ist immer so wichtig wie die Aufgabe, die es im Unternehmen erfüllt.
- Kerninfrastruktur (Domain Controller, Backups, Hypervisor): Hier erfordert selbst ein mittleres Risiko zügiges Handeln.
- Isolierte Testumgebungen: Hier können selbst hohe Einstufungen bis zum regulären Wartungsfenster warten.
Die Priorisierungsmatrix im Alltag
Führt man diese Filter zusammen, entsteht ein klarer Handlungsleitfaden für das Administrationsteam:
| Bedrohung hoch (KEV / EPSS) | Bedrohung gering (Kein aktiver Exploit) | |
|---|---|---|
| Kerninfrastruktur oder exponiert | Prio 1 → Sofortige Behebung (72h) | Prio 3 → Nächstes Wartungsfenster |
| Internes oder Testsystem | Prio 2 → Geplante Behebung (14T) | Prio 4 → Regulärer Rhythmus |
Nach dieser Filterung bleiben von den ursprünglichen 50.000 Meldungen meist nur 30 bis 50 übrig, um die sich sofort gekümmert werden muss. Das ist eine Größenordnung, mit der ein IT-Team arbeiten kann.
3. Automatisierte Übergabe statt Mail-Sintflut
Der größte Bruch im Prozess entsteht beim Wechsel zwischen Security und IT-Betrieb. Wenn das Security-Team Excel-Tabellen oder PDF-Berichte per Mail an die IT schickt, sind die Daten in dem Moment veraltet, in dem sie das Postfach erreichen.
Die Lösung ist eine direkte Kopplung der Aggregationsplattform (z. B. vulsight.io) an das interne Ticketsystem:
- Automatische Ticket-Erstellung: Erreicht ein Befund die Kriterien für „Prio 1“, entsteht automatisch ein Ticket.
- Direktes Routing: Das Ticket geht anhand der Asset-Eigenschaften direkt an die richtige Fachgruppe.
- Kontext mitliefern: Die Meldung enthält nicht nur die Risikobewertung, sondern direkt Verweise auf die benötigten Updates und die Begründung der Priorität.
- Schließen per Rescan: Sobald die Admins das Update eingespielt haben, erkennen Vulnerability-Managementplattformen wie Cyberwatch beim nächsten Scan die Behebung. vulsight.io übernimmt dieses Signal und schließt das Ticket automatisch.
4. Entlastung durch aDvens „mySOC for Vulnerabilities“
Selbst bei gut strukturierten Tickets bleibt im Tagesgeschäft ein Nadelöhr. Die IT-Infrastruktur-Teams haben meist alle Hände voll zu tun und kaum Zeit, eingehende Meldungen fachlich zu prüfen.
Hier setzt ein Managed SOC Service wie aDvens „mySOC for Vulnerabilities“ auf Basis von Cyberwatch an.
In dieser Konstellation geht es ausdrücklich nicht darum, dass das SOC eigenmächtig Patches auf den Produktivsystemen einspielt. Die Hoheit über den laufenden Betrieb, das Change Management und die Installationen bleibt zu 100 Prozent bei den internen IT-Infrastruktur-Teams. Das SOC (oft in diesem Kontext auch als Vulnerability Operations Center [VOC] bezeichnet) übernimmt vielmehr die analytische Entlastung und Qualitätssicherung:
- Kontinuierliche Überwachung: Das SOC behält die Systeme über die Cyberwatch-Plattform laufend im Blick.
- False Positives aussortieren: Die Security-Analysten prüfen eingehende Befunde im spezifischen Kundenkontext. Sie sortieren Fehlalarme aus, bevor diese überhaupt beim IT-Betrieb ankommen.
- Vorbereitete Arbeitspakete: Die IT erhält keine ungeprüften Rohdaten, sondern verifizierte, priorisierte Arbeitsaufträge mit klaren Empfehlungen. Die Admins müssen keine Ursachenforschung mehr betreiben, sondern können sich direkt auf das Ausrollen der Korrekturen konzentrieren.
- Verifikation nach dem Patch: Sobald die IT die Updates eingespielt hat, erkennt Cyberwatch die Veränderung im nächsten Durchlauf. Das SOC bestätigt den geschlossenen Sicherheitskreis und dokumentiert den Status für Audits und Geschäftsführung.
Fazit: Aus Rauschen wird Steuerung
Werkzeuge allein lösen das Schwachstellen-Problem nicht, aber sie ermöglichen die nötigen Prozesse überhaupt erst.
Indem Unternehmen ihre Daten mit vulsight.io konsolidieren, sie mit realen Bedrohungslagen anreichern und die kontinuierliche Auswertung einem kompetenten Managed SOC wie mySOC for Vulnerabilities überlassen, entsteht aus einer unüberschaubaren Datenflut ein verlässliches Risikomanagement.
Aus dem wirren 50.000-Meldungen-Dashboard wird so ein ruhiges, präzises Frühwarnsystem. Sie scannen nicht mehr, um Zahlen aufzuhäufen, sondern um die wichtigsten Werte Ihres Unternehmens gezielt und nachweisbar zu schützen.
