Updates einspielen, ohne den Betrieb anzuhalten

Der IT-Grundschutz des BSI führt Patch- und Änderungsmanagement als eigenen Baustein. Die Anforderung OPS.1.1.3.A15 sagt knapp, dass Patches grundsätzlich zeitnah nach Veröffentlichung eingespielt werden sollten (BSI). Ein Fenster in vier Monaten erfüllt das erkennbar nicht, ein Fenster in vier Wochen für die meisten Fälle schon. Der Baustein trifft dabei keine Aussage über Uhrzeit oder Dauer — er verlangt einen geregelten Ablauf, keine bestimmte Nachtstunde. Wer das liest, bevor er den ersten Termin sucht, spart sich die Diskussion über das perfekte Fenster.

Zwei weitere Sätze desselben Bausteins sind für die Planung wichtiger als jede Werkzeugfrage. Wenn Patches installiert und Änderungen durchgeführt werden, müssen Rückfall-Lösungen vorhanden sein (BSI) — das ist eine Basis-Anforderung, keine Empfehlung. Und Patches und Änderungen sollten vorab geeignet getestet werden (BSI). Damit sind Testinstanz und Rückfallpfad keine Ausbaustufe für später, sondern Bestandteil des Ablaufs, den ein Betrieb ohnehin schuldet. Wie sich dieser Ablauf festhalten lässt, ohne ein Handbuch zu schreiben, steht in unserem Beitrag zur Verfahrensdokumentation.

Auf europäischer Ebene kommt die NIS-2-Richtlinie hinzu. Sie nennt in Artikel 21 Absatz 2 Buchstabe e ausdrücklich Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen einschließlich Management und Offenlegung von Schwachstellen (Amtsblatt der EU) — eine von zehn Mindestmaßnahmen. Damit wird das Einspielen von Aktualisierungen für die erfassten Einrichtungen zur Rechtspflicht und über Lieferketten auch für deren Zulieferer zum Vertragsthema. Wen die Richtlinie im Mittelstand betrifft, ordnet unser Beitrag zu NIS-2 im Mittelstand ein.

Die Meldefristen aus Artikel 23 wirken auf den ersten Blick wie ein Thema für den Ernstfall. Tatsächlich entscheiden sie über die Ablage: Wer einen erheblichen Sicherheitsvorfall innerhalb von 24 Stunden nach Kenntnisnahme als Frühwarnung melden muss (Amtsblatt der EU) und binnen 72 Stunden eine Meldung mit erster Bewertung nachlegt (Amtsblatt der EU), hat keine Zeit, den Patchstand zu rekonstruieren. Ein Wartungsplan, der festhält, welcher Stand wann auf welchem System landete, ist damit kein Verwaltungsakt, sondern die Grundlage der eigenen Auskunftsfähigkeit im IT-Betrieb.

Für Serverbetriebssysteme gibt es seit einigen Jahren Verfahren, die Sicherheitskorrekturen ohne Neustart wirksam machen. Der Hersteller beschreibt für Windows Server einen Quartalsrhythmus: In den beiden Monaten nach der Basis-Ausgabe erhalten die Geräte eine Hotpatch-Ausgabe, die nur Sicherheitskorrekturen enthält und ohne Neustart installiert werden kann (Microsoft). Ein geplantes Jahr besteht damit aus vier Basis-Ausgaben mit Neustart und acht Hotpatch-Ausgaben ohne (Microsoft): acht der zwölf Ausgaben lassen sich ohne Neustart einspielen. Ein Jahr mit nur vier Neustartfenstern folgt daraus nicht. Derselbe Hersteller hält im selben Dokument fest, dass Nicht-Sicherheitsupdates für Windows, .NET-Updates sowie Treiber- und Firmware-Updates außerhalb des Hotpatch-Programms liegen und auch in Hotpatch-Monaten eine Aktualisierung des Systems verlangen; nach einer neuen Basis-Ausgabe kommt ein regelmäßiger Neustart hinzu (Microsoft).

Der Preis dafür steht in derselben Dokumentation: Hotpatch-Aktualisierungen unterstützen keinen automatischen Rückfall (Microsoft). Das verschiebt die Last, es nimmt sie nicht weg. Wer den Neustart aus dem Fenster nimmt, muss den Rückfallpfad an anderer Stelle bauen — über eine Abbildung des Systemzustands vor der Änderung, über eine zweite Instanz oder über die Möglichkeit, das betroffene Paket einzeln zurückzunehmen. Diese Entscheidung gehört in den Plan, bevor das erste Hotpatch läuft.

Unter Linux übernimmt Kernel-Livepatching dieselbe Rolle. Der Anbieter der verbreiteten Distribution gibt für seinen Dienst eine Abdeckung von zehn Jahren an, mit einer Zusatzoption bis zu fünfzehn Jahren (Canonical). Ebenso deutlich steht dort, dass Livepatching den Neustart nicht ersetzt (Canonical). Genau das ist der betriebliche Gewinn: Der Neustart verschwindet nicht, er wandert aus dem Zeitdruck in einen geplanten Termin, an dem ohnehin jemand vor Ort ist.

Wo Dienste in mehreren Instanzen laufen, verschiebt sich die Frage noch einmal. Bei rollierenden Aktualisierungen einer Arbeitslast sind ab Werk höchstens 25 Prozent der Instanzen gleichzeitig außer Betrieb (Kubernetes); der Rest bedient weiter Anfragen. Das ist kein Argument für eine neue Plattform, sondern ein Hinweis auf das Muster dahinter: mehrere gleichartige Instanzen, ein vorgeschalteter Verteiler und eine Prüfung, die eine Instanz erst wieder freigibt, wenn sie antwortet. Dasselbe Muster trägt auch ohne Containerplattform — zwei Anwendungsserver hinter einem Verteiler genügen.

Dass der Rückfall der schwächste Teil ist, zeigt sich sogar dort, wo Aufsicht und Prüfung längst greifen. Bei Betreibern Kritischer Infrastrukturen führten rund 80 Prozent bereits ein Informationssicherheitsmanagementsystem mit einem Reifegrad von mindestens drei, bei den Systemen für das Notfallmanagement lag der Anteil mit knapp zwei Dritteln deutlich darunter (BSI). Die Absicht ist also vorhanden, die geübte Rückfallfähigkeit hinkt hinterher. In kleineren Betrieben ist der Abstand erfahrungsgemäß größer, nicht kleiner.

Ein Rückfallpfad besteht aus vier Angaben: dem Zustand, auf den zurückgegangen wird, dem Weg dorthin, der Person, die ihn auslöst, und dem Zeitpunkt, an dem entschieden wird. Fehlt die letzte Angabe, wird im Fenster weitergesucht, bis das Fenster vorbei ist. Deshalb steht im Plan ein Abbruchpunkt je Abschnitt. Und deshalb wird der Weg einmal im Jahr trocken durchgespielt — an einem Termin ohne Zeitdruck, mit derselben Sicherung, die im Ernstfall gezogen würde.

Ein Teil der Wartungslast entsteht Jahre vor dem ersten Fenster — bei der Auswahl. Das europäische Cyberresilienzgesetz verpflichtet Hersteller von Produkten mit digitalen Elementen auf einen Unterstützungszeitraum von mindestens fünf Jahren (Amtsblatt der EU). Bereitgestellte Sicherheitsaktualisierungen müssen zudem nach ihrer Bereitstellung mindestens zehn Jahre verfügbar bleiben (Amtsblatt der EU). Für die Beschaffung ist das eine Untergrenze, kein Zielwert: Wer ein System zehn Jahre betreiben will, fragt den Zeitraum vertraglich ab.

Eine zweite Anforderung derselben Verordnung wirkt unscheinbar und verändert die Wartungsplanung erheblich. Soweit technisch machbar, müssen neue Sicherheitsaktualisierungen getrennt von den Funktionsaktualisierungen bereitgestellt werden (Amtsblatt der EU). Genau diese Trennung ist die Voraussetzung dafür, dass eine Sicherheitskorrektur in einem kurzen Fenster laufen kann, ohne dass die Fachbereiche danach neue Masken vorfinden. Wer heute ausschreibt, kann die Trennung als Anforderung aufnehmen, statt sie später zu vermissen.

Die Fristen der Verordnung stehen bereits fest. Artikel 14 gilt ab dem 11. September 2026 (Amtsblatt der EU), die Verordnung im Übrigen ab dem 11. Dezember 2027 (Amtsblatt der EU). Für aktiv ausgenutzte Schwachstellen ist spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme ein Abschlussbericht fällig (Amtsblatt der EU). Was das für den eigenen Meldeweg bedeutet, beschreibt unser Beitrag zum Meldeprozess in 24 Stunden.

Die Tabelle ist kein Beschaffungsplan, sie ist ein Terminkalender. Jede Zeile trägt ein Datum, das heute schon feststeht, und jedes dieser Daten erzeugt Arbeit, die sich verteilen lässt — oder eben nicht. Ein Betrieb, der die Endtermine seiner Bausteine einmal im Jahr zusammenträgt, verwandelt spätere Notfälle in gewöhnliche Vorhaben. Wo dabei Systeme auftauchen, für die es keinen Nachfolgestand gibt, beginnt die Arbeit an der Ablösung des Altsystems früher als geplant, aber nicht überraschend.