Vorwort: Diesen Blogpost habe ich, wie schon den letzten, gemeinsam mit Microsoft Copilot Cowork erstellt. Ich habe ihn (mal wieder) angewiesen, sich an meinen anderen Artikeln zu orientieren und mich zu imitieren — das Ergebnis siehst du hier. Wie immer mit Feinschliff von mir und dem Hinweis, dass die folgenden Gedanken meine eigenen sind und nichts, was Copilot frei phantasiert hat.
Stell dir mal kurz vor, du steckst in einer Zeitschleife fest. Jedes Mal, wenn du scheiterst, spult die Welt zurück auf Anfang. Du darfst es nochmal versuchen, ein bisschen klüger, ein bisschen schneller, ein bisschen besser vorbereitet — so lange, bis du irgendwann gewinnst. Schöne Idee für einen Kinosaal. Im echten Cyber-Alltag gibt es diese Schleife nicht. Dort gilt: Live. Patch. Repeat. Das „Die“ dazwischen ist gestrichen, weil wir es uns schlicht nicht leisten können. Wir haben keine zweite Chance!
Vor zwei Wochen habe ich hier über die Defender-Familie geschrieben — wer reingehört… ähm, reingelesen hat, weiß: Defender, Microsoft Defender — und was Q sonst noch zu bieten hat(opens in new window). Ich habe dort versucht aufzuräumen, was bei dem Begriff „Defender“ alles durcheinander geht und welcher Defender wofür eigentlich gedacht ist. Heute möchte ich einen Schritt zurücktreten und über die Frage sprechen, die hinter all dem steht: Was schützt du da eigentlich — und wie viel Zeit hast du noch, das gescheit aufzustellen?
Spoiler: weniger, als du denkst.
Inhaltsverzeichnis
- Warum die Frage „Was war in den letzten zwei Jahren?“ gerade die falsche ist
- Machine-Speed: das wahre Problem hinter „AI in Cyber“
- Die neue Pflicht: ein Patchprozess, der Maschinen-Tempo mithält
- Wenn der Patch selbst zum Problem wird — Rollback ist kein Luxus mehr
- Wenn Patchen nicht (mehr) reicht — Sensorik, Containment, Notausgang
- NIS2, DORA & Co. — der regulatorische Rückenwind, den du gerade brauchst
- Fazit
Warum die Frage „Was war in den letzten zwei Jahren?“ gerade die falsche ist
Wenn ich in Kundengesprächen über Bedrohungslagen rede, läuft das immer noch oft nach dem gleichen Muster ab: Es gibt einen Rückblick. „Was war denn so an Vorfällen?“, „Welche Branchen wurden getroffen?“, „Wie sind die Angreifer reingekommen?“ — und daraus wird dann abgeleitet, was zu tun ist. Das ist nicht falsch — aber es ist gefährlich unvollständig.
Denn diese Herangehensweise unterstellt, dass die nächsten zwei Jahre ungefähr so aussehen wie die letzten zwei. Und genau das ist die Annahme, die gerade in atemberaubender Geschwindigkeit zerbröselt.
Die Welt, in der ein Angreifer Wochen oder Monate damit verbracht hat, in einer Software eine Schwachstelle zu finden, ist nicht weg — aber sie bekommt gerade einen sehr unangenehmen Beifahrer: eine spezialisierte KI, die das in Minuten oder Stunden tut. Tools wie Anthropic Mythos, GPT5.4 Cyber und ihre Geschwister sind keine Spielzeuge mehr — und sie werden, anders als noch vor einem Jahr, ganz offen für genau diese Zwecke entwickelt und eingesetzt. Auf beiden Seiten. Das ist die unangenehme Wahrheit.
Was das im Übrigen für den Umgang mit GenAI in deinem eigenen Unternehmen bedeutet — also auf welcher Seite des Werkzeugs deine Mitarbeitenden gerade stehen und wie du das steuerst — darüber habe ich schon mal ausführlich geschrieben: One Size fits all! Oder auch nicht! — Ausgeklügelter Umgang mit Firmendaten und GenAI Diensten(opens in new window). Lies das gerne als Vorgeschichte zu dem, was hier folgt.
Machine-Speed: das wahre Problem hinter „AI in Cyber“
Ja, ich höre den Einwand schon: „Aber die KIs finden doch am Anfang viel Mist.“ Stimmt. Tun sie. Und das werden sie noch eine Weile.
Nur — und das ist der entscheidende Punkt — ist „eine Weile“ in der KI-Welt eben kein Jahrzehnt mehr. Eher ein Quartal. Vielleicht zwei. Wer die letzten 24 Monate aufmerksam verfolgt hat, weiß, wie absurd schnell sich diese Modelle entwickeln. Was im Januar noch „interessant, aber nicht produktionsreif“ war, ist im Juli schon Standardwerkzeug. Wer also glaubt, dass die heutigen False Positives in KI-gestützter Schwachstellenanalyse ein dauerhaftes Sicherheitsnetz sind, hat den Kern der Sache nicht verstanden.
Das eigentliche Problem ist nicht, dass die KI Zero-Days findet. Das eigentliche Problem ist die Geschwindigkeit, mit der sie es bald tun wird. Was heute noch ein Wettlauf zwischen Forschern, Herstellern und Angreifern ist, in dem alle drei in halbwegs vergleichbarem Tempo unterwegs sind, wird bald zu einem Wettlauf, bei dem zwei der drei Beteiligten plötzlich eine Maschine ans Rennen anschließen. Und du darfst gerne raten, welche zwei das sein werden.
Die Rate an neuen Zero-Days wird also nicht linear, sondern exponentiell steigen. Punkt.
Und genau hier wird aus einem akademischen Problem ein sehr handfestes operatives: Wenn die Bedrohung zehnmal schneller wird, muss die Verteidigung das auch. Sonst wird die Lücke größer, nicht kleiner.
Die neue Pflicht: ein Patchprozess, der Maschinen-Tempo mithält
Hier wird es jetzt unangenehm — vor allem für IT-Organisationen, die seit Jahren mit dem Argument „Patchen ist heikel, das muss in Ruhe geplant werden“ arbeiten. Das war nie ganz falsch. Aber es ist eben auch nicht mehr ausreichend.
Wenn der Abstand zwischen „Schwachstelle bekannt“ und „Schwachstelle ausgenutzt“ auf Stunden zusammenschrumpft — und das ist der Trend, nicht eine Hypothese — dann brauchst du einen Patchprozess, der nicht in Tagen, sondern in Stunden denkt. Idealerweise vollautomatisiert. Idealerweise jetzt, nicht „mittelfristig im Roadmap-Quartal Q3″ oder „wenn die nächste, geplante Down-Time ansteht“.
Was das in der Praxis bedeutet, lässt sich gut auf drei Bausteine herunterbrechen — und die Microsoft-Welt bietet für jeden davon ein passendes Werkzeug:
a) Du musst wissen, welche Maschinen betroffen sind. Das klingt trivial, ist es aber bemerkenswert oft nicht. Vulnerability Management mit Microsoft Defender for Endpoint ist hier das Mittel der Wahl für die Clients und alles, was eine MDE-Lizenz hat. Für Server — egal ob on-prem, in Azure, AWS oder GCP — kommt Azure Arc ins Spiel, das deine Server in dieselbe Sichtbarkeit hebt und damit auch ins Vulnerability Management einbindet. Wer hier keine durchgängige Inventarisierung hat, jagt im Vorfall buchstäblich blind durch sein eigenes Rechenzentrum. Und das ist im Jahr 2026 keine entschuldbare Position mehr!
b) Du musst patchen können. Und zwar schnell. Idealerweise in eng aufeinander folgenden Wellen, idealerweise automatisiert, idealerweise mit klaren Telemetriedaten zu jedem Schritt. Das alte Modell „Wir testen erst zwei Wochen in der Pilotgruppe, dann zwei Wochen Wave 1, dann…“ wird in einer Welt, in der ein Exploit innerhalb von 48 Stunden in jedem Crimeware-Kit landet, schlicht zur Risikomaximierung. Das heißt nicht, dass du Tests abschaffen sollst — es heißt, dass die Zeitachsen drastisch nach unten korrigiert werden müssen.
Wenn der Patch selbst zum Problem wird — Rollback ist kein Luxus mehr
Und damit zum Punkt, an dem viele Organisationen reflexhaft das Bremspedal treten: „Was, wenn der Patch kaputt ist?“
Berechtigte Frage. Aber die Antwort ist nicht „Dann patchen wir lieber später“, sondern „Dann müssen wir den Rollback genauso automatisieren wie das Patchen selbst.“ Das ist der gedankliche Switch, den viele noch nicht vollzogen haben. Oder, wie ich es in Workshops gerne knapper sage:
„Es gibt keinen Grund, nicht zu patchen!“
Und ich meine das genau so absolut, wie es dort steht. Das Risiko, durch einen Patch ein System kaputtzumachen, ist immer kleiner als das Risiko, durch das Nicht-Patchen ein System zu verlieren. Punkt. Ausrufezeichen! Voraussetzung ist nur, dass du die richtigen Mechanismen drumherum hast: einen defekten Patch oder ein zickendes System bekommst du mit einem automatisierten Rollback in Minuten wieder geradegezogen — einfacher, schneller, billiger und nervenschonender, als mit einem aktiv gehackten System umzugehen, das du im Zweifel forensisch komplett aufmachen, neu aufsetzen und der Geschäftsführung erklären darfst. Das eine kostet dich eine schlechte Stunde. Das andere kostet dich Wochen, Geld, Reputation — und im Zweifel ein paar Jobs oder das gesamte Business.
Wer schnell ausrollen will — und muss — braucht also zwingend einen ebenso schnellen und ebenso automatisierten Weg, das Ganze wieder rückgängig zu machen, wenn ein Patch sich als problematisch erweist. Ohne Telefon-Eskalation um halb drei nachts. Ohne „Können wir bitte ein Change Advisory Board einberufen?“. Sondern als Teil des Prozesses, klar definiert und vorab getestet.
Klingt anstrengend? Ja. Ist es. Aber die Alternative ist eben, dass du gar nicht schnell patchst — und das ist das Risiko, mit dem du dich gerade nicht mehr arrangieren kannst. Business Continuity bedeutet 2026 nicht mehr „Wir haben ein DR-Konzept im Tresor liegen“, sondern „Wir können in Echtzeit Schaden begrenzen — auch den, den wir uns selbst zufügen.“
Oder wie ich auch gerne frage:
„Wie patcht Microsoft eigentlich die eigenen Server/Services?“
Und die Antwort darauf ist: gar nicht! Ja, richtig gelesen: gar nicht! Denn das ist schlicht zu teuer und zu aufwändig! Microsoft geht anders vor:
Sagen wir von einem Service gibt es 1000 (schöne runde Zahl, vermutlich meistens viel zu klein) Server. Jetzt gibt es eine neue Version. Dann werden einfach z.B. 200 (=20%) weitere Server mit dem neuen Patch stand in den Service gehängt. Dann werden 200 alte heruntergefahren und die freigewordenen Kapazitäten werden wiederum mit dem neuen Stand gestartet und eingehängt, bis der komplette Service auf der neuen Version läuft. Dazu müssen die Services/Applikationen dieses Vorgehen – unterschiedliche API Versionen, kurze Unterbrechung bei der Erreichbarkeit einzelner Einheiten, Routing, etc. – unterstützen und ja, mir ist klar, dass das Zeit braucht. ABER das ist nix Neues! Das Predige ich seit vielen Jahren – denn so geht Cloud – jetzt wäre ein guter Zeitpunkt endlich damit anzufangen!
Wenn Patchen nicht (mehr) reicht — Sensorik, Containment, Notausgang
So gut der schnellste Patchprozess auch ist: Er hilft dir nicht gegen das, was du nicht kennst. Und genau hier kommen die zwei Themen ins Spiel, die in den nächsten Jahren noch wichtiger werden, als sie es ohnehin schon sind.
Sensorik und Detektion. Wenn die nächste Welle an Angriffen über Schwachstellen läuft, die zum Zeitpunkt des Angriffs schlicht noch nicht bekannt sind — und das ist die unangenehme Eigenheit von Zero-Days nun mal — dann brauchst du Detektion auf Verhaltensebene. Nicht „Hat hier jemand eine bekannte Malware-Signatur reingeschmuggelt?“, sondern „Verhält sich diese Maschine, dieser Account, dieser Prozess gerade anders, als er sollte?“. Genau das ist die Domäne von echtem EDR/XDR mit Auto-IR — und genau hier liegt der Wert von Defender for Endpoint Plan 2, gepaart mit Defender for Identity (für alles, was AD/Entra ist) und Defender for Cloud Apps (für alles, was SaaS ist). Wer da nur „den AV in Windows“ hat — ich verweise nochmal höflich auf den Defender-Artikel — spielt nicht im selben Stadion. Und warum reaktiver Schutz heute schlicht nicht mehr ausreicht, habe ich vor einer Weile mal in Kein Mitleid mit Ransomware ausführlich auseinandergenommen — der Artikel ist ein paar Jahre alt, aber leider in seiner Kernbotschaft noch immer aktuell. Eher noch aktueller.
Containment. Erkennen allein bringt dich nicht weit, wenn du danach drei Stunden brauchst, um zu reagieren. Was du brauchst, ist die Fähigkeit, einen laufenden Angriff früh zu unterbrechen oder zumindest einzuhegen — automatisch, ohne dass jemand erst ein Ticket öffnet. Auto-IR in MDE Plan 2 ist hier das Stichwort, ebenso wie automatische Disruption in Defender XDR, die mittlerweile Identitäten kompromittieren, Sessions terminieren und Geräte isolieren kann, ohne dass ein menschlicher Analyst dazwischen sitzen muss. Das hat vor zwei Jahren noch nach „spannender Marketingfolie“ geklungen — heute ist es Hygiene.
Apropos Identitäten: Wenn deine Angreifer in deinem AD spazieren gehen, hilft dir auch der beste Patchprozess auf den Clients herzlich wenig. Genau deshalb gehört Defender for Identity zwingend mit ins Bild — und genau deshalb solltest du dir die alten Authentifizierungs-Schwergewichte in deinem Netz dringend anschauen. Ich habe das vor Kurzem am konkreten Beispiel durchexerziert: NTLM: Der Zombie im Windows-Netzwerk — wie du ihn jagst und endgültig tötest. Wer NTLM noch im Netz hat und es nicht weiß, hat genau das Sichtbarkeitsproblem, das ich oben meine.
Und der Notausgang für die, die du nicht patchen kannst. Es wird sie immer geben: die OT-Steuerung, die nur mit einer bestimmten Windows-Version läuft. Den Spezial-Server mit der Software, deren Hersteller seit 2018 nicht mehr erreichbar ist. Die Maschine, die du nicht einfach neu starten kannst, weil daran ein 24/7-Prozess hängt. Für diese Systeme brauchst du eine andere Antwort als Patchen — nämlich besonders engmaschige Überwachung, harte Netzwerksegmentierung, Mikrosegmentierung wo möglich, und kompensierende Kontrollen, die das Risiko aktiv senken. Aber bitte: keine Schweigen-im-Walde-Strategie. Genau diese Systeme sind in den nächsten zwei Jahren das attraktivste Angriffsziel!
NIS2, DORA & Co. — der regulatorische Rückenwind, den du gerade brauchst
Und falls du jetzt denkst „Schön und gut, aber wie verkaufe ich das intern?“ — da hilft dir der Gesetzgeber gerade tatkräftig.
NIS2 ist in Deutschland angekommen, DORA ist für die Finanzwelt seit Anfang 2025 scharf, und der gemeinsame Tenor dieser Regulierungen ist genau das, worüber wir hier reden: Du musst wissen, was du hast. Du musst nachweisen können, dass du patchst. Du musst Vorfälle erkennen und melden. Du musst Business Continuity sicherstellen. Die Anforderungen sind im Detail unterschiedlich, aber die Richtung ist eindeutig — und sie deckt sich praktisch eins zu eins mit dem, was die Bedrohungslage technisch ohnehin von dir verlangt.
Das ist ehrlich gesagt eine seltene Win-Win-Situation. Was du tun musst, ist genau das, was du tun solltest. Selten so kongruent gewesen.
Fazit
Wenn ich diesen Artikel auf einen Satz eindampfen müsste, dann diesen: Die alte Frage „Wie schütze ich mich vor dem, was war?“ wird gerade von der Frage „Wie schütze ich mich vor dem, was kommt?“ überholt — und die Antwort darauf ist nicht „mehr vom Gleichen“, sondern „grundlegend anders aufgestellt sein“.
Konkret heißt das aus meiner Sicht:
- Inventarisiere ehrlich. Mit MDE für Clients und lokale IoT Geräte/Drucker, mit Azure Arc für Server. Wer nicht weiß, was er hat, kann es nicht schützen.
- Automatisiere das Patchen. Und dann automatisiere auch den Rollback. Beides gehört zusammen.
- Setze auf echte EDR/XDR-Fähigkeiten mit automatisierter Reaktion — nicht „wir haben den Defender“ im Sinne von „den AV“. Sondern den richtigen Defender, im richtigen Plan, korrekt konfiguriert.
- Mikrosegmentiere und überwache, was du nicht patchen kannst, statt es zu ignorieren.
- Nutze NIS2/DORA als Hebel, nicht als Belastung. Du musst es ohnehin tun. Du darfst es jetzt sogar.
Was sich gerade ändert, ist nicht nur die Bedrohung — es ist die Halbwertszeit deiner Sicherheitsstrategie. Wer heute aufstellt, was vor zwei Jahren modern war, ist morgen offen. Und „morgen“ meine ich, in dieser Branche, durchaus wörtlich.
Wir kriegen keinen Reset. Keine zweite Chance. Kein „beim nächsten Versuch klappt’s bestimmt“. Also: Live. Patch. Repeat. Und zwar schnell genug, dass das „Die“ dazwischen wirklich gestrichen bleibt.