Bundesamt für Sicherheit in der Informationstechnik

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:

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.

  • Beschaffung oder Entwicklung der Patches und Änderungen
    Viele Hersteller bieten die Möglichkeit, die nötigen Informationen über die Veröffentlichung neuer Hard- oder Software oder über aufgetretene Fehler und deren Behebung im Abonnement per E-Mail zu erhalten.
    Die Aktualisierungen und Patches werden in der Regel auf Internet-Servern zum Download bereit gestellt. Teilweise sind diese Quellen nur in Verbindung mit gültiger Registrierung oder Support-Verträgen zugänglich. Häufig bietet die installierte Software oder das installierte Betriebssystem dem Benutzer die Möglichkeit, Software-Änderungen direkt mittels der jeweiligen Anwendung oder dem jeweiligen System zu laden.
    Einige Hersteller stellen ihren Kunden spezielle Applikationen zur Verfügung, um die Produkte zu verwalten und zu aktualisieren. Zusätzlich gibt es auch immer mehr Anwendungen, die, wenn der Benutzer und die Sicherheitseinstellungen dies zulassen, selbsttätig über das Internet bei ihren Herstellern nach Aktualisierungen suchen und den Anwender gegebenenfalls informieren. Aus Sicherheitssicht hat das automatisierte Einspielen von Änderungen allerdings Nachteile. Daher sollte genau überlegt werden, ob solche Mechanismen in Anspruch genommen werden sollen.
    Eine interne Softwareentwicklung könnte eine weitere Möglichkeit sein, Software-Änderungen zu beziehen, falls aufgetretene Sicherheitslücken oder andere Anforderungen diese erforderlich machen. Allerdings muss dafür nicht nur das nötige Fachwissen vorhanden sein, sondern auch die Schnittstellen offen liegen.
  • Testen
    Die Funktionalität der Systeme muss nach Einspielen der Änderung durch einen Test ermittelt werden. Dafür sind bei jeder Änderung, wenn möglich, eine repräsentative Auswahl an typischen Anwendungsszenarien mit der Fachabteilung festzulegen und zu testen. Die Ergebnisse sind zu dokumentieren und mit den erwarteten Ergebnissen zu vergleichen, um eventuelles Fehlverhalten festzustellen. Ferner müssen alle Protokoll-Dateien, die während des Tests angelegt werden, auf Hinweise von Fehlfunktionen untersucht werden.
  • Integration in die Softwareverteilung, Test der Integration
    Oft müssen spezifische Paket- oder Dateiformate, in denen die Hersteller ihre Aktualisierungen zur Verfügung stellen angepasst werden, damit diese in einem automatischen Softwareverteil-System benutzt werden können. Dies gilt insbesondere dann, wenn während oder nach der Installation noch aktive Komponenten, wie beispielsweise Shell-Skripte ausgeführt werden müssen. Diese Anpassungen sind auf einem Testsystem auf ihre Wirksamkeit zu prüfen, bevor die Änderungen verteilt werden.

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:

  • Hat die Änderung bzw. der Patch das angestrebte Ziel erreicht?
  • Sind die Auftraggeber und die Anwender mit dem Ergebnis zufrieden?
  • Sind Seiteneffekte (Störungen bei nicht von der Änderung betroffenen Anwendungen) aufgetreten?
  • Wurden die veranschlagten Kosten, der geplante Aufwand und der Zeitplan eingehalten?

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:

  • Existiert ein definierter Prozess für Patch- und Änderungsmanagement?

  • Werden alle Änderungen von Hard- und Softwareständen und Konfigurationen vom Patch- und Änderungsmanagement gesteuert und kontrolliert?

Stand: 13. EL Stand 2013