Jeden zweiten Dienstag im Monat gibt’s von Microsoft die kumulativen Sicherheitsupdates. In Betrieben mit zehn oder zwanzig Arbeitsplätzen kommen diese Updates oft dann auf die Systeme, wenn gerade jemand Zeit hat. Manchmal auch gar nicht. Das eigentliche Risiko steckt nicht im Update selbst. Es steckt im Fehlen eines Rahmens: Keiner weiß, ob das letzte Backup noch wiederherstellbar ist, und für einen fehlgeschlagenen Patch gibt es keinen Rückweg.
Warum auch kleine Umgebungen ein Wartungsfenster brauchen
Sobald ein Sicherheitsupdate veröffentlicht wird, ist auch die Schwachstelle, die es schließt, veröffentlicht. Angreifer vergleichen dann gepatchte und ungepatchte Binärdateien und leiten je nach Schwachstelle innerhalb weniger Tage Exploits ab. Wer Updates nach Gefühl einspielt, vergrößert das Zeitfenster unnötig.
Ein Wartungsfenster schafft Verlässlichkeit. Bewährt hat sich ein Termin am Wochenende nach dem Patchday, an dem Server neu starten dürfen, ohne dass jemand bei der Arbeit unterbrochen wird. Das BSI fordert im IT-Grundschutz, dass Updates geplant, getestet, freigegeben und dokumentiert werden. Sofern die Unternehmen nicht zu klein werden, gilt das für alle.
In Betrieben ohne eigene Administration wird häufig schlicht ein solcher Rhythmus an den Betreuer mehr oder weniger delegiert. Beim IT-Dienstleister Absolute-IT wird z. B. nach festem Zeitplan am Wochenende gepatcht, während Monitoring und Backup-Überwachung laufen. Dabei ist weniger wichtig, wer das Fenster betreut, sondern dass es regelmäßig aufmacht und jedes Mal nachvollziehbar protokolliert wird.
Updates in Ringen ausrollen statt auf einen Schlag
Ein Update, das auf allen Geräten gleichzeitig landet, macht jeden Fehler sofort zum Flächenproblem. Das Ring-Modell verteilt dieses Risiko auf verschiedene Ringe:
- Ring 0: zwei oder drei Testgeräte, idealerweise mit den wichtigsten Fachanwendungen
- Ring 1: eine Pilotgruppe aus technisch versierten Mitarbeitenden
- Ring 2: alle übrigen Arbeitsplätze
In Microsoft Intune lassen sich solche Update-Ringe abbilden. Dort können Qualitätsupdates um bis zu 30 Tage zurückgestellt werden, Funktionsupdates um bis zu 365 Tage. Für kleine Umgebungen reicht meist auch nur einige Tage Abstand zwischen den Ringen.
Backup prüfen, bevor gepatcht wird
Ein grüner Haken in der Backup-Software belegt nur, dass ein Job durchgelaufen ist. Ob sich daraus tatsächlich ein brauchbares lauffähiges System wiederherstellen lässt, ergibt erst der Restore-Test.
Als Orientierung eignet sich die erweiterte 3-2-1-1-0-Regel. Sie verlangt drei Kopien der Daten auf zwei unterschiedlichen Medien, eine davon außerhalb der eigenen Behausung. Eine weitere Kopie offline oder unveränderbar gespeichert schützt vor Ransomware. Die Null bedeutet null Fehler in der Sicherungsprüfung.
Zwei Kennzahlen helfen bei der Planung:
- RPO (Recovery Point Objective): wie viel Datenverlust ist maximal tolerabel, gemessen in Zeit seit letzter Sicherung?
- RTO (Recovery Time Objective): wie lange darf die Wiederherstellung maximal dauern?
Rollback: Den Rückweg vor dem ersten Klick festlegen
Bevor ein Update eingespielt wird, muss klar sein, wann es wieder entfernt wird. Sinnvolle Abbruchkriterien sind etwa nicht startende Dienste, ausfallende Druckaufträge oder eine Fachanwendung, die keine Verbindung mehr zur Datenbank herstellt.
Technisch gibt es viele Wege zurück. Seit Microsoft Servicing Stack Update und kumulatives Update im Paket liefert, lässt sich das kumulative Update über wusa.exe meist nicht mehr entfernen. Der sichere Weg führt über DISM mit dem Parameter /Remove-Package. Funktionsupdates lassen sich innerhalb eines Rückrollzeitraums, der standardmäßig zehn Tage beträgt, zurücksetzen. Er kann auf 2 bis 60 Tage anpassbar sein. Bei Servern ist der Snapshot oder das letzte geprüfte Backup meist der schnellste Rückweg.
Jeder Rollback gehört ins Protokoll: welches Update, auf welchen Systemen, welcher Fehler, welche Maßnahme. Diese Aufzeichnungen zeigen dann über Monate, welche Systeme regelmäßig Probleme verursachen.