Der Einsatz von künstlicher Intelligenz verändert die IT-Landschaft gravierend. Microsoft hat sich daher einige Gedanken im Hinblick auf die Frage, wie sich dies auf den Zeitraum zum Einspielen von Sicherheitsupdates auswirkt, gemacht. In einem Beitrag will Redmond IT-Supportern Hinweise, wie sich das alles auf das Thema Updates auswirkt, in Form von Update-Strategien an die Hand geben.
KI-gestützte Softwareanalyse zur Entdeckung von Schwachstellen legt oft hunderte an Sicherheitslücken offen. Bei Google Chrome werden pro Update mehrere Hundert Schwachstellen beseitigt (was dann auch den Edge-Browser trifft), und auch beim Microsoft Patchday am zweiten Dienstag eines Monats heißt es schon mal 180 CVEs geschlossen, davon 10 kritisch. Da auch Angreifer sehr genau auf diese Updates schauen und selbst KI zum Finden von Schwachstellen verwenden, trägt der alte Ansatz "ich warte mal einen Monat ab, bis ich patche" eventuell nicht mehr.
Microsoft zu Update-Installationszyklen in KI-Zeiten
Genau in diesem Kontext hat Microsoft zum 8. Juli 2026 den Techcommunity-Beitrag Deploy Windows updates to counter AI-discovered threats für IT-Mitarbeiter in Unternehmen veröffentlicht (via). Angesichts der Geschwindigkeit, mit der KI mittlerweile Schwachstellen aufspüren und ausnutzen kann, müssen auch die Abwehrmaßnahmen angepasst werden, lautet die Botschaft.
Zum Abspielen des Videos klicken
Für Geräte mit Windows, bei denen die Bereitstellungsfristen zur Installation von Updates verkürzt werden können, erläutert Microsoft 365 Director Jeremy Chapman wie Kunden die Patch-Installation beschleunigen können.
- Zunächst sollten die IT-Verantwortlichen mithilfe des neuen Autopatch-Berichts in Microsoft Intune das Risiko durch nicht gepatchte Geräte ermitteln (was sinnvoll klingt).
- Anschließend sollten die Kriterien, wie schnell Sicherheitsupdates installiert werden, angepasst werden (Microsoft bezeichnet dies als "Verschärfung der Aufschubrichtlinien für die Geräte, bei denen dies sinnvoll ist).
- Weiterhin könnten Administratoren die Hotpatch-Funktion in Windows aktivieren, so dass die Sicherheitsupdates ohne Neustart installiert werden können (bei Servern sinvoll).
Windows Autopatch automatisiert zudem die Update-Bereitstellungen mithilfe von Ringen, um Updates schrittweise auf die von definierten Gerätegruppen anzuwenden, argumentiert Microsoft. Das schließt Updates für Windows, Microsoft 365-Apps und den Edge-Browser ein. Und um interne Ressourcen zu schützen, können Administratoren mithilfe von "Conditional Access" Zugriffskontrollen durchsetzen. Dies ermöglicht Administratoren nicht konforme Geräte bei der Update-Verteilung zu blockieren.
Ich hätte Fragen …
Jeremy Chapman gibt im Beitrag einige Hinweise und erläutert in einem YouTube-Video die Vorstellungen Microsofts. In der Theorie klingen die Vorschläge alle gut, aber die Krux liegt in der Einstufung der Geräte, der Implementierung der Update-Zyklen etc., die letztendlich vom IT-Personal getroffen werden muss.
Beim Schreiben des Beitrags habe ich mich spontan gefragt, wie viele Systeme wirklich gefährdet sind, weil ein Update auf einem Server erst "Tage später" wegen des anstehenden Neustarts installiert werden kann?
Das größte Problem, was ich sehe, ist bei Microsoft doch seit Jahren die sich immer wieder stellende Frage: "Was geht beim aktuellen Update wieder kaputt und was funktioniert noch"? Die IT muss halbwegs sicher sein, dass eine Update-Verteilung nicht die halbe IT der Firma lahm legt, weil Microsoft zwischen AI-Entwicklung, Featuritis-Wahn und Aktualisierungszyklen seiner Software die Updates nicht mehr in den Griff bekommt. Ein Known Issues Rollback (KIR) ist schön und gut, kommt aber oft viel zu spät, "wenn das Kind schon in den Brunnen gefallen ist". Wie seht ihr diesen gesamten Themenkomplex, bzw. wie geht ihr damit um?
MVP: 2013 – 2016
Die Patch Qualität wird immer schlechter. Also bist gefangen zwischen Security Problemen oder der Benutzer kann nicht arbeiten.
Microsoft sollte sich lieber mal um die Patch Qualität kümmern.
Wenn der Nutzer nicht arbeiten kann, weil das System nicht bootet, dann ist es doch automatisch sicher. Win Win.
Aber Du hast den Finger genau drauf. Es steht tatsächlich die Frage was weniger kostet. Der Ausfall durch Sicherheitsprobleme oder durch Microsofts Patchpolitik.
Bis auf wenige Ausnahmen finde ich eigentlich, dass die Update-Qualität durchaus (wieder) zugenommen hat. Man liest zwar immer wieder von Fällen, wo was schief ging, aber an mir/uns (also meine Firma) ist dieser Kelch die letzten Jahren zum Glück immer vorbei gegangen, klopf, klopf, klopf (auf Holz).
Was vielleicht Betroffenen helfen könnte, wäre ein besseres Patchmangement für Dritt-Software und Treiber, denn oft ist nicht Windows/Microsoft schuld, sondern irgend ein nicht aktualisierter Krempel, der sonst noch so installiert ist. Dazu gehört auch, vor dem Einsatz von neuer Software / Hardware (Treiber!) zu prüfen, wie oft es da Updates gibt, und das in seinen Genehmigungsprozess einfließen lässt. Den ganzen Softwarezoo muss man eh in Grenzen halten, muss es bei den Mitarbeitern 5 verschiedene Text- oder Hex-Editoren, drölf verschiedene Grafikprogramme, 7 verschiedene Druckerhersteller mit unterschiedlichen Treibern, usw. geben, auch das hilft bei der Fehlervermeidung!
Ja, was helfen könnte wäre endlich wieder Sicherheits- und Featureupdates zu trennen. Aber MS möchte natürlich extra Geld für stabilere Versionen von Windows.
Nicht gepatchte Geräte sehe ich hier im WSUS sofort.
Dazu brauche ich kein Intune.
Und was Hotpatching angeht:
Das ist eine gute Idee, aber Microsoft sollte das auch für OnPrem anbieten.
Es kann nicht sein, das man nur für so eine Funktion Intune und Lizenzen für Windows 11 Enterprise E3 oder E5, Microsoft 365 F3, Windows 11 Education A3 oder A5, Microsoft 365 Business Premium oder Windows 365 Enterprise braucht bzw. für Server 2025 Azure braucht.
Microsoft will wohl so die Firmen in die Cloud drängen.
Hinzu kommt, das das kein echtes Hotpatching ist, denn alle 3 Monate braucht es eben doch einen Neustart des Systems.
Früher, als es noch nicht diese kommulativen Updates gab, waren die Updates sehr sehr deutlich kleiner und es gab jede Menge Updates, die keinen Neustart des Systems benötigten.
Und wenn ich mein System monatlich patche, brauche ich kein kommulitatives Update, das Patches beinhaltet, die schon in vorherigen kummulativen Updates enthalten waren. Warum soll man die noch einmal herunterladen?
Imhowäre die richtige Strategie:
Wie früher einzelne Updates und nur, wenn das Gerät längere Zeit oder noch nie Updates bekommen hat, ein kommulitatives Update, das das System auf den aktuellen Stand bringt.
Das würde die Downloads sehr deutlich verkleinern und die Patchinstallation beschleunigen.
Dem kann ich nur beipflichten. Falls es MS wirklich um die Sicherheit ginge, würden sie diese Mechanismen nicht an optionale kostenpflichtige Services hängen.
Also meines Erachtens kann man weiterhin im WSUS die "Express Installation Files" zusätzlich laden, falls man nicht kumulativ patchen möchte. Habe ich nie gemacht, weil das unendlich Speicherplatz (auf dem WSUS) benötigt. Aber die einzelnen Clients sollten dadurch sehr viel schlanker betankt werden können.
Es war ja immer so, wer die Lücke zuerst findet, kann sie patchen oder ausnutzen. Vielleicht sollte man da eher von 0-Hour als von 0-Day sprechen?
Trotzdem: Meine Hoffnung ist, dass MS durch massiven Einsatz von KI die eigenen Fehler schneller patcht ehe andere es ausnutzen können. Wenn man das zu Ende denkt, müssten alle Patches unmittelbar installiert werden. Täglich.
Auf meinen Linux-Mint Rechnern gibt er mehrere, meist sehr kleine Updates pro Woche.
Vor allem sind diese Updates bei Mint sehr stabil und das ist enorm viel wert – besonders für die Nerven.
Allerdings muss man bei Kernel Updates auch rebooten. Außerdem werden die Apps bei Mint nicht neu gestartet, die offen waren. Auch der Editor xed (heißt er glaub ich?) merkt sich einfach nicht, welche Dokumente offen waren. Also auch da gäbe es noch potential für Verbesserung. Aber das wichtigste haben sie viel besser im Griff.
Also bevor sie da wieder tolle Regeln für die Kunden aufstellen, sollten sie:
1. Alle Entwicklungen aussetzen und die Teams aktuell auf Security Themen ansetzen
2. Sie laufen security-technisch ständig allem nach: sie sollten eben bevor sie Updates und neue Features herausgeben, diese auf Security Themen testen (auch mit KI). Eventuell externe Fachleute einbinden und so ihr Bug Bounty Programm erneuern. Themen sollen getestet werden bevor sie Produktiv gehen.
3. Meldungen zu Lücken und Bug sollten sie ernst nehmen und offen gegenüberstehen – nicht abblocken und den Kopf in den Sand stecken.
4. Schlussendlich sollten sie sich auf die Nase schreiben, dass Security auch ein Feature sein kann. Es müssen nicht immer bunte neue Icons – oder ein weiterer Copilot in einer weitern App sein.
Ich bin der Meinung, dass sie sich wieder darauf besinnen sollten, was ein BS im eigentlichen Sinne ist!
Sie sollten Windows ausmisten und alle Anwendungen und Features rausschmeißen, die gar nicht erforderlich für einen sicheren Betrieb sind!
Dann, wenn das System wieder schlank und gut wartbar ist, den Fokus auf Sicherheit legen und wenn nötig
eben alle 14 Tage ein Sicherheitspatch rausbringen.
Sie können ja, so alle 2 Monate dann einen "Sammelpatch" veröffentlichen.
Alles, was bisher so ins System gefrickelt wurde, können sie ja weiter entwickeln, aber bitte optional
und eben ganz separat und nicht wieder ins System frickeln, sodass eine Deinstallation unmöglich wird.
Ja selbst der Edge müsste nicht ins System verwoben werden!
Denn auch heute braucht es für Updates auch den Edge nicht!
Somit könnte auch ein Browser ganz normal, wie alle andere Software installiert werden,
halt wie andere Browser eben auch.
Aber das wäre ja nur ein Traum.
Der Weg, den Microsoft gehen wird, wird ein anderer sein.
Alles in die Cloud und möglichst volle Kontrolle, damit der Kunde gemolken werden kann.
meine Worte… ein OS hat ein OS hat ein OS zu sein und keine Eierlegende Wollmilchsau! Dann klappts auch mit der Sicherheit. Software die ich brauche, da sorg ich mich schon selbst drum! Darf mir MS ja auch gerne anbieten, aber eben optional… und dies dann auch akzeptieren.
Naja man muss aber auch klar sehen ja KI findet hunderte von Lücken… davon sind aber auch hunderte irrelevant da nur direkt vor Ort ausnutzbar und das auch noch nur wenn die IT schläft! Saubere Segmentierung; Zero Trust und Maschinen die nur die Rechte und Zugriffe haben die sie tatsächlich für ihre Aufgaben brauchen und den HTML Müll außen vor lassen und du kannst dich entspannt mit Popcorn zurücklehnen!
All den "HTML Müll" brauchen sie aber, um letztendlich das gesamte OS und alle Daten komplett in die Cloud zu verfrachten, das ist der finale Plan. Lokal gibt es dann nur noch Thin Clients mit irgendeinem kleinen vernagelten Bootstrap mit Digitaler Identität als alternativlosem Zugang.
Das wäre auch für mich als End-Verbraucher zu Hause sehr schön.
Wann lernen Firmen, dass nicht alles ständig am Internet hängen müsste und man durch passende Segmentierung bei so einigen Gerätschaften auch aus dem Dauerupdate-Zug aussteigen könnte?
Ach so, das geht ja nicht, weil man sich überall mit irgendwelchen externen Onlinedienstleistern, extern gehostete Dashboards, externem Monitoring, eigentlich unnötigen Cloudkram, ständigen online Lizenzprüfungen usw. total von "muss online sein" abhängig gemacht hat?
Hier vielleicht mal ansetzen bei Überlegungen.
Die IT wäre einfach, wenn sie nur der Bedarfe der IT erfüllen müsste. Ist halt nicht die Realität.
Schneller patchen ist möglich, wenn Microsoft die Qualität wieder in den Griff bekommt. Wenn nicht, bleibt das Dilemma zwischen Betriebsunterbruch wegen Hack oder Betriebsunterbruch wegen broken Software bestehen.
Unsere Strategie:
Ab dem Patchday in Borns Blog die Kommentare zu den Update-Beiträgen lesen und wenn möglich selber möglichst zeitnah einige Server und Client patchen (nicht gerade die Mission Critical Server, muss man jedoch jeweils von Monat zu Monat beurteilen, je nachdem was für 0-Day da lauern). Auffälligkeiten bei Born posten.
Danach, wenn bei Born und anderen Quellen sich keine Katastrophen-Meldungen häufen, die Server möglichst zeitnah, nach 1-2 Tagen, jene mit Zugriff aus dem Internet zuerst (IIS, Mail usw.) patchen.
Die Client werden im Normalfall nach 11 Tagen gepatcht (2. Wochenende nach dem Patchday). Wenn es die Lage erfordert auch früher. Sollte es Microsoft mit der Patch-Qualität hinbekommen wird das in Zukunft das 1. Wochenende nach dem Patchday sein. Browser werden sofort und automatisch mit den im Produkt enthaltenen Autoupdate-Funktionen aktuell gehalten.
Patch-Management benötigt aktuell viel mehr Ressourcen als früher, trotz Automatisierung. Release-Notes lesen, testen usw. Mag mich an die Jahre 2014-2019 erinnern. Da konnte man auf Server 2012 R2 die Patches ungeprüft installieren und es knallte in 5 Jahren vielleicht einmal. Das ist für mich ein akzeptables Qualitätsziel. Allerdings hat sich die Komplexität der IT-Landschaften in den letzten Jahren exponentiell entwickelt. Wir müssen möglicherweise akzeptieren, dass dies ein Zielkonflikt zu Rundum Sorglos Patchen ist.
Und ja, zurück zu den einzelnen Patches würde die Möglichkeit bieten alles, ausser dem broken Patch zu installieren. Vermutlich aber eine Utopie wegen der vielen Abhängigkeiten. Schon zu Zeiten von NT4 ging das manchmal in die Hose und hat Microsoft letztendlich zur Umstellung auf kumulative Patch gebracht wo dann allenfalls per KIR Funktionen ausgeschaltet werden können.
Und zwischen den Microsoft-Patchdays gibt es ja noch vieles anderes zu patchen, Firewall, Switches, Virtualisierungs-Hosts, Applikationen und neuerdings auch alle Wochen mal Linux. Nur so angemerkt, falls mal jemand fragt was die IT die ganze Zeit macht … :D
Bei uns kommt dann bei bestimmten Systemen noch das Abwarten der Freigabe durch DATEV dazu. Die brauchen in der Regel 1 bis 2 Tage, um die Windows Updates zu testen und dann bekannt zu geben, ob es da Probleme gibt (und wenn ja, ob es Workarounds gibt). Wenn nach einem Update der DATEV-Server oder die Arbeitsplätze nicht sauber laufen habe ich direkt die BuHa und HR mit Fackeln und Mistgabeln neben mir stehen, ohne DATEV geht bei denen nichts.
Das Patchen erfolgt nach einem risikobasierten Stufenmodell. Nach einer kurzen Beobachtungs- und Testphase werden Updates zuerst auf Pilot- und weniger kritischen Systemen ausgerollt, anschließend auf exponierten und geschäftskritischen Systemen sowie danach flächendeckend auf Servern und Clients. Der gesamte reguläre Rollout soll grundsätzlich innerhalb von 2–3 Tagen abgeschlossen sein, sofern keine bekannten schwerwiegenden Patch-Probleme dagegen sprechen.
Im Grunde eine gute Strategie, nur folgendes halte ich für falsch:
"Die Client werden im Normalfall nach 11 Tagen gepatcht (2. Wochenende nach dem Patchday)."
Das ist sogar gefährlich, sehr gefährlich. Denn an den Kisten sitzen die Leute, welche die Emails und Webseiten öffnen. Die sind die Einbruchstelle Nummer eins. Bei uns sind die 3 Tage nach Patchday spätestens durch, sobald sie das erste Mal nach Patchday Kontakt mit unserer Update-Infrastruktur aufnehmen.
Und ein von Außen erreichbarer IIS gehört nicht in die Office-Domäne, sowas stellt man in eine DMZ-Domäne, von der es einen einseitigen Trust, oder nicht mal das zur internen Domäne gibt. , Diese DMZ-Server sind per Firewall im eigenen Subnetz abgetrennt, nur die Türen offen, die unbedingt gebraucht werden. Ich kenne sogar Umgebungen, wo auch Exchange in einer eigenen Domäne ist, einseitiger Trust, und Outlook nur auf Terminalserver, per Remote-App auf den Desktop geholt. Wenn diese (speziell gehärteten) Terminalserver wegen Phishing hops gehen, egal, lässt sich jederzeit aus dem Backup wieder herstellen.
Machen wir grundsätzlich ähnlich. Borncity lesen, Kommentare bei Borncity lesen, Heise.de lesen, unkritische Server patchen, Rest patchen, alle kritischen Systeme kurz testen. Wenn es doch mal schief geht (kommt bei uns recht selten vor), kann man VMs ja relativ schnell wieder auf einen vorherigen Snapshot zurücksetzen.
Allerdings patchen wir die Clients bei uns inzwischen sehr viel schneller. Je nach Autopatch Gruppe haben die aktiv genutzten Clients i.d.R. spätestens nach drei Tagen die Updates drauf + einen Tag Karenzzeit für den Neustart. Das, was bis dahin an Problemen nicht aufgefallen ist, fällt eh erst nach X Tagen im Livebetrieb und i.d.R. nur bei einzelnen Usern auf. Letztlich muss man halt Patchlevel und Bugfreiheit gegeneinander abwägen. Bisher funktioniert das für uns eigentlich ganz gut.
Wir machen es ähnlich und ich gebe gerne zu, daß das der Hauptgrund ist, warum ich seit vielen Jahren auf Borncity unterwegs bin.
Natürlich nicht nur deswegen 😉
Zu den Informationsquellen zählt für mich neben den genannten noch die Statusseite der DATEV (https://www.datev.de/web/de/berufsgruppenuebergreifend/service-und-support/rund-um-unsere-programme/technische-informationen/systemplattform/microsoft-updates – m.W. auch ohne Buchung entsprechender Dienste frei lesbar).
Es gibt eine Gruppe von Keyusern (u.a. die komplette IT), die die Updates quasi ungefiltert bekommen und den gängigen Bereich firmenrelevanter Arbeitsplätze abdecken, sowie für Standardkonfigurationen entsprechende VMs, die oft schon direkt in der Nacht nach dem Erscheinen der Updates automatisch gepatcht werden.
Generische PCs (etwa in Konferenzräumen und Deskshare-Plätze) sind automatisiert am Wochenende (ausgehend von einem normalen Patchday Dienstag 20:00 Uhr) dran, die "klassischen" Anwender am nächsten Montag.
Bei Anomalien (wie im Frühling diesen Jahres) kann der Prozeß verzögert werden, aber selten mehr als eine weitere Woche.
Zur Automatisierung bewährt hat sich (neben den im WSUS eingebauten Mechanismen) auch das hier schon ein paarmal erwähnte CAWUM von Aagon ACMP.
Der letzte Absatz des Beitrags, „Das größte Problem,…" enthält alle vorhandenen Probleme. Mit diesen kämpft man jeden Monat und versucht den Spagat zwischen „Sicherheit" und „der Laden muss laufen". Einen Monat geht es ganz prima, im nächsten Monat ist es katastrophal. Die Kommentare hier zeigen das auch deutlich! In den genau dargelegten Spannungsfeldern bewegen sich die Verantwortlichen immer.
Was ist der Grund? Nahezu Monopolismus auf Anbieterseite, die optimieren die Einkünfte und weniger die Prozesse.
Updates installieren ist immer eine gute Idee.
Windows 11 kann auch schnell zurückrollen.
Wichtig ist einfach, dass man Hausaufgaben gemacht hat und "Altlasten" laufend abbaut ohne neue aufzubauen.
Ich wünschte mir, es wäre wie bei iOS… da kommt das Update und meistens läuft es, ein paar Apps patzen, kommen am nächsten Tag mit einem Update.
Das ist aber auch nur möglich, weil keiner "dran rumfrickelt".
Ich fahre meine private Maschine seit Jahren als Insider… hier und da muss ich mal zurückrollen, aber sehr selten.
Vor ein paar Wochen habe ich spaßeshalber mal die Maschine auf 0 gesetzt… auch das war nicht so schlimm. Nach 15 Minuten hatte ich ein sauberes Windows am Start, weitere 15-20 Minuten waren die wichtigsten Daten wieder da. Aus dem Store und über Winget die wichtigsten Apps installiert – Netto 30 Minuten war ich produktiv.
Beruflich wäre das schneller, Device hängt an Entra/Intune und da sind es 15-20 Minuten.
Klar, ich habe nicht unendlich viele Apps.
Microsoft Apps, Apps aus dem Store, auch Firefox oder VSCode aus dem Store.
Ich habe einfach zu wenig Lebenszeit zu viele Apps zu haben.
In Firmen sieht es vielleicht anders aus, aber auch da, wann habt ihr die Software, die ihr da so sammelt das letzte mal aktualisiert? Wenn überhaupt?
Immer wieder bekommt man von Microsoft zu hören "wir haben verstanden". Und immer wieder kann man später feststellen, dass sie nichts verstanden haben. Meine Erwartungshaltung ist dementsprechend gering.
Ich habe einige Windows Server an der Backe. Updates ohne Neustart quasi als Hotpatch zu installieren ist ein guter Ansatz, aber es muss sehr zuverlässig und reproduzierbar funktionieren. Dass hin und wieder einzelne Server mit kryptischen Fehlerkodes aus der Reihe tanzen, ist nicht akzeptabel. Meist passieren solche Unfälle immer dann, wenn ich wenig Zeit habe und die Updates über Nacht in die Kisten reinprügeln muss. Wenn ich mir die Größe der Updates anschaue, dann muss ich jedesmal den Kopf schütteln, was das soll. Wenn es zweimal im Jahr ein großes Update (Service Pack) gibt, ist das Ok. Alles andere kann über feingranulare Updates geregelt werden. Die lassen sich viel schneller herunterladen und installieren. Der Admin kann auch zielgerichtet das Mini-Update installieren, was bei einer bestimmten Serverfunktion wirklich wichtig ist. Aber Microsoft scheint hier andere Ziele zu verfolgen…
Schön, dass es Bemühungen gibt, die Update-Strategie an die veränderte Bedrohungslage anzupassen. Dass Schwachstellen heute schneller gefunden, analysiert und vermutlich auch schneller ausgenutzt werden können, ist keine gewagte These mehr. Insofern ist der Gedanke, Updates schneller und gezielter auszurollen, grundsätzlich richtig.
Was mich daran aber weiterhin stört: Bei vielen Updates ist immer noch ein Neustart notwendig. Genau dieser Neustart ist in der Praxis einer der Gründe, warum Updates verzögert werden. Nicht, weil Administratoren grundsätzlich Spaß daran hätten, ungepatchte Systeme zu betreiben. Sondern weil produktive Systeme nicht beliebig neu gestartet werden können und weil jeder Patchday auch die Frage mitbringt, was danach möglicherweise nicht mehr funktioniert. Die technische Wahrheit lautet eben nicht nur: „Update verfügbar". Sie lautet oft: „Update verfügbar, Neustart erforderlich, Nebenwirkungen nicht ausgeschlossen." Das erhöht die Begeisterung bekanntlich ungemein.
Wenn man etwas tiefer ins System blickt, bekomme ich zudem den Eindruck, dass immer mehr Funktionen in die Systeme hineingebuttert werden, ohne sich vorher konsequent die Sicherheitsfrage zu stellen. Neue Features sind nicht grundsätzlich schlecht. Aber sie sollten so gebaut und ausgeliefert werden, dass sie per Default und per Design vernünftigen Sicherheitsstandards entsprechen. Nicht erst nachträglich über Gruppenrichtlinien, Intune-Profile, Registry-Anpassungen und sonstige administrative Gymnastikübungen halbwegs eingefangen werden müssen.
Das eigentliche Problem ist aus meiner Sicht also nicht nur die Geschwindigkeit beim Patchen. Es ist auch die wachsende Angriffsfläche. Je mehr Dienste, Integrationen, Komfortfunktionen, Cloud-Anbindungen, Automatismen und Hintergrundprozesse ein System mitbringt, desto größer wird die Komplexität. Und Komplexität ist selten ein Sicherheitsgewinn. Sie ist eher der Bereich, in dem sich Fehler wohlfühlen.
Natürlich muss man Updates trotzdem einspielen. Wer bekannte Schwachstellen dauerhaft offen lässt, handelt fahrlässig. Aber Patch-Management allein ist keine Sicherheitsstrategie. Es ist ein wichtiger Baustein, mehr nicht. Man sollte nicht so tun, als könne der Hersteller durch monatliche Reparaturen dauerhaft kompensieren, was vorher an unnötiger Angriffsfläche eingebaut wurde.
Darüber hinaus gibt es einige Sicherheitsprobleme, die man außerhalb von Windows zumindest deutlich eindämmen kann. Nutze ich zum Beispiel eine UTM-Firewall mit Webfilter, HTTP-Proxy und sauber gepflegten Portregeln, kann ich bereits eine ganze Menge abfangen. Nicht alles, aber vieles. Wenn ausgehende Verbindungen nicht beliebig möglich sind, wenn bekannte Schadseiten blockiert werden, wenn unnötige Ports geschlossen sind und wenn Netze sinnvoll getrennt werden, dann reduziert das die praktischen Angriffsmöglichkeiten erheblich.
Kommt zusätzlich eine gut gepflegte und sinnvoll konfigurierte Endpoint-Sicherheitslösung dazu, wird die Angriffsfläche weiter kleiner. Auch hier gilt: Das ist keine magische Schutzkuppel. Aber es ist ein weiterer Filter, eine weitere Hürde, ein weiterer Punkt, an dem ein Angriff hängen bleiben kann. Und genau darum geht es in der Praxis: nicht um die eine perfekte Maßnahme, sondern um mehrere vernünftige Schichten.
100 Prozent Sicherheit erreiche ich damit nicht. Die erreicht ohnehin niemand, auch wenn manche Marketingabteilungen das Gegenteil andeuten. Aber ich kann sehr wohl etwas dazu beitragen, Systeme sicherer zu machen — auch dann, wenn der Hersteller gerade schläft, träumt oder wieder ein neues Feature für unverzichtbar hält, nach dem niemand gefragt hat.
Am Ende müsste die Diskussion daher breiter geführt werden. Schnellere Updates sind sinnvoll. Hotpatching ist ebenfalls ein Schritt in die richtige Richtung, wenn dadurch Neustarts seltener notwendig werden. Aber das löst nicht die Grundfrage: Warum müssen Betriebssysteme immer weiter aufgeblasen werden, statt sie konsequent robuster, schlanker und sicherer zu gestalten?
Sicherheit beginnt nicht erst am Patchday. Sie beginnt beim Design. Und sie beginnt bei der Frage, ob eine Funktion überhaupt standardmäßig aktiv sein muss. Alles, was nicht läuft, muss nicht gepatcht werden. Alles, was nicht erreichbar ist, kann schwerer angegriffen werden. Und alles, was gar nicht erst eingebaut wurde, verursacht zumindest an dieser Stelle keine Sicherheitslücke.
Kurz gesagt: Es ist gut, wenn Microsoft die Update-Strategie verbessert. Noch besser wäre es, wenn weniger Anlass bestünde, ständig hinterherzuräumen. Patchen bleibt notwendig. Aber ein System, das dauerhaft nur durch hektisches Nachbessern sicher gehalten werden kann, hat ein grundsätzliches Konstruktionsproblem.
This! Dem ist nichts mehr hinzuzufügen, sprichst mir aus der Seele! Danke
Ziemlich ausführlich auf den Punkt gebracht…