M 2.421 Planung des Patch- und Änderungsmanagementprozesses

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Änderungsmanager

Jede Institution sollte für das Patch- und Änderungsmanagement einen klar definierten Prozess eingerichtet haben und die Zuständigkeiten für die verschiedenen Aufgaben geregelt haben (siehe M 2.423 Festlegung der Verantwortlichkeiten für das Patch- und Änderungsmanagement). Alle Änderungen von Hard- und Softwareständen und Konfigurationen sollten über den Prozess Patch- und Änderungsmanagement gesteuert und kontrolliert werden. Um alle Änderungen erfassen und bewerten zu können, sollten alle vom Patch- und Änderungsmanagement betreuten IT-Systeme dem Änderungsmanager unterstellt sein. Änderungen an Konfiguration und Zustand der Systeme sollten damit nur noch über das Änderungsmanagement möglich sein.

Der Patch- und Änderungsmanagementprozesses kann, angelehnt an ITIL, wie folgt schematisch dargestellt werden:

Überblick über den Patch- und Änderungsmanagementprozess

Abbildung: Überblick über den Patch- und Änderungsmanagementprozess

Koordination

Nachdem ein Request for Change (RfC), also eine Änderungsanforderung, eingereicht und akzeptiert wurde, muss er zunächst kategorisiert und priorisiert werden, bevor mit der eigentlichen Umsetzungsplanung und -koordination begonnen wird.

Wenn eine Änderungsanforderung (wie in M 2.422 Umgang mit Änderungsanforderungen beschrieben) eingereicht und akzeptiert wurde, muss sie zunächst klassifiziert, also kategorisiert und priorisiert werden, bevor mit der eigentlichen Umsetzungsplanung und -koordination begonnen wird. Im Anschluss sollten weitere Punkte berücksichtigt werden, bevor der Patch oder die Änderung eingespielt werden kann.

Umsetzung

Die vom Änderungsmanager bestimmten Mitarbeiter werden beauftragt, die Änderung umzusetzen. Das Änderungsmanagement überwacht dies. Bei Änderungen, die nur ungenügend getestet werden können, ist es in manchen Fällen sinnvoll, diese zunächst nur bei einer kleinen Anwendergruppe einzuspielen. Danach werden die Ergebnisse evaluiert, bevor die Änderung auf allen Systemen umgesetzt wird. Ist dies aufgrund der Gegebenheiten nicht möglich oder sinnvoll, beispielsweise weil vergleichbare Änderungen schon häufig ohne Probleme durchgeführt wurden, oder weil miteinander inkompatible Softwarestände eine Teil-Verteilung unmöglich machen, kann auch eine Komplett-Verteilung durchgeführt werden.

Evaluation

Durchgeführte Änderungen sollten anschließend evaluiert werden. Danach wird das Ergebnis vom Änderungsmanagement bzw. vom CAB (Change Advisory Board) anhand der folgenden Aspekte bewertet:

Wurde die Änderung erfolgreich durchgeführt, kann die Änderungsanforderung (Request for Change) bzw. der Änderungsdatensatz geschlossen werden. Ist die Änderung fehlgeschlagen, muss entschieden werden, ob die durchgeführten Änderungen angepasst werden müssen. In machen Fällen empfiehlt es sich, die Änderung rückgängig zu machen und eine neue oder abgeänderte Änderungsanforderung auszuarbeiten. Bei einer fehlgeschlagenen Änderung kann es auch sinnvoll sein, die Ursachen zu beleuchten und davon ausgehend IT-Systeme oder Prozesse anzupassen. So können ähnliche Probleme zukünftig vermieden werden.

Je nach Art und Umfang der Änderung kann es sinnvoll sein, eine Evaluation direkt nach dem Einspielen durchzuführen. Andererseits kann es auch sinnvoll sein, einige Tage oder Wochen abzuwarten, bis die Auswirkungen der Änderung und die Zielerreichung abzusehen sind. Durchgeführte Änderungen sind erst dann erfolgreich abgeschlossen, wenn sie positiv evaluiert und dokumentiert wurden. Damit dies nicht vergessen wird, sollte sich der Änderungsmanager über eine zeitliche automatisierte Wiedervorlage daran erinnern lassen.

Rücknahme von Änderungen

Ob es notwendig ist, Hard- oder Software-Änderungen zurückzuziehen, ergibt sich direkt aus der Evaluation. Haben die Änderungen den gewünschten Erfolg nicht erreicht oder hat sich die Situation sogar verschlechtert, sollten die Änderungen zurückgenommen werden, wenn es technisch möglich und wirtschaftlich vertretbar ist.

Dies kann häufig durch die benutzte Patch- und Änderungsmanagementsoftware technisch unterstützt werden. Ist dies nicht der Fall, müssen die Patches und Änderungen manuell rückgängig gemacht werden.

Abschluss und Dokumentation

Es empfiehlt sich, alle Änderungsanforderungen, Hard- und Software-Änderungen, Testdurchführungen und -ergebnisse in einer Datenbank zu dokumentieren, unabhängig davon, ob sie erfolgreich waren oder nicht, (siehe M 2.34 Dokumentation der Veränderungen an einem bestehenden System). Das Wissen um Fehler bei der Installation der Änderungen und deren Lösungen sollte als Wissen in der Institution für den Wiederholungsfall zur Verfügung stehen.

In vielen Institutionen ist es inzwischen Routine, Betriebssysteme und Anwendungen regelmäßig mit den verfügbaren Software-Updates zur Behebung von Schwachstellen und dem Schutz vor Schadsoftware zu versorgen. Dieses Verfahren ist jedoch auch für Hardware notwendig, was bei ordnungsgemäßer Funktionalität der Hardware oft in Vergessenheit gerät. In vielen IT-Geräten kommen kompakte Betriebssysteme zum Einsatz, die oft auf die jeweilige Hardware zugeschnitten sind. Dazu gehören beispielsweise Router, Switches, Netzdrucker und Mobiltelefone. Daher muss sichergestellt sein, dass auch solche Geräte ins Änderungsmanagement einbezogen und mit sicherheitsrelevanten Updates versorgt werden.

Prüffragen: