dark

Business-Impact-Analyse mit nur 5 Slides

Avatar

Um zukünftige Schadensszenarien begegnen zu können, müssen Unternehmen im Kontext eines Notfall- bzw. Risikomanagements eine Erhebung ihrer kritischen IT-Systeme durchführen, insbesondere im Rahmen von IT-Architektur-Reviews, Assessments, Audits oder weil die Compliance dies erfordert. In der Praxis ist eine solche Betrachtung viel zu umfänglich. Eine Business-Impact-Analyse kann jedoch mit vereinfachtem Umgang auf fünf Schaubilder reduziert werden. 

Eine gängige und anerkannte Methode für die Erhebung kritischer IT-Systeme ist das Notfallmanagement nach BSI 100-4. Der Umfang dieses Vorgehens betrachtet jedoch nicht nur die IT-Infrastruktur, sondern eben ein unternehmensweites Notfallmanagement inklusive Organisation und Prozesse. Nicht selten ist ein Analyseprojekt in diesem Kontext bis zu mehrere Hundert PT groß. In der Praxis ist diese Betrachtung viel zu umfänglich, da man im ersten Schritt nur den Technologie-Stack betrachten möchte. Sofern Prozesse und Organisation nicht im Fokus stehen, kann eine Business-Impact-Analyse (BIA) mit vereinfachtem Umfang auf fünf Schaubilder reduziert werden.

BSI 100-4 als Basis für die Erhebung

Der Vorteil einer BIA liegt darin, dass ein strukturierter Blick auf IT-Systeme oder IT-Verbunde durchgeführt werden kann und wesentliche Informationen zur Kritikalität einzelner Fachanwendungen oder Technologiekomponenten ermittelt werden können. Im Gegensatz zur üblichen Kritikalitätseinstufung, die bei vielen IT-Dienstleistern existieren und in der Regel nur Systeme im Kontext eines Kerngeschäftsprozesses und deren zugeordneten IT-Systemen berücksichtigen, prüft eine BIA-Erhebung die Auswirkung eines IT-Systemausfalles auf folgende Schadensszenarien:

  • die finanzielle Auswirkung
  • die Beeinträchtigung der Aufgabenerfüllung
  • die Auswirkung auf Gesetze, Vorschriften und Verträge
  • die Auswirkungen auf das Image des Unternehmens
  • die Auswirkungen auf die persönliche Unversehrtheit[1]

Fachanwendungen sind Informationssysteme die Kernprozesse, Managementprozesse oder Unterstützungsprozesse innerhalb eines Unternehmens abbilden. Unterhalb der Fachanwendungen muss ein Technologie-Stack existieren, damit Informationssysteme aufgebaut, betrieben und überwacht werden können. Dieser Technologie-Stack besteht wiederum aus Technologiekomponenten wie Hardware (Server, Netzwerk, Storage, Backup etc.) und Software (Betriebssysteme, Middleware, Datenbanken etc.). Im Rahmen der BIA-Erhebung wird jede relevante Fachanwendung und bzw. oder Technologiekomponente auf jedes der vier vorab genannten Schadensszenarien geprüft. Maßgeblich dabei ist die Ausfallzeit (< 4 Std, < 24Std, < 3Tage, < 3-10 Tage, > 10 Tage). Alle Daten werden anschließend in einer umfangreichen Dokumentation mit Word oder Excel erfasst und nachfolgend analysiert. Der BSI-Standard zum Notfallmanagement wird aktuell überarbeitet und zukünftig in BSI200-4 fortgeführt.

Die Anwendungs- und Technologielandkarte

Zur Erfassung und komprimierten Darstellung einer BIA auf fünf Slides muss zuerst eine Aufnahme der IT-Architektur bestehend aus Fachanwendungen und Technologien erfolgen. Wesentliche Elemente dieser Darstellung sind:

  • Organisationseinheiten
  • Systemkritikalitäten
  • Fachanwendungen
  • Technologiekomponenten
  • Grad der Anwendungskomplexität (sofern bekannt)
  • Zusatzinformationen:
    • IT-Service[2] wird extern erbracht
    • IT-Service in Ablösung
    • IT-Service in Entwicklung
    • keine relevante Komponente im Kontext der Kritikalität[3]

Die Zuordnung von Fachanwendungen zur Organisationseinheiten muss dabei wie folgt umgesetzt werden:

  • Fachanwendungen, die nur durch eine Organisationseinheit verwendet werden, werden nur dort einmalig aufgeführt.
  • Fachanwendungen die durch mehrere Organisationseinheiten verwendet werden, müssen jeder Organisationseinheit einzeln zugewiesen werden[4].
  • Fachanwendungen, die alle Fachbereiche nutzen, gehören in die Rubrik Übergreifend.

Im Kontext der Bestandsaufnahme wird die grundsätzliche Kritikalität der Fachanwendungen und Technologiekomponenten erhoben. In diesem Zusammenhang werden die Anwendungen mit einem Farbcode entsprechend eingefärbt (Abb. 1).

Übersicht der Systemkritikalitäten (Abb.1)[6]

Diese Darstellung bildet dann die Grundlage der BIA-Erhebung. Als Zwischenformat empfiehlt sich hier die Nutzung einer Excel-Liste zur Sammlung und Abstimmung aller Fachanwendungen und Technologiekomponenten. Nach Abstimmung der Liste kann dann die grafische Landkarte innerhalb von PowerPoint erstellt werden. Diese Landkarte bildet die Basis für die Durchführung einer BIA-Light. (Abb. 2).

Beispiellandkarte_Technologie + Fachanwendungen (Abb. 2)[6]

BIA-Erhebung

Die Erfassung aller wesentlichen Informationen gemäß der im Modul Business-Impact-Analyse vorgegebenen Schadensszenarien erfasst je Schadensszenario vier Auswirkungsgrade, die dort entsprechend beschrieben sind:

  1. Niedrig
  2. Mittel
  3. Hoch
  4. Sehr hoch

Um ein direktes Mapping zu den drei Farbcodes in der Landkarte gemäß (Abb. 2) zu bekommen, werden die Auswirkungsgrade Hoch und Sehr hoch zusammengefasst. Die obige Variante beschreibt dabei die genaue Variante. Das Problem liegt in der Regel darin, hier eine adäquate Quantifizierung des Schadens zu ermitteln, zum Beispiel den finanziellen Schaden. Es empfiehlt sich daher einen eher pragmatischen Ansatz zu wählen. Am besten auf Basis einer direkten Experteneinschätzung des Fachbereiches beziehungsweise der IT. Die BIA-Erhebung unterscheidet diese Aufnahme zusätzlich in zwei Szenarien:

  • Kalenderjahr: folglich der normale Geschäftsbetrieb
  • besondere Termine und Ereignisse

Hier empfiehlt sich ebenfalls zur Vereinfachung immer die höchstmögliche Auswirkung einmalig zu erfassen. Am besten auf Basis eines gemeinsamen Workshops mit direkter Anpassung des Farbcodes je Schadensszenario, in Abhängigkeit des Auswirkungsgrades für jede Fachanwendung beziehungsweise Technologiekomponente.

Bevor nun die Farbcodierung und damit die Erstellung der BIA beginnt, muss eine Anpassung der Anwendungs- und Technologielandkarte erfolgen. Und zwar müssen alle vorab kritischen Systeme (Rot), sowie alle unkritischen Systeme (Grün) ausgeblendet werden, indem sie schwarz ausgefüllt werden, denn

  1. kritische Systeme bleiben auch immer kritisch und
  2. unkritische Systeme werden niemals kritisch.

Nun ist die Basis für die eigentliche BIA-Light geschaffen worden und die Erhebung kann beginnen.

Schadensszenario: Finanzielle Auswirkung

Betrachtet man nun die erste Folie zur BIA-Light, stellt man fest, dass eine weitere Legende dazugekommen ist. Hier wird grafisch vereinfacht dargestellt, welche identifizierten, neuen, kritischen Fachanwendungen bzw. Technologiekomponenten nach welcher Laufzeit kritisch[5] werden. Dazu werden in dem anonymisierten Beispiel einfach Farbpunkte an das jeweilige Item platziert und damit farblich kenntlich gemacht. Auch hier wird wieder vereinfacht und die Ausfallzeit wie folgt kategorisiert bzw. gebündelt:

  • kritisch < 1 Tag
  • kritisch 1 – 10 Tage
  • kritisch > 10 Tage

Falls dies nicht dem Wunsch oder Anspruch genügt, kann hier detaillierter verfahren werden (Abb. 3). Hier wurden zum Beispiel keinerlei finanzielle Risiken aus Sicht der IT (Technologiekomponenten) erfasst, sondern ausschließlich kritische Fachanwendungen neu identifiziert. Dieses Vorgehen wird nun für die restlichen drei Schadensszenarien wiederholt angewendet.

BIA: Finanzielle Auswirkung (Abb. 3)[6]

Schadensszenario: Beeinträchtigung der Aufgabenerfüllung

In (Abb.4) erkennt man wie massiv die Aufgabenerfüllung bei längeren Laufzeiten eingeschränkt wird. Dies ist typisch für Unternehmen mit hoher Kundeninteraktion oder in den Bereichen Fertigung, Forschung und Entwicklung. Zu sehen ist ein massiver Anstieg an zusätzlichen kritischen Fachanwendungen im Bereich 1-10 Ausfallzeit. Nach ungefähr zehn Tagen Ausfallzeit hat sich die Anzahl der vorab kritisch identifizierten Anwendungen aus (Abb. 2) nun fast verdoppelt.

BIA: Beeinträchtigung der Aufgabenerfüllung (Abb. 4)[6]

Schadensszenario: Verstoß gegen Gesetze, Vorschriften und Verträge

Im Vergleich zu den beiden vorherigen Schadensszenarien ist hier zu sehen, dass generell weniger Objekte betroffen sind. Bei Unternehmen, die Compliance-Standards wie VAIT, BAIT oder KAIT unterliegen, würde es bezüglich der Menge etwas anders aussehen.

BIA: Auswirkung auf Gesetze, Vorschriften, Verträge (Abb. 5)[6]

Zu guter Letzt zeigt die Betrachtung des Imageschadens, dass auch hier relativ viele zusätzliche Fachanwendungen und Technologiekomponenten betroffen sind. Dies ist für Unternehmen mit starker öffentlicher Wahrnehmung und davon abhängigen Geschäftsmodellen sehr relevant.

BIA: Auswirkungen auf das Image (Abb. 6)[6] 

Was nun?

An diesem Punkt stellt sich die Frage was man mit diesen erhobenen, prägnanten Informationen eigentlich macht. Die Tatsache, dass es weitere, kritische Informationssysteme gibt, kann und muss dazu genutzt werden, die dortigen aktuell verwendeten Backup- und Recovery-Prozeduren zu überprüfen. Die BIA-Light liefert einen guten Fahrplan mit abgeleiteter Priorisierung, um aktuell nicht erfasste und behandelte Fachanwendungen und bzw. oder Technologien zu behandeln.

Für Fachanwendungen kann dies bedeuten:

  • die IT-Architektur hochverfügbarer zu gestalten
  • ein adäquates Monitoring bereitzustellen, um kritische Systemzustände frühzeitig zu erfassen
  • Fachtests zu automatisieren
  • die Wiederherstellung einer konsistenten Anwendung regelmäßig zu prüfen oder zumindest Stichproben durchzuführen

Für Technologiekomponenten bedeutet dies:

  • hochverfügbar zu sein
  • wesentliche Statusinformationen für das Monitoring zu liefern
  • Technologien zu konsolidieren

Weiterhin hat diese eher kurze aber sehr detaillierte Aufnahme den Vorteil, dass erste Schritte zur Einführung von Business-Continuity-Management (BCM) erfolgt sind. Dies wird immer relevanter, da mehr und mehr Branchen gesteigertes Interesse auf ein BCM legen werden.

Fazit:

Das hier aufgezeigte Vorgehen spart Zeit und Geld, um einen ersten Blick auf das Unternehmen und dessen IT-Systeme sowie deren Kritikalität zu erlangen. Die Darstellung ist managementtauglich und kann auch von Nichttechnologen verstanden und angewendet werden. Um eine genauere Übersicht zu geben, kann neben den vorgestellten Slides eine weitere Vertiefung im Rahmen von Analysen vorgenommen werden, die zum Beispiel die veränderten Kritikalitäten im Kontext der Ausfallzeit noch einmal aufbereitet darstellen. Ausgehend vom Normalzustand in (Abb.2) ist eine tabellarische Übersicht der kritischen Fachanwendungen und Technologiekomponenten, die zusätzlich je Schadenszenario hinzukommen, sinnvoll.

Gerd Herbertz

Gerd Herbertz, Jahrgang 1969, ist ausgebildeter Dipl. Ing (FH) Elektrotechnik. Bei adesso verantwortet er im Geschäftsfeld IT-Management Consulting das Competence Center Infrastruktur & Technologie, welches sich mit den Technologiestacks Microsoft und Linux beschäftigt. Speziell im Linux-Umfeld liegt der Fokus auf Konzeption, Aufbau und Übergabe von DevOps-Umgebungen im Rahmen von Kundenprojekten. Neben dem reinen Engineering und der Technologieberatung wird das Portfolio des Competence Centers durch IT-Management- und Strategieberatung abgerundet.

 

 

[1] Für BIA-Erhebungen bei IT-Dienstleistungsunternehmen ist dies in der Regel nicht erforderlich

[2] Ein IT-Service wird durch die Kombination von Informationstechnologie, Menschen und Prozessen gebildet

[3] Dies bezieht sich auf Basistechnologien, die ohne einen entsprechenden Nutzungskontext keine Kritikalität haben (also z.B. Datenbanken, Client/Server-Software)

[4] Bei hochkomplexen Umgebungen muss ggf. vereinfacht werden, damit die Darstellung nicht überladen wird

[5] Entspricht dem Auswirkungsgrad „hoch/sehr hoch“ -> Farbcode: „Rot“

[6] Quelle: adesso AG

Total
0
Shares
Previous Post

Loggen mit Struktur

Next Post

OpenJDK Amazon-Corretto

Related Posts