Einführung eines integrierten IT Service Continuity Management

Einführung eines integrierten IT Service Continuity Management Dipl. Informatiker Alexander Haasper, Management Consultant Einführung eines integrierten IT Service Continuity Management (ITSCM) Dipl. Informatiker Alexander Haasper IT Service Continuity Management – Gesetzliche Pflicht oder doch mehr Nutzen? 1. Gesetzliche Anforderungen und steigende IT-Komplexität sind die wesentlichen Treiber für ITSCM1 Mit dem Inkrafttreten des KonTraG, dem Gesetz zur Kontrolle und Transparenz im Unternehmensbereich, werden seit 1998 an alle Unternehmen grundlegende Anforderungen an IT Service Continuity Management gestellt. Der Gesetzgeber hat in diesem Zug die Verantwortung für die Funktionsfähigkeit der internen Kontrollsysteme und die Früherkennung von Risiken bei der Unternehmensleitung verankert. Bei fahrlässigem Handeln ist die Unternehmensführung persönlich haftbar. Mit dem Sarbanes- Oxley-Act (SOX) haben im Jahr 2002 die USA entsprechende Anforderungen an die Kontrollsysteme definiert, welche auf die Korrektheit der publizierten Finanzdaten abzielen. Bei vorsätzlichen Vergehen durch das Executive Management sind Haftstrafen von bis zu 20 Jahren vorgesehen. Im Bankenbereich ist zudem BASEL II in aller Munde. Hier wirkt sich eine adäquate operationale Risikovorsorge unmittelbar auf die erforderliche Eigenkapitalausstattung und damit auch auf Kosteneinsparungen aus. Außerdem fordert die BaFin über die Mindes- tanforderungen an das Risikomanagement (MaRisk) sehr präzise einen geordneten Wiederanlauf von IT-Infrastruktur und Geschäftsprozessen. Glaubt man den einschlägigen Gartner-Studien, dann geht die größte Gefahr für eine das Unternehmen in der Existenz gefährdenden IT-Katastrophe von den eigenen Mitarbeitern aus. Sei es durch Fehler bei der Administration oder bewusste Sabotage. Im Vergleich dazu weisen in der Regel die Risiken aus dem Bereich Infrastruktur bzw. Standortrisiken (Unwetter, terroristische Anschläge, etc.) weit geringere Wahrscheinlichkeiten auf. Durch die heute vorherrschenden oft mehrschichtigen Client-Server-Architekturen ist der Vernetzungsgrad der IT über die Jahre extrem gestiegen. Dies hat die Komplexität und damit die Verletzbarkeit der IT entsprechend erhöht. Neue Ansätze wie z.B. Cloud Computing verschärfen diesen Trend weiter. Insofern ist das Wissen in der Organisation über die Abhängigkeiten in ihrer Service-Architektur und deren Flexibilität inzwischen ein entscheidender Erfolgsfaktor für die Umsetzung von neuen Geschäftsanforderungen. Vor diesem Hintergrund wundert es doch ein wenig, dass das Thema ITSCM in vielen Unternehmen immer noch als reine Pflichtaufgabe verstanden wird, um den gesetzlichen Anforderungen Rechnung zu tragen. 2. Typische Ausgangssituation für ITSCM Warum ist das so? Warum wird ITSCM nicht als Kür veranstaltet, um weitere Synergien zu heben? 1 In einigen Unternehmen werden ITSCM und Business Continuity Management (BCM) synonym verwendet. Dieser Beitrag geht davon aus, dass die Mitarbeiter- und Gebäudesicherheit (ausgenommen Rechenzentren) allein zum Thema BCM gehört. ITSCM bezieht sich auf die Recovery-Fähigkeit bei IT-relevanten Notfälle und Katastrophen. ITSCM ist nach diesem Verständnis eine Spezialdisziplin von BCM. 1 Einführung eines integrierten IT Service Continuity Management Dipl. Informatiker Alexander Haasper, Management Consultant Es gibt dazu wahrscheinlich in jeden Unternehmen anders gelagerte Historien und Voraussetzungen. Dennoch lassen sich für die innerhalb der letzten 6 Jahre durchgeführten zahlreichen Projekte einige immer wiederkehrende Ausgangssituationen in den Unternehmen beobachten: • Das Sicherheitsniveau ist oftmals nur auf der Ebene von Redundanz der IT- Infrastruktur festgelegt. Ein Business Case ITSCM ist nicht erarbeitet worden. • Investitionen in ITSCM erfolgen in der Regel erst nach „mittleren“ Katastrophen oder als Folge von entsprechenden Auflagen durch die Revision. • Die Rolle des IT-Notfall-Managers ist hinsichtlich der Verantwortung nur unzureichend definiert. • Die Verfahren für den Notfall sind zu komplex oder im Notfall selbst vermutlich nicht verfügbar oder nicht ausreichend erprobt. • Es existiert kein standardisiertes bereichsübergreifendes Tool für den Wiederanlauf • Die Recovery-Verfahren einzelner Services sind nicht aktuell oder nicht ausreichend standardisiert. • Recovery-Tests werden in der Regel auf einzelne IT Services begrenzt durchgeführt. Rein organisatorischen Tests der Notfallorganisation finden nicht statt. • Die Aktualisierung der Verfahren zum Wiederanlauf der IT ist nicht in den Change- Prozess des Betriebs und der laufenden Projekte integriert, so dass die Belastbarkeit der Verfahren bei hoher Veränderungsdynamik ein Risiko darstellt. Die Ausgangssituation stellt sich somit oft als ein komplexes Geflecht aus IT-, Prozess- und Organisationsproblemen dar, welche häufig aber immer noch als reines Tool- oder Hardware-Problem verstanden werden. Doch will man den prozessualen Risiken von Fehlbedienung und Sabotage begegnen, reicht es nicht aus, dass man in sein Auto weitere Airbags einbaut. Man braucht vielmehr ein Verfahren, dass sicherstellt, dass das Auto mit seinen Insassen bei einem Notfall zeitnah und zuverlässig von der Pannenhilfe und den ärztlichen Notdiensten erreicht und zielgerichtet versorgt wird, so dass der Service „individuelle Mobilität“ wieder „bei bester Gesundheit“ verfügbar ist. IT Continuity Management Fachbereich Abhängigkeit nimmt von oben nach unten zu Unternehmen Business/Anwender – fordern Anwender- dienste Office Messaging Daten- SAP banken eBusiness (Applikationen) System- Verzeichnisdienste, Backupsoftware, Virenscanner, Softwareverteilung, applikationen Systemmanagement usw. Basisdienste DNS, DHCP, WINS IT-Abteilung – liefert Konzeption Erhebung & & Analyse Basis-SW Betriebssysteme Etablierung Basis-HW Serversysteme, Storagesysteme, Backuplibraries, Router, Switches, Firewalls usw. Infrastruktur Betriebstechnisches Rechnerumfeld (Strom, Klima, Verkabelung usw.) Gebäude Bauliche Strukturen (Lage, Zutritt, baulicher Zustand usw.) Abbildung 1“House of Services“ 2 Einführung eines integrierten IT Service Continuity Management Dipl. Informatiker Alexander Haasper, Management Consultant 3. Framework des integrierten ITSCM-Ansatzes Im der obigen Abbildung des „House of Services“ sind für den integrierten Ansatz die Ebenen der für das ITSCM relevanten Services dargestellt. In der Regel wird zum Start von ITSCM-Vorhaben mit den Business-Bereichen im Rahmen einer Business-Impact- Analyse die Kritikalität der Services priorisiert. Aufgrund der Abhängigkeiten in der Service-Architektur pflanzen sich diese Prioritäten bis auf die Abhängigkeiten in die untersten Ebenen bis zur Gebäude-Sicherheit fort. Soll die Lösung für die oben beschriebenen Herausforderungen wirklich grundlegend erfolgen und nachhaltige Verbesserung bewirken, so sollten folgende Bausteine in eine integrierte ITSCM-Lösung einfließen: • Business-Impact-Analyse (insb.