CIOs müssen Notfallpläne laufend anpassen

Framework für mehr Sicherheit

Ist ein Notfallplan etabliert, besteht die größte Herausforderung darin, ihn aktuell zu halten. Notfall­planung muss als permanente Tätigkeit verstanden werden. Mit dem Architecture Development Lifecycle (ADM) liefert etwa das Architektur-Management-Framework TOGAF einen Lebenszyklus, in den Sicherheits- und Kon­ti­nuitätsanforderungen in verschiedenen Stufen eingepasst werden können.
Architecture Vision: Zu Beginn von Transformationsprojekten erfolgt zwingend eine erste Risikoeinschätzung. Auf Basis dieser initialen Einschätzung lassen sich Schwerpunkte in den nachfolgenden Phasen setzen.
Business Architecture: Schon bei der Ausgestaltung der künftigen betrieblichen Abläufe und IT-Services müssen sicherheitsrelevante Anforderungen klar definiert werden. Das Hauptaugenmerk gilt jenen Geschäftsprozessen, die als unternehmenskritisch eingestuft wurden und kritische Daten (etwa sensible Kundendaten) bearbeiten.
Information Systems & Technology Architecture: In diesen beiden Phasen werden die zukünftigen technischen Anforderungen an die IT-Services definiert. Zusammenhänge mit der bestehenden Architektur sind nachvollziehbar aufzubereiten. Mögliche neue oder geänderte Risiken müssen identifiziert werden. Mit anderen Worten: Die Service-Anforderungen werden mit den Fachbereichen unter Einbeziehung des Security Managers abgestimmt. Referenzkataloge wie die BSI-Grundschutzkataloge sparen hierbei Arbeit. So definieren die Grundschutzkataloge beispielsweise ein umfassendes Set an Bedrohungen, womit sich die neuen IT-Services abwägen und bewerten lassen. Die dort ebenfalls katalogisierten Maßnahmen dienen als Checkliste, um den Grundschutz sicherzustellen.
Opportunities and Solutions: Hier wird die Lösungsarchitektur konkretisiert und das initiale Projektportfolio definiert. Mögliche Lösungsszenarien müssen den Sicherheitsanforderungen entsprechen. Wiederum können die in den öffentlich verfügbaren Grundschutzkatalogen definierten, bausteinartigen Maßnahmen dabei unterstützen, ein ausgewogenes Set an Sicherheitsvorkehrungen zu treffen. Beispiele für derartige Maßnahmen sind: Empfehlungen für Zutritts- oder Zugriffsregelungen, organisatorische Regelungen für das Personal oder technische Sicherungsmöglichkeiten für Gebäude, Hardware oder Software.
Migration Planning: Die Migrationsplanung befasst sich mit der finalen Vorbereitung und Abstimmung zur Implementierung der konzipierten Lösung. Spätestens zu diesem Zeitpunkt sind auch Arbeitspakete zur detaillierten Er­arbeitung der Sicherheitsarchitekturen zu definieren und deren Ausführung vorzusehen.
Implementation Governance: In dieser Phase ist dafür Sorge zu tragen, dass die Umsetzung der IT-Services den vereinbarten Sicherheits-Levels entspricht. Die operativen Prozesse für den Betrieb der Services müssen durch Schulungen vermittelt werden. Die erstellten Notfallpläne müssen der Umsetzung der Services entsprechen und ausreichend praktisch erprobt werden.
Architecture Change Management & Requirements Management: Die Verantwortlichen müssen Geschäftsprozesse und etablie­rte IT-Services laufend auf ihr Gefährdungspoten­zial überprüfen. Diese kontinuierliche Analyse und Bewertung muss von Notfalltests begleitet sein. Unzulänglich­keiten werden als Anforderungen definiert und im Rahmen des Requirements Management priorisiert und bewertet. Im Bedarfsfall läuten die Anforderungen wiederum einen neuen Transformationszyklus ein.

Gewappnet für den Ernstfall

Welches Framework auch immer in einem Unternehmen eingesetzt wird, um für den Ernstfall gewappnet zu sein: Die Integ­ration in ein zyklisches Vorgehensmodell zur Durchführung von Business-Transformation-Projekten stellt sicher, dass die BCM-Dokumentation nicht Gefahr läuft, sich als Insel­lösung im Elfenbeinturm von der tatsächlichen Ist-Architektur zu entfernen.
So wird garantiert, dass die Zusammenhänge zwischen den wesentlichen Gestaltungselementen jederzeit transparent sind und nachvollziehbar vorliegen, die Dokumentation kontinuierlich auf dem Laufenden gehalten werden kann, Verantwortlichkeiten für die Bewertung der Risiken klar definiert sind – und das Business Continuity Management kein zahnloser Tiger ist.
Verwandte Themen