Never change a running system... diese Weisheit hat schon manchen Administrator vor Problemen bewahrt. Oder sie nur verschoben? Eine Datenbank die nicht mehr richtig funktioniert, ein Server der nicht mehr startet oder ein Dienst der nicht mehr sauber anläuft. Das kann von Unannehmlichkeiten bis zum Stillstand einer Maschine alles bedeuten. 

Aber mit jedem Schritt hin zu einer digitalen und vernetzten Systemlandschaft steigen die Anforderungen und Risiken weiter an. Gesetzliche Vorgaben wie das IT-Sicherheitsgesetz und BDSG sind verpflichtend. KRITIS und NIS2 drängen auf die Umsetzung. Firmen werden verpflichtet IT Anforderungen auch gegenüber ihren Lieferanten zu definieren und zu prüfen.

Also ist "never change a running system" schon jetzt in vielen Bereichen nicht mehr umsetzbar. 

Die Frage sollte also lauten:

"How to change a running system?"
 

Analysephase

Wer nicht weiß, wo er steht, weiß auch nicht wie weit der Weg noch ist. Vor irgendwelchen Maßnahmen steht die Bestandsaufnahme. Dabei werden für den definierten Umfang alle Systeme Hard- und Softwareseitig ermittelt. Die Anzahl der Geräte und sowie installierte Software wird als Baseline festgehalten.

Erstellen einer Update Strategie

Im nächsten Schritt wird die Updatestrategie erstellt. In einem Workshop werden die einzelnen Systeme und Komponenten gemeinsam bewertet und festgelegt, welche Systeme in welchem Zyklus aktualisiert werden um internen wie externen Anforderungen gerecht zu werden. Der Dokumentationsbedarf wird je nach internen Spezifikationen und branchenüblichen Anforderungen festgeschrieben. Die erstellte Update Strategie dient als Grundlage für die technische und organisatorische Umsetzung.

Dokumente und Testprotokolle

Was nicht dokumentiert wurde, wurde auch nicht gemacht. Dies ist eine der Kernaussagen GMP gerechter Dokumentation. Hierzu zählen Change Control Dokumente, Spezifikationsanpassungen, Testprotokolle und SOPs. Notwendige Dokumente werden erzeugt. Bestehende Dokumente, die im Zuge der Updates angepasst werden müssen, werden über eine Change Prozedur verfolgt und freigegeben.

Testaufbau

Um Patches vor Installation in der Produktivumgebung zu testen, wird ein Testsystem benötigt. Dies kann physisch oder virtuell, vor Ort oder remote sein. Der Aufbau und Umfang wird gemeinsam definiert. Je ähnlicher das Testsystem dem Produktivsystem ist, desto aussagefähiger sind die durchgeführten Tests.

Testdurchführung

Die Testdurchführung kann sowohl extern als auch intern erfolgen. Dazu können interne Mitarbeiter geschult werden und danach die Tests anhand der Protokolle und SOPs durchführen. Externe Unterstützung oder Durchführung der Tests ist auch möglich. Ziel ist eine erfolgreiche Abarbeitung aller spezifizierten Tests, die eine Freigabe zur Installation auf dem Produktivsystem zur Folge hat.

Installation im Produktivsystem

Die Installation im Produktivsystem erfolgt dann innerhalb eines verfügbaren Wartungszeitraums. Externe Unterstützung bei der Installation ist möglich.

Dieses Patch Management Konzept erzeugt eine klare Definition der zu aktualisierenden Systeme, so wie einen definierten und dokumentierten Prozess. Durch den zweistufigen Ablauf wird das Risiko für Stillstände der Produktivumgebung minimiert. Dennoch können kurze Aktualisierungsintervalle eingeführt und die Systemsicherheit erhöht werden.