Teil 1: Das 50.000-Schwachstellen-Paradoxon – Warum ein Security-Dashboard allein nicht reicht

Eine Szene aus einem ISO-Audit: Der IT-Leiter präsentiert das neue Security-Dashboard auf einem großen Bildschirm, um die dadurch dazugewonnene Übersichtlichkeit zu demonstrieren. Das moderne Interface leuchtet in Alarmfarben. Zentral platziert und absolut unübersehbar stehen dort 50.000 offene Schwachstellen.

„Wir scannen unsere gesamte Infrastruktur wöchentlich“, erklärt er stolz über die erreichte Transparenz. „Wir haben die absolute Übersicht.“

Auf die Nachfrage des Auditors, nach welchen Kriterien diese 50.000 Lücken priorisiert werden, antwortet der Informationssicherheitsbeauftragte mit Überzeugung: „Wir selektieren nicht. Wir betrachten grundsätzlich alle Schwachstellen.“

Auf die Nachfrage hin, wie die operative Umsetzung dieser Mammutaufgabe gesteuert wird, folgt eine knappe Antwort: „Darum kümmert sich die IT.“

Dieses Gespräch klingt auf den ersten Blick pflichtbewusst und gründlich. In der Praxis geht es jedoch am Ziel vorbei. Wer bei 50.000 offenen Befunden behauptet, grundsätzlich alle zu betrachten, kapituliert in Wahrheit vor der Masse und verliert den Blick für das Wesentliche.

Die harte Realität im IT-Betrieb lautet: Nicht jede Schwachstelle ist gleich wichtig. Wer alles als gleich kritisch behandelt, behandelt am Ende gar nichts.

Dieses Szenario ist kein Einzelfall, sondern ein branchenweites Muster. Sichtbarkeit wird fälschlicherweise mit Handlungsfähigkeit verwechselt.

1. Die Illusion der Kontrolle: Schwachstelle ist nicht gleich Risiko

Wer 50.000 unbewertete Schwachstellen als Steuerungskennzahl nutzt, begeht einen methodischen Denkfehler. Eine nackte Summe offener Lücken ist keine Kennzahl, sondern lediglich Datenrauschen. Sie zeigt nur, dass der Scanner funktioniert, sagt aber nichts darüber aus, wie groß die Bedrohung für das Unternehmen tatsächlich ist.

Hier wird das Fundament des Risikomanagements ignoriert. Eine Schwachstelle an sich ist noch kein Risiko. Ein Risiko entsteht erst dann, wenn eine Schwachstelle auf eine reale Bedrohung trifft und ein geschäftskritisches System betrifft.

Ein Dashboard, das nur die Anzahl an Schwachstellen zählt, klammert zwei Drittel dieser Gleichung aus. Es erzeugt Transparenz, aber Transparenz allein reduziert kein Risiko.

Zusätzlich bläht ein technischer Effekt die Zahlen künstlich auf und verzerrt die Priorisierung. Hinter 50.000 offenen Einträgen stecken fast nie 50.000 unterschiedliche Sicherheitsprobleme.

Ist eine veraltete Browserversion oder ein fehlendes Update auf 1.000 Arbeitsplatzrechnern installiert, meldet der Scanner im Dashboard 1.000 offene Schwachstellen. Für den IT-Betrieb handelt es sich dabei jedoch um eine einzige Aufgabe, nämlich die Verteilung eines zentralen Softwarepakets.

Auf der anderen Seite steht vielleicht ein einziger, manuell gepflegter Datenbankserver mit einer verheerenden Sicherheitslücke. Im Dashboard zählt dieser Fall als genau ein Befund. Seine Behebung erfordert jedoch aufwendige Tests, Abstimmungen und geplante Ausfallzeiten.

Ohne die Unterscheidung zwischen reinen Vorkommen auf Endgeräten und tatsächlich zu lösenden, einzigartigen Schwachstellen misst das Dashboard nicht das Cyber-Risiko, sondern schlicht die Größe der Infrastruktur.

Wenn alles kritisch ist, sinkt die Handlungsbereitschaft

Diese Praxis hat spürbare Folgen für das gesamte Team:

Wenn ein Admin-Team mit 50.000 unpriorisierten Aufgaben konfrontiert wird, sinkt die Motivation. Wenn anscheinend alles die höchste Priorität hat, verschwimmen die eigentlichen Ziele und notwendige Entscheidungen werden vertagt.

Fordert das Management stur sinkende Zahlen, reagiert die IT rational, aber strategisch falsch. Es werden die am einfachsten zu behebenden Lücken abgearbeitet, etwa harmlose Client-Updates. Die Zahlen im Dashboard sinken schnell, während die eine kritische Lücke auf einem zentralen Server unangetastet bleibt, weil ihre Behebung komplex ist.

Tausende behobene Kleinigkeiten sehen im Report gut aus. Ein paar wenige ungeschlossene, kritische Lücken reichen jedoch völlig aus, um den Betrieb lahmzulegen.

2. Die Haftungsfalle im Risikomanagement

Viele Organisationen gehen davon aus, dass wöchentliches Scannen ausreicht, um Vorgaben wie NIS-2, DORA oder ISO 27001 zu erfüllen. Das ist ein Irrtum. Regulatorische Standards fordern kein reines Aktivitäts-Reporting, sondern ein funktionierendes Risikomanagement.

Ein bekanntes, aber unberücksichtigtes Risiko stellt im Ernstfall ein organisatorisches Versäumnis dar. Die Lücken sind dokumentiert und im Dashboard sichtbar, aber konkrete, risikobasierte Maßnahmen bleiben aus.

Nach einem erfolgreichen Angriff wird das Dashboard selbst zum Beleg dafür, dass Schwachstellen zwar bekannt waren, aber nicht gezielt gesteuert wurden.

3. Die drei organisatorischen Schwachstellen

Schwachstellenmanagement scheitert selten an der Technik. Meist liegt es an fehlenden Schnittstellen im Prozess.

Die Security-Abteilung erzeugt Transparenz durch Scans, während der IT-Betrieb die Anpassungen umsetzen soll. Dazwischen fehlt oft die kommunikative Verbindung. Reports werden verteilt, aber die Umsetzung gerät ins Stocken, weil eine klare, gemeinsame Prozessverantwortung fehlt.

Ohne Bezug zu den Geschäftsprozessen bleibt jede Priorisierung unvollständig. Für eine sinnvolle Risikobewertung muss klar sein, welche Systeme für die Wertschöpfung entscheidend sind, welche Server direkt aus dem Internet erreichbar sind und wo eine reale Bedrohung vorliegt.

Regeln wie „Alles über einem bestimmten CVSS-Wert sofort patchen“ greifen zu kurz. Ein hoher CVSS-Wert auf einem isolierten Testsystem bedeutet ein geringes reales Risiko. Ein mittlerer CVSS-Wert auf einem zentralen, extern erreichbaren System erfordert dagegen sofortiges Handeln.

4. Integriertes Risikomanagement als Lösung

Schwachstellenmanagement muss als fester Bestandteil des Risikomanagements verstanden werden. Wirksame Risikoreduktion entsteht aus einer Kette von Priorisierung, Verantwortung, Fristen und Nachverfolgung.

Nach etablierten Standards gibt es vier Wege, mit Risiken umzugehen:

• Risikoreduktion: Die Schwachstelle wird durch ein Update behoben. Hierfür braucht es verbindliche Service Level Agreements, damit kritische Lücken auf Kernsystemen innerhalb klar definierter Fristen geschlossen werden.
• Risikovermeidung: Wenn ein System unbehebbare Schwachstellen aufweist und das Risiko zu hoch ist, wird der Dienst abgeschaltet oder durch eine sichere Alternative ersetzt.
• Risikotransfer: Verlagerung des Risikos, beispielsweise durch Auslagerung an einen spezialisierten Dienstleister oder die Absicherung über Versicherungen.
• Formale Risikoakzeptanz: Lässt sich eine Schwachstelle nicht sofort beheben, muss dieser Zustand formal dokumentiert werden. Das Risiko wird mit kompensierenden Maßnahmen abgemildert, vom Verantwortlichen freigegeben und im zentralen Risikoregister erfasst. Damit liegt die Verantwortung nachvollziehbar bei der Unternehmensführung.

Sinnvolle Kennzahlen messen im Anschluss die tatsächliche Wirkung:

• Mean Time to Remediation: Die durchschnittliche Zeit von der Erkennung bis zur vollständigen Behebung einer Schwachstelle.
• SLA-Erfüllungsgrad: Die Einhaltung der eigenen Bearbeitungsfristen.
• Risiko-Exponiertheit: Anzahl und Dauer offener, kritischer Lücken auf extern erreichbaren Systemen.

5. Fazit: Aus Datenrauschen wird Steuerung

Die entscheidende Frage für Verantwortliche lautet nicht, wie viele Schwachstellen im Dashboard stehen. Sie lautet, ob die tatsächlichen Geschäftsrisiken schnell und messbar reduziert werden.

Ein Dashboard mit 50.000 unpriorisierten Einträgen beantwortet diese Frage nicht. Im zweiten Teil des Beitrags zeigen wir, wie sich diese Datenmenge mit intelligenter Triage, Anreicherung durch Bedrohungsinformationen und klaren Abläufen auf wenige relevante Aufgaben reduzieren lässt.