Ein Scanner ist kein Schwachstellenmanagement. Er ist der einfachste Teil davon: ein Programm, das Listen produziert. Die eigentliche Arbeit beginnt nach der Liste, und genau dieser Teil fehlt in den meisten KMU, die uns ihren Scan-Report zeigen.
Das Muster kennen wir gut. Der IT-Partner oder ein Auditor liefert einen PDF-Report, vierzig Seiten, Ampelfarben, ein paar hundert Findings. Alle sind kurz beunruhigt, jemand verspricht, sich das anzuschauen. Dann wandert der Report in einen Ordner, das Tagesgeschäft übernimmt, und beim nächsten Scan sind es ein paar Findings mehr. Der Scanner war nie das Problem. Er hat geliefert.
Die konkreteste Version davon begegnet uns in Assessments regelmässig: Der Scanner läuft seit Jahren, sauber konfiguriert, monatlicher Lauf, der Report geht automatisch an eine Sammel-Mailbox. Auf die Frage, wer diese Mailbox liest, wird es still. Der Scanner hat seinen Job die ganze Zeit gemacht. Nur hatte niemand den Auftrag, mit dem Ergebnis etwas zu tun. Die Firma bezahlt für Sichtbarkeit und bekommt davon nichts, weil zwischen Sehen und Handeln niemand sitzt.
Schwachstellenmanagement im KMU heisst nicht, diesen Report zu besitzen. Es heisst, dass jemand entscheidet, was davon zählt, dass die relevanten Lücken in einem festen Rhythmus geschlossen werden und dass ihr sagen könnt, warum der Rest offen bleibt. Das klingt unspektakulär. Es ist auch unspektakulär. Aber es ist der Teil, der schützt.
Was nach dem Scan kommt
Der Begriff klingt nach einem Produkt, das man kauft. Es ist aber eine Schleife: finden, bewerten, entscheiden, umsetzen, nachprüfen. Der Scanner erledigt davon genau den ersten Schritt.
Bewerten heisst: Was bedeutet diese Lücke für uns, nicht für die Welt? Entscheiden heisst: patchen, abschalten, isolieren oder das Risiko bewusst tragen. Umsetzen heisst: jemand macht es, in einem Wartungsfenster, ohne die Produktion zu überraschen. Nachprüfen heisst: der nächste Scan bestätigt, dass die Lücke zu ist, und nicht nur der Ticketstatus.
Keine dieser Stationen braucht ein Framework oder eine Zertifizierung. Jede braucht eine Zuständigkeit. Das ist der Unterschied zwischen Firmen mit einem Scanner und Firmen mit Schwachstellenmanagement: Beim einen produziert der Scan Reports, beim anderen Entscheidungen.
Eine Voraussetzung wird dabei gern übersprungen: Ihr könnt nur bewerten, was ihr kennt. Ein Scanner prüft die Systeme, die man ihm zeigt. Der Server aus dem alten Projektvertrag, das NAS im Nebenraum, die Firewall des früheren Dienstleisters tauchen in keinem Report auf, wenn niemand weiss, dass es sie gibt. Deshalb steht vor dem Schwachstellenmanagement das Asset-Inventar. Ohne das ist jede Vollständigkeitsaussage eine Annahme.
Warum der Report allein niemanden schützt
Scan-Reports sortieren nach Schweregrad, meist nach CVSS-Score. Das wirkt objektiv. Als Prioritätenliste gelesen führt es aber in die Irre.
Eine Lücke mit Score 9.8 auf einem System ohne Verbindung nach aussen ist ein kleineres Problem als eine 6.5 auf dem VPN-Gateway, das im Internet steht. Der Score kennt euer Netz nicht. Er weiss nicht, was von aussen erreichbar ist, was geschäftskritisch ist und wo eure Kundendaten liegen. Diese drei Dinge wisst nur ihr, und sie entscheiden die Reihenfolge.
Die Priorisierung ist darum der eigentliche Kern der Arbeit, und sie lässt sich für ein KMU auf zwei Fragen verdichten: Ist das betroffene System von aussen erreichbar? Und wird die Lücke draussen bereits aktiv ausgenutzt? Was beide Fragen mit Ja beantwortet, kommt nach vorn und wird zügig geschlossen. Der grosse Rest läuft im normalen Patch-Rhythmus mit, ohne Hektik.
Das Tempo für die vorderste Gruppe hat sich allerdings verändert. Wir haben in Angreifer im KI-Tempo beschrieben, warum das Fenster zwischen der Veröffentlichung einer Lücke und ihrer Ausnutzung schrumpft. Daraus folgt keine Panik, nur eine Aufteilung in zwei Geschwindigkeiten: ein schneller Takt für das, was exponiert ist, ein gemütlicherer für alles andere. Ein Takt für alles wäre entweder zu langsam für die exponierten Systeme oder unnötig teuer für den Rest.
Den Scanner besitzt du wahrscheinlich schon
Der übliche Reflex, wenn das Thema auf den Tisch kommt: ein Projekt starten, Tools evaluieren, Offerten einholen. Bevor du das tust, lohnt sich ein Blick in die Lizenzen, die ihr schon bezahlt.
Wer Microsoft 365 Business Premium im Haus hat, hat Defender for Business gleich mit, und der bringt die Kernfunktionen des Schwachstellenmanagements mit: Er inventarisiert die Geräte, zeigt fehlende Updates und verwundbare Software und sortiert die Empfehlungen (Quelle: Microsoft Learn, What is Microsoft Defender for Business). Das ist kein Nischenwissen, aber es ist erstaunlich, in wie vielen Umgebungen diese Ansicht noch nie geöffnet wurde.
Damit verschiebt sich die Frage von «Welchen Scanner kaufen wir?» zu «Wer schaut in das rein, was wir haben, und was passiert mit dem, was er sieht?». In unserer Erfahrung ist der Kauf eines zweiten Scanners, während der erste unbeachtet läuft, eine der häufigeren Formen von Security-Theater im Kleinen. Mehr Sicht auf dieselben ungeschlossenen Lücken schützt kein bisschen mehr.
Dieselbe Frage gehört auch an den IT-Partner, falls einer die Umgebung betreut. Viele Verträge decken das Scannen ab, aber nicht das Entscheiden und Umsetzen. Der Partner schickt den Report, das KMU nimmt an, der Partner kümmere sich, der Partner nimmt an, das KMU entscheide. In dieser Lücke zwischen zwei Annahmen bleiben Findings monatelang liegen, und im Vertrag steht sie nirgends. Ein kurzes Gespräch darüber, wer nach dem Report was tut, kostet nichts und klärt mehr als jede neue Lizenz.
Ehrlicherweise hat der Bordmittel-Ansatz Grenzen. Defender sieht Endpoints und Windows-Server gut. Die Firewall, der Hypervisor, das NAS und die selbst betriebene Webapplikation brauchen einen anderen Blick. Aber die Reihenfolge stimmt so: erst nutzen, was bezahlt ist, dann die Lücken in der Abdeckung gezielt schliessen. Das ist dieselbe Logik, mit der wir auch Sicherheitstools konsolidieren: weniger Werkzeuge, die jemand bedient, schlagen mehr Werkzeuge, die niemand anschaut.
Der Engpass heisst Betrieb
Wenn es scheitert, scheitert es selten am Werkzeug. Es scheitert am Betrieb.
Patchen ist Änderungsarbeit. Es braucht Wartungsfenster, Neustarts und die Bereitschaft, dem Geschäft gelegentlich einen unbequemen Termin zuzumuten. Dazu kommt die Angst, dass das ERP nach dem Update nicht mehr startet, und diese Angst ist nicht irrational, wer lange genug Systeme betreibt, hat so eine Geschichte. Wer den Job deshalb der internen IT «nebenbei» gibt, hat faktisch entschieden, dass er liegen bleibt, sobald etwas Dringenderes kommt. Und etwas Dringenderes kommt zuverlässig.
Lösbar ist das auch ohne eigenes Security-Team, aber nicht ohne Entscheid: Jemand besitzt die Schleife. Intern oder extern, mit festem Rhythmus, mit dem Mandat, Wartungsfenster durchzusetzen, und mit der Pflicht, über den Stand zu berichten. Wie diese Rollenverteilung ohne eigenes Team aussehen kann, haben wir in IT-Sicherheit ohne eigenes Security-Team beschrieben. Schwachstellenmanagement ist einer der Jobs, die dort besetzt sein müssen, egal von wem.
Zur Zuständigkeit gehört ein zweiter, oft vergessener Teil: die Berichtslinie nach oben. Die Geschäftsleitung muss keinen Scan-Report lesen, sie soll ihn auch gar nicht lesen. Sie braucht drei Zahlen in verständlicher Sprache: wie viele exponierte Systeme offene kritische Lücken haben, wie lange das Schliessen im Schnitt dauert und welche Ausnahmen bewusst getragen werden. Wer diese drei Zahlen quartalsweise sieht, kann steuern und trägt die Risikoentscheide mit, statt sie nach einem Vorfall zum ersten Mal zu hören. Das ist nebenbei auch der Sorgfaltsnachweis, wenn später jemand fragt, ob das Unternehmen sein Schwachstellenmanagement im Griff hatte.
Zum Betrieb gehören auch die Ausnahmen. Das Alt-System, das den Patch nicht verträgt, wird es bei euch geben, so wie fast überall. Eine Lücke bewusst offen zu lassen ist legitim, wenn es dokumentiert ist und das System dafür isoliert oder enger überwacht wird. Nicht legitim ist das stille Offenlassen, das erst nach dem Vorfall auffällt, wenn jemand fragt, warum der Server von 2016 noch am Netz war und wer das entschieden hat. Auf diese Frage will niemand mit «das hat sich so ergeben» antworten.
Drei Fragen an euren letzten Scan-Report
Ob bei euch Schwachstellenmanagement läuft oder nur ein Scanner, zeigt sich an drei Fragen.
- Wer hat den letzten Report gelesen, und was wurde daraufhin entschieden? Wenn die Antwort «niemand» oder «nichts» lautet, produziert ihr Papier, keine Sicherheit.
- Welche der obersten Findings betreffen Systeme, die von aussen erreichbar sind? Wenn das niemand ohne Nachschauen sagen kann, fehlt die Verbindung zwischen Report und eurer Realität.
- Was wurde seit dem letzten Report nachweislich geschlossen? Im nächsten Scan verschwunden zählt, ein erledigtes Ticket allein noch nicht.
Stehen diese drei Antworten, habt ihr Schwachstellenmanagement, egal wie euer Tool heisst und was es gekostet hat. Stehen sie nicht, hilft auch kein neues Tool. Dann braucht es jemanden mit dem Auftrag, dem Rhythmus und dem Rückhalt der Geschäftsleitung. Genau diese Betriebsrolle übernehmen wir in unserem Security Management, inklusive der unbequemen Gespräche über Wartungsfenster. Wenn du wissen willst, wie das bei euch aussehen könnte, melde dich für ein Erstgespräch, unverbindlich.
Und falls du gerade nachgeschaut hast: Wann hat bei euch zuletzt jemand wegen eines Scan-Reports etwas abgeschaltet oder gepatcht?
