Was eine ungepatchte Schwachstelle auf dem Server kostet

Die rumänische Cybersicherheitsbehörde DNSC hat 2025 insgesamt 2.020 öffentliche Einrichtungen und Betreiber wesentlicher Dienste über mehr als 43.000 ausnutzbare Schwachstellen informiert, die auf ihrer öffentlich exponierten IT-Infrastruktur gefunden wurden — mit der Empfehlung, sie dringend zu beheben. Für die meisten dieser Organisationen ist eine ungepatchte Schwachstelle kein unbekanntes Risiko. Sie ist eine Zeile in einer E-Mail, die jemand bereits erhalten hat, mit Produkt, Adresse und der längst verfügbaren Korrektur.

Was passiert, wenn diese Zeile eine Zeile bleibt, steht im selben Bericht. Aaylex ONE SA, die Lebensmittelgruppe hinter der Marke CocoRico — über 2.000 Beschäftigte, 36 Standorte in neun Kreisen — wurde von Akira-Ransomware getroffen, mit Auswirkungen auf Buchhaltung, Produktion, Betrieb und die Dateiserver; das DNSC stellte später über 66% der Daten wieder her. Der Erstzugang erfolgte höchstwahrscheinlich über die Ausnutzung von CVE-2020-3259 in der Weboberfläche von Cisco-ASA- und Firepower-Threat-Defense-Geräten. Die ersten vier Ziffern dieses Kennzeichens sind das Jahr der Veröffentlichung.

Wie lange das Fenster offen bleibt und was eine ungepatchte Schwachstelle kostet

Der Befund selbst ist längst erhoben, und wir haben ihn separat aufgeschrieben, im Artikel über im Internet exponierte Server: Die Ausgabe 2026 des Verizon DBIR, aufgebaut auf über einer Milliarde Erkennungsdatensätze, misst einen Median von 43 Tagen bis zur vollständigen Behebung einer Schwachstelle aus dem CISA-Katalog aktiv ausgenutzter Schwachstellen, gegenüber zuvor 32, und nur 26% vollständig behoben, gegenüber zuvor 38%. Diesen Befund wiederholen wir hier nicht. Wir rechnen ihn durch.

Der Median verbirgt den entscheidenden Teil. Analysen derselben Daten zeigen, dass an Tag 7 zwischen 60% und 70% der aktiv ausgenutzten Schwachstellen noch offen sind — unabhängig vom Jahr, vom Volumen oder vom Reifegrad der Organisation; selbst im Bestfall schließen Organisationen 30-40% in der ersten Woche. An Tag 28 waren 2025 noch 35% der Fälle offen, gegenüber 27% im Jahr 2024. Und das Volumen wächst: im Medianfall 50% mehr kritische Schwachstellen als im Vorjahr. Auch der Rückstand summiert sich: In einer separaten Messung von Cyentia und Veracode tragen 82% der Organisationen bekannte Schwachstellen mit sich, die seit über einem Jahr ungelöst sind.

Dauer hat einen Preis, und es gibt eine Zahl, in der die Dauer die einzige Variable ist. Der IBM Cost of a Data Breach Report 2026 zeigt, dass Vorfälle, die erst nach mehr als 200 Tagen erkannt und eingedämmt wurden, im Durchschnitt 5,65 Millionen US-Dollar kosteten, gegenüber 4,32 Millionen bei schneller gelösten Fällen — eine Differenz von rund 1,33 Millionen. Der Abstand zwischen beiden Gruppen hat sich gegenüber dem Vorjahr vergrößert, nicht verringert.

Millionenbeträge klingen nach US-Konzern, und das zu Recht. Am nächsten an einem mittelständischen Unternehmen liegt die Sophos-Befragung The State of Ransomware 2026 mit 2.158 IT-Verantwortlichen aus 17 Ländern, in Unternehmen mit 100 bis 5.000 Beschäftigten, die von Ransomware getroffen wurden: Organisationen mit weniger als 50 Millionen US-Dollar Umsatz erhielten mediane Lösegeldforderungen von rund 140.000 US-Dollar, jene über 5 Milliarden 5,7 Millionen. Angreifer kalibrieren die Forderung an der vermuteten Zahlungsfähigkeit. Die durchschnittlichen Wiederherstellungskosten ohne Lösegeld lagen bei 1.700.200 US-Dollar — eine Größenordnung für diese Gruppe, keine Rechnung, die ein Betrieb mit 60 Beschäftigten erwarten muss.

Leichter zu spüren als das Geld ist die Wahrscheinlichkeit. In derselben Befragung wurden 41% der Angriffe vor der Verschlüsselung gestoppt — Unternehmen mit 3.001-5.000 Beschäftigten schaffen das aber in 46% der Fälle, jene mit 100-250 Beschäftigten nur in 34%. Der Bericht erklärt die zwölf Prozentpunkte Differenz nicht, aber sie übersetzen das Fenster von Geld in Wahrscheinlichkeit: Je später jemand hinsieht, desto häufiger kommt der Angriff bis zur Verschlüsselung. Und die Ursache liegt genau dort, wo das Fenster ist: exponierte Anwendungen und Systeme 38%, Firewall 21%.

Wo das Fenster konkret verloren geht, in einem Unternehmen, das nicht nachlässig ist:

• Die Meldung landet in einem Sammelpostfach und wird „an die IT" weitergeleitet, ohne Frist und ohne jemanden, der bestätigt, dass sie umgesetzt wurde.
• Die Korrektur braucht ein Wartungsfenster, das Fenster braucht die Zustimmung von jemandem aus dem Betrieb, und die Zustimmung verschiebt sich auf das nächste Wochenende — drei Wochenenden hintereinander.
• Das anfällige Gerät steht am Netzrand und wird vom Internetanbieter oder vom Integrator administriert, also fühlt sich niemand im Unternehmen als Eigentümer.
• Behoben wird, was einen hohen Score hat, weil ein hoher Score sich der Geschäftsführung leichter erklären lässt — und die Schwachstelle, die tatsächlich ausgenutzt wird, bleibt auf Platz elf.

Warum sich das Fenster nicht durch schnelleres Einstellen schließt

Der normale Reflex angesichts dieser Zahlen ist der Schluss, dass eine Person fehlt. Die Daten stützen diesen Schluss nicht. Das Cyentia Institute hat an rund 300 Organisationen die monatliche Schließungsrate von Schwachstellen gegen die Öffnungsrate modelliert und etwas unbequem Stabiles gefunden: Eine typische Organisation hat die Kapazität, etwa 1 von 10 Schwachstellen pro Monat in ihrer Umgebung zu beheben, und das scheint für große Unternehmen, kleine und alles dazwischen zu gelten. Behebungskapazität verhält sich wie eine Obergrenze, nicht wie eine lineare Funktion der Teamgröße.

Die Sophos-Befragung zeigt dasselbe aus anderer Richtung. Fehlende Leute oder Kapazität wird von Unternehmen mit 100-250 Beschäftigten massiv genannt, was niemanden überrascht; unerwartet ist, dass vier von zehn Organisationen mit 3.001-5.000 Beschäftigten es mit einer nur 3% niedrigeren Rate nennen. Ressourcen werden mit der Größe nicht zwangsläufig leichter. Und die am häufigsten genannte operative Ursache bleibt im zweiten Jahr in Folge „bekannte oder unbekannte Sicherheitslücken", mit 62%, vor fehlenden Leuten oder Kompetenzen mit 58%.

Ein weiteres Argument, aus Rumänien: Im Bericht für 2025 gibt das DNSC einen Stellenbesetzungsgrad von 17,69% an. Die nationale Behörde arbeitet mit weniger als einem Fünftel der vorgesehenen Stellen und hat dennoch 317.000 CVE-Einträge beobachtet, davon 121 unmittelbar nach Veröffentlichung im Detail analysiert. Sie hat das nicht durch mehr Einstellungen geschafft. Sie hat es durch Auswahl geschafft.

Das Problem ist nicht die Arbeitsmenge, sondern die Reihenfolge

Hier dreht sich die ganze Diskussion. FIRST.org, die Organisation hinter den EPSS-Scores, weist darauf hin, dass der KEV-Katalog der CISA rund 0,5% der veröffentlichten CVEs enthält und dass EPSS in einem beliebigen 30-Tage-Fenster bei etwa 2,5-3% von ihnen Ausnutzungsaktivität beobachtet. Die großzügigste Schätzung sagt, dass höchstens etwa 6% der veröffentlichten CVEs jemals in der freien Wildbahn ausgenutzt werden; strengere Datensätze deuten auf 1-2%. Von 35.364 im ersten Halbjahr 2026 veröffentlichten Schwachstellen waren zum Zeitpunkt einer unabhängigen Analyse nur 85 im KEV aufgetaucht — mit der berechtigten Einschränkung, dass KEV Monate hinterherläuft und nur bestätigte Ausnutzung erfasst.

Zusammen mit der Kapazitätsgrenze gelesen, dreht diese Zahl das Problem um. Wenn Sie ohnehin rund 10% Ihres Bestands pro Monat beheben und von den Schwachstellen in diesem Bestand nur einige Prozent jemals gegen Sie verwendet werden, dann haben Sie kein Mengenproblem. Sie haben ein Auswahlproblem. Das Unternehmen, das 10% pro Monat behebt und schlecht wählt, verliert; das Unternehmen, das genau dieselben 10% behebt und gut wählt, ist abgedeckt. Der Unterschied zwischen beiden ist keine zusätzliche Stelle.

Sie beheben nicht mehr. Sie beheben in einer anderen Reihenfolge — und diese Reihenfolge muss im Takt neu berechnet werden, in dem sich die Liste des Angreifers ändert, nicht im Takt des Quartalsberichts.

Dieser Takt ist nicht großzügig. VulnCheck hat an 884 Schwachstellen, die 2025 in den KEV-Katalog aufgenommen wurden, gemessen, dass 28,96% am Tag der CVE-Veröffentlichung oder davor Belege für Ausnutzung aufwiesen; im ersten Halbjahr 2026 waren es 23,43%. Die Ausgabe 2025 des DBIR maß auf Daten von 2024 einen Median von 5 Tagen bis zur massenhaften Ausnutzung einer KEV-Schwachstelle und null Tage bei Perimeter-Schwachstellen — eine Zahl aus der Vorausgabe, zu einem anderen Jahr, von der also nichts abgezogen wird. Bei knapp einer von vier Schwachstellen startet die Uhr des Angreifers ohnehin vor Ihrer.

Deshalb funktioniert die Priorisierung nach einem einzigen Kriterium nicht. Der CVSS-Score beschreibt, wie schlimm es wäre, wenn — nicht, wie wahrscheinlich es ist. Auch die Wahrscheinlichkeit allein genügt nicht: Im August 2026 hatten von 26 in den KEV-Katalog aufgenommenen Schwachstellen 18 einen EPSS-Wert unter 1%. Was funktioniert, ist eine Kombination aus fünf Kriterien: Schweregrad, Ausnutzungswahrscheinlichkeit, Präsenz auf der Liste bestätigter Ausnutzung, die tatsächliche Exposition des Dienstes und seine Kritikalität für das Geschäft. So entsteht die Situation, die einen Auditor erschreckt und trotzdem richtig ist: Eine Schwachstelle mittleren Schweregrads, aktiv ausgenutzt, auf einem zum Internet hin offenen Dienst geht einer nahezu maximalen Schwachstelle vor, die niemand ausnutzt, in einem internen Dienst.

Wie stark der Schwachstellen-Vektor gegenüber den anderen wiegt, klären die Quellen nicht: Der DBIR 2026 setzt ihn mit 31% der Vorfälle auf Platz eins; die Sophos-Befragung sieht ihn von 32% auf 18% fallen, hinter die bösartige E-Mail — sie fragt aber Betroffene, was sie für die Ursache halten, und ein Betrieb mit 150 Leuten erkennt eine E-Mail leichter als eine Schwachstelle, von der er nicht wusste. Die Zahlen sind untereinander nicht vergleichbar. Was nicht davon abhängt, welche Sie wählen: 59% der Lösegeldforderungen bei Angriffen, die von einer ausgenutzten Firewall-Schwachstelle ausgingen, liegen bei einer Million US-Dollar oder mehr, gegenüber 48% aller Forderungen. Ein seltenerer und teurerer Vektor ist kein Grund, ihn zu ignorieren.

Die Reihenfolge der Schritte, wenn Sie das Fenster verkürzen wollen

Nichts auf der folgenden Liste setzt ein Konzernbudget voraus. Sie setzt nur voraus, dass die Dinge in dieser Reihenfolge geschehen und nicht umgekehrt.

1. 1Erstellen Sie eine Bestandsaufnahme der tatsächlichen Exposition — was von außen wirklich auf eine Anfrage antwortet, nicht was jemand erinnert. Ohne sie erfolgt jede Priorisierung auf der falschen Karte.
2. 2Legen Sie fest, wer die Meldungen erhält — von der nationalen Behörde, vom Hersteller des Perimetergeräts, vom eigenen Scan — und schreiben Sie eine Reaktionsfrist dazu. Eine Meldung ohne Eigentümer und ohne Frist ist keine Meldung, sondern ein Archiv.
3. 3Priorisieren Sie nach den fünf Kriterien, nicht nach dem Schweregrad, und rechnen Sie häufig neu: Der CISA-Katalog aktiv ausgenutzter Schwachstellen hat allein im August 2026 26 neue Einträge erhalten, eine quartalsweise festgelegte Reihenfolge ist also schon alt, wenn Sie sie lesen.
4. 4Behandeln Sie den Perimeter separat und zuerst. Die ENISA beschreibt die Aktivität staatlich gestützter Gruppen 2025 genau über die anhaltende Ausnutzung von Perimeter-Infrastruktur, und der Versicherer Coalition zeigt an den 2024 gezahlten Schäden, dass 58% der Ransomware-Schäden von einem kompromittierten Perimetergerät ausgingen.
5. 5Wenn Sie die Korrektur jetzt nicht einspielen können — und manchmal können Sie nicht — schreiben Sie auf, was bis dahin an ihre Stelle tritt: Zugriff beschränkt auf die Quellen, die ihn brauchen, Monitoring auf dem betroffenen Dienst, ein Termin zur Wiederaufnahme. Ein bewusst offengehaltenes Fenster ist etwas anderes als ein vergessenes.
6. 6Führen Sie ein Protokoll der Entscheidungen: was behoben wurde, was verschoben, auf welcher Grundlage und von wem. Das ist das Einzige, was aus „wir hatten keine Zeit" ein „wir haben priorisiert, und so" macht.
7. 7Wenn Sie niemanden haben, der das wöchentlich tut, geben Sie die Beurteilung nach außen, nicht nur die Werkzeuge — einen Partner für Cybersicherheit, der auch die Entscheidung übernimmt und nicht bloß den Scan-Bericht liefert.

Was ein Produkt leistet, das den Server rund um die Uhr beobachtet

Die Produktklasse, die zu diesem Problem passt, ist kein Antivirus und kein SIEM. Sie ist deterministische Erkennung, die rund um die Uhr läuft, zu nahezu null Kosten pro Ereignis, plus eine modellbasierte Beurteilungsschicht, die nur bei dem gerufen wird, was einen Schwellenwert überschreitet — beides auf der Infrastruktur des Kunden. Die Erkennung rund um die Uhr hält die Prioritätenliste aktuell; die Beurteilungsschicht macht sie für jemanden lesbar, der kein Spezialist ist. Was ein Modell in der Triage kann und was nicht, haben wir im Artikel über die Triage von Sicherheitsmeldungen behandelt.

Sentinel, unser eigenes Produkt, ist eine konkrete Illustration dieser Klasse, und der nützlichste Weg, es in einem Artikel zu beschreiben, führt über das, was es nicht tut. Die Behebungspriorität wird aus Schweregrad, Ausnutzungswahrscheinlichkeit, Präsenz auf der CISA-Liste aktiv ausgenutzter Schwachstellen, Exposition und Kritikalität berechnet — genau die fünf Kriterien von oben — und der Reparaturplan wird Befehl für Befehl verfasst, mit Backup, Prüfungen und Rückkehrschritten. Aber es spielt ihn auf keiner kommerziellen Stufe selbst ein: Auf der Einstiegsstufe ist das Einspielen von Korrekturen ausdrücklich vom Leistungsumfang ausgeschlossen, auf der betreuten Stufe werden die vom Modell verfassten Pläne von uns geprüft, bevor sie den Kunden erreichen, und das Einspielen verlangt zwei ausdrückliche Bestätigungen am Telefon, mit einem Button, der stirbt, wenn der Plan neu erzeugt wird.

Klar gesagt, für jeden Käufer: Das Produkt schließt das Fenster nicht an Ihrer Stelle. Es macht es sichtbar, ordnet es richtig und legt Ihnen die Prozedur in die Hand; die Entscheidung, die Produktion fünf Minuten anzuhalten, um eine Korrektur einzuspielen, bleibt beim Unternehmen. Die Lücken sind ebenfalls deklariert: Logs aus Containern werden noch nicht gesammelt, es gibt über auditd hinaus keinen dedizierten Integritätsmonitor für Dateien, und die Installation auf Debian ist durch Tests abgedeckt, aber noch nicht auf einem echten Debian-Host verifiziert. Die drei kommerziellen Stufen sind „auf Anfrage" bepreist, weil es davon abhängt, wie viele Maschinen beteiligt sind und wie viel des Betriebs Sie selbst übernehmen.

Für die technische Prüfung: was Sie fragen, bevor Sie unterschreiben

Wenn Sie derjenige sind, der mit dem Produkt auf dem Server leben wird, dann drehen sich die Fragen, die zählen, nicht um Dashboards. Und sie lohnen sich bei jedem Anbieter dieser Klasse, nicht nur bei uns.

• Was genau gesammelt wird. Bei uns sind fünf Quellentypen öffentlich aufgeführt — sshd, sudo und su, nginx, auditd, Suricata. Verlangen Sie die Liste, nicht eine Zahl: Was nicht auf der Liste steht, wird nicht überwacht.
• Wie oft geschaut wird und nach welchen Regeln. Die Erkennung läuft deterministisch alle 10 Sekunden, auf veröffentlichten Schwellenwerten: SSH-Brute-Force bei 15 Fehlversuchen in 60 Sekunden, Web-Enumeration bei 200 nicht existierenden Pfaden in 5 Minuten. Ein Schwellenwert, den Sie nicht sehen dürfen, ist ein Schwellenwert, den Sie nicht kalibrieren können.
• Wie Vorfälle gezählt werden. Die Deduplizierung über Fingerprints macht aus 400 Versuchen von einer Adresse einen einzigen Vorfall, nicht 400. Ohne sie trainiert das erste Wochenende automatisierten Scannens Ihr Team darauf, Meldungen zu ignorieren.
• Was mit dem vom Modell verfassten Plan geschieht. Bei uns läuft er durch einen deterministischen Validator, der ihn ablehnt, wenn er nicht sicher ist: Das Modell verfasst, der Validator entscheidet. Der Befehl rm steht nicht auf der Liste erlaubter Binaries, und Löschen läuft über eine einzelne Operation, die auf das Backup-Verzeichnis beschränkt ist.
• Wie Logzeilen behandelt werden. Sie werden vom Angreifer geschrieben, sind also nicht vertrauenswürdige Daten: Sie erreichen das Modell mit ausdrücklichen Trennzeichen, der Transport, der Dateien liest, läuft im Permission-Mode plan, und ein Test platziert IGNORE PREVIOUS INSTRUCTIONS in einem Access-Log und prüft, dass nichts ausgeführt wurde. Eine erfolgreiche Injektion ändert ein Label, nicht das System.
• Was passiert, wenn das Produkt ausfällt. Die nftables-Grundregel ist policy accept, es ist also ein Deny-Lister, keine Firewall: Stirbt der Prozess oder ist die Konfiguration falsch, geht der Verkehr durch. Ein Sicherheitsprodukt, das Ihr Geschäft durch sein eigenes Versagen anhält, ist ein neues Problem.
• Wie die automatische Blockierung eingeschaltet wird. Bei uns existiert sie und ist getestet, wird aber deaktiviert ausgeliefert: Die ersten 72 Stunden zeigen nur, was blockiert worden wäre. Wer die Blockierung am ersten Tag in einem Netz einschaltet, das er noch nicht gesehen hat, verspricht Ihnen einen Verfügbarkeitsvorfall.

Fazit

Das Fenster zwischen dem Moment, in dem Sie von einer ungepatchten Schwachstelle erfahren, und dem Moment, in dem Sie sie behoben haben, schließt sich nicht durch mehr Arbeit, denn die Behebungsgrenze fällt in einem kleinen Betrieb ungefähr genauso aus wie in einem mit mehreren Tausend Beschäftigten. Es schließt sich durch bessere Auswahl, wöchentlich, aus einem Bestand, von dem nur einige Prozent jemals gegen Sie verwendet werden — und diese Auswahl braucht etwas, das Ihren Server im Takt des Angreifers beobachtet, nicht im Takt des Quartalsberichts. Wenn Sie gemeinsam sehen wollen, was Sie gerade exponiert haben und in welcher Reihenfolge es behoben werden sollte, sprechen wir 30 Minuten, ohne Verpflichtung.

Quellen

• DNSC — Jahresbericht 2025, genehmigt durch CSAT-Beschluss Nr. 117 vom 7. August 2026 (dnsc.ro)
• Verizon — Data Breach Investigations Report 2026, über eine Milliarde Erkennungsdatensätze, mit Analysen von Tenable, Nucleus Security und Qualys; Ausgabe 2025 desselben Berichts, über die GreyNoise-Analyse
• Cyentia Institute — „Patching, Fast and Slow" (cyentia.com); Cyentia / Veracode — 2026 State of Software Security
• Sophos — The State of Ransomware 2026, 2.158 IT-Verantwortliche, 17 Länder, Unternehmen mit 100-5.000 Beschäftigten (sophos.com)
• IBM — Cost of a Data Breach Report 2026, Untersuchung des Ponemon Institute (ibm.com/reports)
• FIRST.org — EPSS-FAQ und EPSS-Dokumentation (first.org/epss)
• VulnCheck — State of Exploitation 2026 und 1H-2026 (vulncheck.com)
• ENISA — Threat Landscape 2026, 8.257 Vorfälle aus 2025 (enisa.europa.eu)
• Coalition — Cyber Threat Index 2025, auf Basis vom Versicherer gezahlter Schäden (coalitioninc.com)
• Jerry Gamblin — CVE Mid-Year 2026 Check-In (jerrygamblin.com); isMalicious — KEV- und EPSS-Analyse, August 2026 (ismalicious.com)
• CryptoITData — Sentinel, Produktdokumentation und öffentlich erklärte Grenzen (cryptoitdata.eu/sentinel)