Nach den vorangehenden Blogartikeln, die Grundlagen und der CMDB, geht es nun um den Change-Prozess als Kernelement der IT-Serviceprozesse.

Was ist der Change-Prozess?

In IT-Organisationen ist der Change- neben dem Incident-Prozess einer der absoluten Kernprozesse, da er in unterschiedlichen Formen, und zum Teil abgewandelt, überall dort zum Einsatz kommt, wo Veränderungen geplant und umgesetzt werden. Ein Change-Prozess verändert Bestehendes, führt Neues ein oder entfernt Bestehendes. Der Change-Prozess ist aus dem Bedürfnis entstanden, Veränderungen zu steuern und zu planen. Oftmals existiert er in drei typischen Ausprägungen, als regulärer, als Standard und als Emergency Change. Diese drei Varianten unterscheiden sich zum einen in der Dringlichkeit aber auch in der Abschätzbarkeit. Der reguläre Change ist immer im Voraus geplant und kann vor der Umsetzung beurteilt werden. Der Standard Change ist erprobt und seine Parameter sind bekannt. Der Emergency Change ist, wie der Name schon sagt, ein Notfallprozess, bei dem zuerst gehandelt und später geprüft wird. Ein weiterer wichtiger Aspekt sind die mit dem Change verbundenen Rollen des Change Managers und des Change Advisory Boards (CAB), die beide in die Bewertung und Freigabe eingebunden sind.

Wie kann der Change-Prozess die Sicherheit fördern?

Grundsätzlich gibt der Change-Prozess einen bestimmten Workflow vor. Wenn wir ihn auf die wichtigsten Elemente reduzieren, sind die folgenden Schritte die Hauptelemente:

Ist entschieden, dass es sich um einen «normalen» Change handelt, der dem vollständigen Prozess unterliegt, erfolgt die Bewertung und anschliessende Genehmigung, je nach Bewertung durch das CAB oder den Change Manager. Vorgängig muss der Change beschrieben worden sein, und die wichtigsten Attribute wie Auswirkung und Risiko, aber auch Dringlichkeit und Umfang (Änderungsklasse) müssen definiert werden. In vielen Fällen muss ab einem gewissen Umfang bzw. Risiko auch ein Rollback-Szenario und eine Risikobewertung vorliegen. In der Praxis lässt sich über diese ohnehin vorhandenen Informationen, auch direkt die Einbindung der IT-Security steuern. So können bereits im Rahmen der Genehmigung Auflagen definiert oder der Change aufgrund von Sicherheitsmängeln zurückgewiesen werden.
Bei Emergency Changes erfolgt die Bewertung und Genehmigung korrekterweise nachträglich, was zur Folge haben kann, dass Nacharbeiten in Auftrag gegeben werden müssen.

Bewertung von Changes

Als Beispiel hier eine Maske für die Erfassung eines Changes, wobei ein modernes ITSM-Tool den Workflow anhand der Felder Change Type (13), Risiko (6), Auswirkung (4) und weiterer Kriterien steuern kann.

Ist es nicht zu aufwendig, jeden Change so zu bearbeiten?

Ja, natürlich ist es in der Praxis viel zu aufwändig, jeden Change komplett zu beurteilen. Deshalb gibt es im Gesamtprozess auch Verzweigungen. Bereits bei der Erfassung wird zwischen «Normal» oder «Standard» unterschieden, wobei ein Standard Change (oder Service Request) vordefinierte und standardisierte Aufgaben umfasst, die immer wieder gleich umgesetzt werden. Diese können ohne den aufwändigen Prozess einfach durchgeführt werden und benötigen nur eine formale Genehmigung durch das Change Management oder können sogar ganz ohne Genehmigung auskommen.

Praktische Umsetzung, Stolpersteine und Fallen

In der Praxis sind eine Vielzahl von Anforderungen unterschiedlicher Stakeholder unter einen Hut zu bringen. Einerseits sollen Changes agil, flexibel und kurzfristig umgesetzt werden können, andererseits soll der Change-Prozess auch sicherstellen, dass sowohl «Security» als auch «Business Continuity» und «Availability» ihre Ziele erfüllen. Dies muss individuell gelöst werden. Das grösste Risiko von komplexen Prozessen besteht darin, dass sie umgangen werden. Die Kreativität der Mitarbeitenden, sich administrativen Aufgaben zu entziehen, ist oft gross und führt dann den Sinn des Prozesses ins Absurde.
Wir konnten schon beobachten, dass einfach alles als Emergency Change deklariert wurde und damit am regulären Prozess vorbeilief, oder auch dass Standard Changes so weit gefasst deklariert wurden, dass damit alles abgebildet werden konnte. All dies ist nicht zielführend. Deshalb ist es wichtig, auf einfache und verständliche Prozesse zu setzen, die wenig von den eigentlichen Aufgaben ablenken oder den Workflow unterbrechen.

Beispielsweise erlaubt das ITIL V4 Framework eine relativ freie Gestaltung der Value Streams und ermöglicht eine optimale Abbildung der Anforderungen. In der Praxis hat sich gezeigt, dass nur in wenigen Fällen eine explizite, vorgängige Genehmigung notwendig ist. Oft kann der Tool-Workflow anhand der angegebenen Kriterien vieles direkt freigeben. In diesen Fällen kann dennoch ein hoher Compliance Level erreicht werden, indem im Post Implementation Review nochmals explizit geprüft wird, ob die angegebenen Kriterien auch korrekt waren. Dies wiederum erlaubt dann steuernd einzugreifen.

Configuration Management Data Base (CMDB)

Die CMDB ist unsere wichtigste Datensammlung, vorausgesetzt, sie ist vollständig und aktuell. Wie bereits im vorhergehenden Artikel (CMDB und Risikobewertung) beschrieben, ist eine umfassende CMDB das Herzstück des gesamten ITSM aber auch der Cyber Defense. Ein Change benötigt in jedem Fall einen Verweis auf die betroffenen Configuration Items aus der CMDB, also auf Assets, Identities oder auch Systeme. Nur anhand der in diesen Objekten hinterlegten Klassifizierungen zu BCM und Security kann eine systematische Bewertung erfolgen.

Rollen

Typischerweise definiert man im Rahmen des Change-Prozesses drei Rollen

• Change Manager: Eine Person mit breitem IT-Wissen um die Klassifizierung der Changes sicherzustellen, aber auch jemand mit organisatorischen Fähigkeiten, um die Koordination zu gewährleisten. Nicht zuletzt ist auch ein Prozessverständnis z. B. bezüglich BCM und schlussendlich auch ein Bezug zur Security notwendig.
• Das Change Advisory Board (CAB) sollte ein entscheidungsfähiges Gremium sein, das in der Lage ist eventuelle betriebliche Auswirkungen und allgemeine Konsequenzen abzuschätzen. Das Management muss hier ebenso vertreten sein wie der CISO.

Es gibt eine weitere Rolle bzw. Gruppe, die mit besonderem Bedacht definiert werden muss:

• Das PIR Board: Das Post Implementation Review Board kommt immer dann ins Spiel, wenn nach einem Change ein Review notwendig erscheint. Den Entscheid, welche Changes dem PIR Board vorgelegt werden, kann aus Effizienzgründen der Change Manager treffen. Das PIR Board muss aber ebenso wie das CAB in der Lage sein, Entscheidungen zu treffen, wenn zum Beispiel zu viele Shortcuts verwendet werden oder Policies falsch interpretiert werden.

Post Implementation Review (PIR)

Der Post Implementation Review ist ein wertvolles Instrument, um einfache Changes durchzuführen und trotzdem Compliance sowie die Einhaltung von Regeln zu ermöglichen. Dies setzt jedoch voraus, dass der PIR nicht nur bei fehlgeschlagenen Changes angewendet wird, sondern auch erfolgreiche Changes überprüft werden, insbesondere  alle Emergency Changes im Hinblick auf die Einhaltung der relevanten Prozessschritte und Vorgaben.

Fazit: ein richtig angewandter Change-Prozess hilft die Security zu verbessern

Ein richtig eingesetzter Change-Prozess führt zum Ziel

• Security by Design zu erreichen
• die Awareness der Beteiligten zu verbessern und
• erfüllt auch die Anforderungen an Compliance und Dokumentation.

Wenn mit den Elementen der Klassifizierung und den Möglichkeiten von Standard Changes korrekt gearbeitet wird, steht der Aufwand in einem guten Verhältnis zum Nutzen. Der Nutzen eines optimalen Change-Prozesses zeigt sich langfristig sowohl operativ in der Termintreue und der guten technischen Umsetzung, aber auch mit verbesserter Security und Resilienz.

Wie kann terreActive Sie unterstützen?

Wir unterstützen Sie gerne bei der Erstellung von Gesamtkonzepten und natürlich auch bei den Anforderungen für die Integration in den SOC-Betrieb.

Darüber hinaus berät Sie unser Audit- und Consulting-Team bei der Optimierung Ihrer Sicherheitsinfrastruktur und dem Aufbau der Cyber Resilienz.

In dem vierten und letzten Teil unserer Blogserie werden wir auf einzelne Aspekte der Organisation eingehen. Typische Prozesse wie Incident und Eskalation werden im Detail betrachtet und in den Kontext der Cyber Security gestellt.