Bundesamt für Sicherheit in der Informationstechnik

M 2.422 Umgang mit Änderungsanforderungen

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

Verantwortlich für Umsetzung: Änderungsmanager

Die Anträge für Patches und Änderungen sollten nach einem festgelegten Vorgehen eingereicht und bearbeitet werden.

Einreichen und Erfassen von Änderungsanforderungen

Zunächst müssen alle Änderungsanforderungen (Request for Changes, RfCs) erfasst werden. Damit alle notwendigen Informationen vorliegen, empfiehlt es sich, den Antragstellern ein Formular zur Verfügung zu stellen (siehe Muster einer Änderungsanforderung aus den Hilfsmitteln zum IT-Grundschutz).

Dieser Antrag dient ebenfalls dazu, die Änderung abzustimmen (siehe auch: M 2.427 Abstimmung von Änderungsanforderungen ). Wenn beispielsweise eine Änderung beantragt wurde, um ein bestehendes Problem zu lösen, sollte auch eine entsprechende Referenz auf das Problem, meist eine Erfassungsnummer in einer Datenbank, mit dokumentiert werden.

Nicht jeder Änderungsantrag wird innerhalb des Patch- und Änderungsprozesses als normale Änderung behandelt. Einige routinemäßige Änderungen, die klar umschrieben sind, standardisiert durchgeführt werden und dennoch eine Änderung betreffen, können wie eine Serviceanfrage behandelt werden. Eine Serviceanfrage wäre zum Beispiel das Zurücksetzen eines Passworts und, bezogen auf das Patch- und Änderungsmanagement, eine Änderung am Login-Banner eines Dienstes (der Text mit dem sich der Dienst bei einem Verbindungsaufbau über die Netzwerkschnittstelle meldet).

Änderungsanforderungen filtern und akzeptieren

Nachdem eine Änderungsanforderung erfasst wurde, wird sie durch den Änderungsmanager (Change Manager) kontrolliert. Dabei sollen nicht durchführbare, unnötige oder doppelte Änderungsanforderungen ermittelt werden. Solche Anträge sollten unter Angabe des Grundes abgelehnt werden. Die Antragsteller haben damit die Möglichkeit, die Änderungsanforderung zu überdenken und umzuformulieren.

Wenn eine Änderungsanforderung akzeptiert wurde, werden die Informationen in einem Änderungsdatensatz aufgenommen, um die Änderung durchzuführen. Der Datensatz kann in einem Software-Werkzeug, auf Papier oder auch in einer selbst erstellten Datenbank erfasst werden. Im weiteren Verlauf werden dem Änderungsdatensatz noch die nachstehenden Informationen hinzugefügt:

  • Ermittelte Priorität und Kategorie,
  • Beurteilung der Auswirkungen und die erforderlichen Ressourcen,
  • Empfehlungen des Änderungsmanagers bzw. des Änderungsberatungsausschusses (Change Advisory Boards, CAB s),
  • Datum und Uhrzeit der Autorisierung,
  • Geplantes Datum für die Umsetzung der Änderung,
  • Aktuelles Datum und aktuelle Uhrzeit der Änderung,
  • Datum der Auswertung,
  • Testergebnisse und aufgetretene Probleme,
  • Begründung für eine eventuelle Ablehnung des Vorschlags bzw. des Antrags und
  • Ablaufplan und Auswertungsdaten.

Änderungsanforderungen klassifizieren (Priorität und Kategorie)

Nachdem eine Änderungsanforderung akzeptiert worden ist, muss sie priorisiert und kategorisiert werden:

  • Die Priorität beschreibt, wie wichtig eine Änderung ist und leitet sich von der Dringlichkeit und den Auswirkungen ab. Wenn es sich um die Korrektur eines bekannten Fehlers handelt, der schon einmal im Rahmen des Patch- und Änderungsmanagements eingestuft worden ist, wird die Priorität unter Umständen bereits mit übergeben. Dabei sollten die Priorität der Änderung jedoch immer noch einmal vom Änderungsmanager überprüft und gegebenenfalls korrigiert werden. Gleiches gilt für Sicherheitspatches oder Updates, die von der Informationssicherheit beantragt werden. Die endgültige Priorität wird jedoch innerhalb des Änderungsmanagements unter Berücksichtigung der anderen in Bearbeitung befindlichen Änderungsanforderungen festgelegt.
  • Die Kategorie wird vom Änderungsmanager auf der Grundlage von den zu erwartenden Auswirkungen und benötigten Ressourcen bestimmt.

Die aus Priorität und Kategorie zusammengesetzte Klassifizierung legt die weitere Bearbeitung der Änderungsanforderung fest und beschreibt somit die Bedeutung der geplanten Änderung.

Prioritäten werden vom Änderungsmanager für eine Änderung vergeben und sind in unterschiedliche Prioritätsstufen eingeteilt, wobei das Sicherheitsmanagement ein Einspruchsrecht gegen zu niedrige bzw. falsche Priorisierung erhalten sollte. Es können beispielsweise die folgenden Prioritätsstufen vom Änderungsmanagement vergeben werden:

  • höchste Priorität:
    Eine Änderungsanforderung mit höchster Priorität bezieht sich z. B. auf ein Problem, das für die Zielgruppe im Rahmen der Nutzung wichtiger IT-Dienste erhebliche Schwierigkeiten verursacht. Auch dringend benötigte Anpassungen der IT (z. B. um eine Sicherheitslücke zu schließen, für die ein Wurm im Internet kursiert) werden mit dieser Priorität versehen. Änderungen dieser Priorität werden auch "Urgent Changes" genannt. Diese Änderungen unterscheiden sich von denen mit hoher und normaler Priorität dadurch, dass in diesem Fall die benötigten Ressourcen sofort zur Verfügung gestellt werden sollten. Eine Dringlichkeitssitzung des CAB oder des Informationssicherheitsmanagement-Team kann ebenfalls erforderlich sein. Wenn Änderungen in diese Priorität eingestuft werden, können alle früheren Planungen Verzögerungen erfahren oder vorerst eingestellt werden.
  • hohe Priorität:
    Diese Priorität beschreibt z. B. eine Änderung aufgrund einer schwerwiegenden Störung oder hängt mit anderen dringenden Aktivitäten zusammen. Diese Änderung erhält bei der nächsten Sitzung des CAB oberste Priorität bei der Zuordnung von Ressourcen für Test- und Durchführung.
  • normale Priorität:
    Eine Änderung mit normaler Priorität hat keine besondere Dringlichkeit oder größere Auswirkung, darf aber nicht auf einen späteren Zeitpunkt verschoben werden. Im CAB erhält diese Änderung bei der Zuteilung von Ressourcen normale Priorität.
  • niedrige Priorität:
    Eine Änderung mit niedriger Priorität ist erwünscht, hat jedoch Zeit, bis sich eine geeignete Gelegenheit ergibt (z. B. eine Folgeversion oder eine geplante Wartung).

Kategorien werden in der Regel vom Änderungsmanagement zugewiesen, wobei auch hier das Sicherheitsmanagement ein Einspruchsrecht gegen eine zu niedrige Kategorisierung erhalten sollte. Kategorien sollen eine Einschätzung darüber liefern, wie sich die Änderung auswirkt und wie die Institution durch den Änderungsprozess belastet wird. Beispielsweise können nachstehende Kategorien vergeben werden:

  • geringfügige Folgen:
    Eine Änderung dieser Kategorie erfordert wenig Aufwand. Der Änderungsmanager kann diese Art von Änderungen genehmigen, ohne dass er sie dem CAB vorlegen muss.
  • erhebliche Folgen:
    In diese Kategorie fallen Änderungen, die einen erheblichen Aufwand erfordern und weitreichende Auswirkungen auf die IT-Dienste zur Folge haben. Solche Änderungen werden im CAB besprochen, um den erforderlichen Aufwand zu definieren und das Risiko zu minimieren. Im Vorfeld und zur Vorbereitung der Sitzung wird zunächst die notwendige Dokumentation an die Mitglieder des CAB sowie gegebenenfalls auch an einige IT-Spezialisten und Entwickler verschickt.
  • weitreichende Folgen:
    Eine Änderung dieser Kategorie erfordert einen großen Aufwand. Für eine solche Änderung benötigt der Änderungsmanager zunächst die Autorisierung durch das Sicherheitsmanagement-Team. Anschließend muss die Änderung dem CAB noch zur Beurteilung und weiteren Planung vorgelegt werden.

Planung

Die am Patch- und Änderungsmanagementprozess beteiligten Mitarbeiter planen die Umsetzung für alle angenommenen Änderungen. Bei Bedarf geschieht dies zusammen mit dem CAB. An dieser Stelle des Patch- und Änderungsmanagementprozesses ist es wichtig, die dazu benötigten technischen und personellen Ressourcen zu berücksichtigen und die Auswirkungen auf den Betrieb während der Durchführung der Änderung abzuschätzen. Die folgenden Aspekte sollten mindestens berücksichtigt werden:

  • Verfügbarkeit der betroffenen IT-Systeme,
  • Zuverlässigkeit und Wiederherstellbarkeit der betroffenen IT-Dienste,
  • Planung des Notfallmanagements für die betroffenen IT-Dienste,
  • Blackout-Pläne, also Notfallpläne für die Reaktion auf unerwünschte Effekte durch die Änderung,
  • Datensicherungsverfahren,
  • Mögliche Auswirkungen der Änderungen auf andere IT-Dienste (Seiteneffekte),
  • benötigte technische und personelle Ressourcen und deren Kosten
  • benötigte Genehmigungen wie
    • finanzielle Genehmigungen, wenn beispielsweise ein kostenpflichtiges Update eingespielt werden oder auf ein Folgeprodukt (Upgrade) gewechselt werden muss.
    • technische Genehmigungen, weil beispielsweise zusätzliche IT-Systeme beschafft werden müssen.
    • geschäftliche Genehmigungen, weil beispielsweise die Aktualisierung Auswirkungen auf Zulieferer hat.
  • Anzahl und Verfügbarkeit der benötigten IT-Spezialisten,
  • gewünschte zeitliche Umsetzung einer Änderung,
  • Konsequenzen für die Nutzung der IT-Dienste und daraus resultierende Anpassungen an Service-Level-Vereinbarungen,
  • eventuelle Konflikte mit anderen Änderungen.

Prüffragen:

  • Gibt es ein festgelegtes Verfahren, wie Anträge für Patches und Änderungen eingereicht und bearbeitet werden?

  • Werden alle Änderungsanforderungen (RfCs) erfasst und dokumentiert?

  • Erfolgt eine Kontrolle der erfassten Änderungsanforderungen durch den Änderungsmanager?

  • Wird jede Änderungsanforderung priorisiert und kategorisiert?

  • Werden für die jeweiligen Prioritäten die benötigten Ressourcen zur Verfügung gestellt?

Stand: 13. EL Stand 2013