Laut Microsofts Statusmeldung kann RDS nach der Installation des Patchday-Updates instabil werden. Der Hersteller beschreibt RDP-Verbindungen, die nach einigen Minuten abbrechen, Anmeldeprobleme sowie Server, die bei der Meldung „Bitte warten Sie auf die Remotedesktopkonfiguration" hängen bleiben. Auch zugehörige Werkzeuge könnten nicht mehr reagieren, darunter die Microsoft Management Console (MMC), der RDS-Lizenzdiagnose sowie der Datei-Explorer.
Hinzu kommt, dass die Seite für Windows Update laut Microsoft nicht mehr reagieren und dauerhaft einen Ladeindikator anzeigen kann. Bei Hyper-V waren freigegebene Host-Ordner in Linux-VMs plötzlich nicht mehr verfügbar. Einzelne USB-Audiogeräte im Mehrkanalmodus starteten nach dem Update entweder gar nicht mehr oder gaben keinen Ton aus.
Ensar Seker, Chief Information Security Officer beim Threat-Intelligence-Anbieter SOCRadar, ordnet den Vorfall gegenüber Dark Reading ein: „Ich denke, wir sollten damit rechnen, dass dieses Risiko mit weiter wachsenden Patch-Mengen zunimmt, aber der Zusammenhang ist nicht einfach der, dass mehr Patches automatisch mehr kaputte Systeme bedeuten." Das größere Problem sei die Komplexität moderner IT-Landschaften — zunehmend verflochtene Betriebssysteme, Cloud-Dienste, Virtualisierungsplattformen, Treiber, Identitätskomponenten und Alttechnik.
„Jede zusätzliche Abhängigkeit und jede unterstützte Konfiguration vergrößert die Testmatrix, und es wird extrem schwierig, vor der Freigabe eines Patches jede Unternehmensumgebung nachzubilden", sagt Seker. Weil Schwachstellen immer schneller ausgenutzt würden, stünden Organisationen zugleich unter enormem Druck, schneller zu patchen — daraus entstehe „ein unvermeidbares Spannungsverhältnis zwischen sicherheitsbedingter Dringlichkeit und Regressionstests".
„Was mit den Remote Desktop Services und Hyper-V passiert ist, ist ein gutes Beispiel dafür, warum Patch-Management faktisch Teil der betrieblichen Resilienz geworden ist", so Seker. Verzögerte Patches setzten Unternehmen aktiver Ausnutzung aus, ein fehlerhaftes Update direkt in der Produktion könne dagegen kritische Dienste stören.
Sein Rat lautet, nicht alles sofort auszurollen, sondern risikobasiert zu patchen: mit gestaffelten Deployment-Ringen, repräsentativen Testumgebungen, Rollback-Möglichkeiten und verstärkter Überwachung. „Mit steigenden Patch-Mengen und wachsender Software-Komplexität müssen Organisationen besser darin werden, Patches sicher auszurollen, statt anzunehmen, dass Hersteller jede unbeabsichtigte Nebenwirkung vor der Freigabe ausschließen können."
Tyler Reguly, Associate Director für Security R&D bei Fortra, teilt diese Einschätzung und verweist darauf, dass Sicherheitsteams Patches vor der breiten Verteilung noch sorgfältiger prüfen müssten — denn es gebe keine unabhängigen Stellen oder Aufsichtsbehörden, die ihnen diese Prüfung abnehmen. „Dieses Fehlen externer Schutzmechanismen ist der Grund, warum das Testen von Patches während des Rollouts so entscheidend ist und warum wir es niemals so weit kommen lassen sollten, Updates ohne angemessene Tests sofort auszuspielen", sagt Reguly.