Patching ohne monatliche Verhandlungen

Anbieter veröffentlichen ihre Fixes, das Sicherheitsteam erinnert alle an die Fristen und der Betrieb beginnt, die Service Owner per E-Mail zu kontaktieren. Wann können die Anwendungserver neu gestartet werden? Ist Dienstagabend in Ordnung oder muss es bis zum Wochenende warten? Was ist mit dem System, das letztes Mal länger als erwartet brauchte, um wieder hochzufahren? Die Antworten kommen spät, einige gar nicht. Am Ende wird ein Teil der Systeme gepatcht und der Rest wird auf „nächsten Monat“ verschoben.

Dieser Zyklus wiederholt sich jeden Monat und kostet Energie auf beiden Seiten. Administratoren sind frustriert, dass sie die Arbeit, für die sie verantwortlich sind, nicht erledigen können. Service Owner fühlen, dass der Betrieb immer wieder etwas von ihnen verlangt. Und die Sicherheit beobachtet, wie der Rückstau von aufgeschobenen Fixes wächst.

Warum dieselbe Frage immer wieder kommt

Oft sehen wir, dass Patching als eine Reihe von Einzelereignissen durchgeführt wird. Jeden Monat bringt eine neue Serverliste, eine neue Reihe von Ausfallanfragen und eine neue Runde von Genehmigungen. Doch die meisten Antworten ändern sich nicht von Monat zu Monat: Der Service hat immer noch dieselben Geschäftszeiten, dieselbe Redundanz und denselben Besitzer.

Das Problem ist also nicht, dass die Leute nicht bereit sind, zuzustimmen. Das Problem ist, dass die Vereinbarung nie schriftlich festgehalten wird und im nächsten Monat alle wieder von vorne beginnen. Weitere Schwächen kommen hinzu:

• Es ist unklar, wer für einen Service entscheidet, daher wird die Anfrage zwischen mehreren Personen hin- und hergegeben,
• Server werden einzeln von einer Liste gepatcht, nicht nach Service und dessen Abhängigkeiten,
• redundante Knoten werden manchmal gleichzeitig neu gestartet, weil nur wenige Leute wissen, dass sie redundant sind,
• ein kritischer Fix wartet in derselben Warteschlange wie ein routinemäßiges monatliches Update.

Wie man es angeht

Anstatt jeden Monat zu verhandeln, ist es besser, eine einmalige Vereinbarung mit dem Service Owner zu treffen, die gültig bleibt, bis jemand sie bewusst ändert. Die Vereinbarung regelt, wann Patching stattfinden darf, ob Patching innerhalb dieses Fensters vorab genehmigt ist und wie redundante Knoten behandelt werden. Die monatliche Planung hört dann auf, eine Frage von „Dürfen wir?“ zu sein, und wird einfach zu „Was kommt als Nächstes?“.

Das zweite Prinzip ist, den Routineweg vom dringenden Weg zu trennen. Eine kritische Schwachstelle sollte nicht bis zum nächsten regulären Fenster warten, aber auch nicht den Service Owner vollständig umgehen.

Wie Eywo Stratum es handhabt

Eywo Stratum führt eine Patch-Vereinbarung zwischen Betrieb und Service Owner ein. Sie umfasst:

• ein stehendes Fenster – eine regelmäßige Zeit, in der der Service gepatcht werden darf,
• vorab genehmigtes Patching innerhalb des Fensters – Änderungen, die von der Vereinbarung abgedeckt sind, benötigen keine neue Ausfallgenehmigung jeden Monat,
• rollierende Patching von redundanten Knoten – Knoten in einer Redundanzgruppe werden nacheinander gepatcht, damit der Service verfügbar bleibt,
• ein beschleunigter Modus für kritische Probleme – ein kürzerer Weg für schwere Schwachstellen, der im Voraus von beiden Seiten vereinbart wird.

Ein vorgeschlagener Patch-Vertrag landet in der einzigen „Zu genehmigenden“ Warteschlange des Service Owners, neben Änderungsausfällen und Anfragen. Eine Regel definiert, wer der Besitzer ist; wenn ein Service keinen Besitzer hat, entscheidet der Change-Manager. Eine Ablehnung kommt immer mit einem Grund, damit der Betrieb weiß, was anzupassen ist.

Patch-Vereinbarungen fließen in einen wellenbasierten Patching-Plan ein. Server werden nach ihren Services und Fenstern in Wellen gruppiert, und der Plan generiert die entsprechenden Änderungen in einem Schritt. Diese Änderungen durchlaufen dieselben Prüfungen wie jede andere Änderung im System: Auswirkungen auf Services, Wartungsfenster, Einfrierungen und Kollisionen. Das Dashboard für Schwachstellen und Behebung zeigt dann, wie die Arbeit voranschreitet.

Einmal zustimmen, jeden Monat ruhig schlafen

Patching muss keine monatliche Verhandlung sein. Sobald vereinbart ist, wann und wie ein Service gepatcht wird, können Administratoren nach einem Plan arbeiten, Service Owner wissen, was sie erwarten können, und die Sicherheit kann sehen, dass Fixes tatsächlich in die Produktion gelangen. Das Gespräch mit dem Service Owner findet gelegentlich statt und dreht sich um das, was wichtig ist, nicht dieselbe Frage jeden Monat.

Patch-Vereinbarungen, wellenbasierte Patching-Pläne und das Behebungsdashboard sind in der Business-Edition enthalten.