Montag, den 19.06.2017

(Un)informiert über IT Risiken?

IT Information Management als Basis für Enterprise Risk Management

Download als PDF

Governance, Risk Management und Compliance – GRC umfasst drei wichtige Handlungsebenen erfolgreicher Unternehmensführung. Ohne eine genaue Definition und Abgrenzung der einzelnen Bereiche vornehmen zu wollen, soll der Schwerpunkt im Folgenden auf das Risikomanagement gelegt werden. Risikomanagement verstehen wir in diesem Zusammenhang als der Umgang mit bekannten und unbekannten Risiken durch definierte Risikoanalysen. Dazu zählen das frühzeitige Auseinandersetzen mit Risiken, die Bereitstellung von Strategien zur Risikominimierung und das Vorbereiten von Schadensfallpuffern bei Risikoeintritt.

Im Rahmen des Risiko Management identifiziert, analysiert und bewertet das Unternehmen seine Risiken. Es existieren viele Ansätze und Normen. Zentral sind sicher die Normen der ISO 31000. 

Während die in der ISO 31000 beschriebenen Grundsätze und Verfahren grundsätzlich in allen Organisationsbereichen Anwendung finden können, steht mit AXELOS Management of Risk (M_o_R) ein weiterer methodischer Ansatz zur Verfügung, der mit Blick auf die weiter unten beschriebene Aufgabenstellung ausgesprochen praktikabel erscheint. Der Zweck des M_o_R liegt im Wesentlichen darin, Organisationen ein effektives Framework für das Risikomanagement in der IT zur Verfügung zu stellen. 

In Anlehnung an M_o_R wollen wir uns im weiteren Verlauf mit einer der zentralen Herausforderungen in der Enterprise IT auseinandersetzen: Der Verfügbarkeit und Sicherheit von Datenbanken.

Datenzugriff und Datenbanken stellen einen wichtigen Bereich der IT dar, in dem Risiken für Unternehmen entstehen. Um einen ersten pragmatischen und schnellen Ansatz zum Risikomanagement für Datenbanken zu bieten, konzentrieren wir uns auf folgende Teilbereiche des M_o_R Frameworks:

  • M_o_R Principles: Engages Stakeholders, Provides Clear Guidance, Informs Decision-Making
  • M_o_R Approach: Risk Management Strategy, Risk Register
  • M_o_R Process: Identify, Assess

(Mehr Informationen zu M_o_R im Appendix)

Einen besonderen Schwerpunkt wollen wir dabei auf „Engages Stakeholders“, „Identify“ sowie „Assess“ für Datenbanken legen. Dies geschieht vor dem Hintergrund, dass in aller Regel keine verlässlichen Informationen und technische Dokumentationen zu Einzelsystemen, und vor allem zum Zusammenspiel von Systemen, existieren. Das hat mit Blick auf Risiken wesentliche Konsequenzen:

  • Ausfallwahrscheinlichkeit: Die wenigsten Unternehmen können die Ausfallwahrscheinlichkeit für Datenbanken einschätzen
  • Konsequenzen von Ausfällen: In den meisten Unternehmen kann niemand vollständig einschätzen, welche Konsequenzen der Ausfall einzelner Datenbanken nach sich zieht
  • Eingeschränkte Recovery-Fähigkeit: In aller Regel existiert keine verlässliche Information dazu, ob und mit welchem zeitlichen Aufwand Datenbestände vollständig wiederhergestellt werden können

  

avato Vorgehensmodell Risiko Management am Beispiel Datenbanken

Was sind die wesentlichen Erfolgsfaktoren, um langfristig unterschiedlichen Zielsetzungen und Anforderungen an Verfügbarkeit und Sicherheit von Datenbanken gerecht zu werden? Ausschlaggebend sind Konzept und Vorgehensmodell. Das avato Vorgehensmodell zum Risikomanagement für Datenbanken orientiert sich am Vorgehensmodell für IT Information Management. Es ist ein Prozess mit strukturierten Stufen und klar definierten Zielen und Stakeholdern. Dabei durchläuft der Risikomanagementprozess für Datenbanken (Oracle) folgende Stufen:

  • Stakeholder: Ermitteln und Festlegung der Stakeholder
  • Goals: Definition und Abstimmung der Ziele
  • Scope & Objectives: Definition der zu analysierenden Bereiche und der jeweiligen Ziele
  • Details Scope & Prioritization: Festlegung der Detailziele, Messgrößen für jeden Bereich und Priorisierung 
  • Methods: Festlegung der Vorgehensweise sowie der Analysemethoden
  • Tools: Festlegung von Tools zur Datenerhebung und zur Datenanalyse

 

Stakeholders

Verschiedene Stakeholders haben in aller Regel sehr unterschiedliche Anforderungen in Bezug auf Ziele und Schwerpunkte. Typische Stakeholders sind:

  • IT Governance, inklusive Supplier Governance
  • IT Audit und IT Compliance inklusive regulatorischer Anforderungen
  • IT Service Management, inklusive Continual Service Improvement, Standardisierung & Automatisierung, Self-Service Funktionalitäten und Supplier Management

 

Goals

Kennt man die Stakeholders sowie deren Ziele und Prioritäten, werden diese abgeglichen und aufeinander abgestimmt. Das Ergebnis wird mit allen Stakeholders gemeinsam vereinbart und im Idealfall schriftlich fixiert. In dieser Phase ist es wichtig zwischen langfristigen Zielen (Goals) und den konkretisierten, mittelfristigen Zielen (Objectives) zu unterscheiden. Im Wesentlichen geht es in dieser Phase um Vereinbarungen mit den Stakeholders und um die Abstimmung der Langfristziele (Goals).

Typische Goals von Risikomanagement sind:

  • Risiken kennen (für Datenbanken beispielsweise im Sinne von unberechtigtem Datenzugriff oder Ausfall) und erfassen
  • Risiken bewerten im Sinne von Eintrittswahrscheinlichkeit und potentiellem Schaden
  • Risiken überwachen / kontrollieren

 

Scope & Objectives

In dieser Phase erfolgt die Festlegung der zu analysierenden Bereiche (Scope) und der jeweiligen Ziele pro Bereich (Objectives). Am Beispiel von Oracle Datenbanken soll hier der Schwerpunkt auf die Verfügbarkeit von Datenbanken gelegt werden. Scope & Objectives einer high-level Analyse zur Verfügbarkeit von Datenbanken könnte wie folgt aussehen: 

  • Datenbank-Software
  • Datenbankinfrastruktur
  • Datenbankkonfiguration und Setup
  • Monitoring
  • Datenbank Availability Konzept und Implementierung 
  • Datenbank Disaster Recovery Fähigkeit und Test
  • Datenbankschnittstellen

  

Details Scope & Prioritization 

Die Detailtiefe zu den oben aufgelisteten Scope und Objectives wird jetzt festgelegt. Zudem werden die unterschiedlichen Ziele priorisiert. Mit Blick auf Verfügbarkeit und Sicherheit von Oracle Datenbanken sind unter anderem diese Detailinformationen wichtig:

  • Datenbank-Software: Eingesetzte Module, Version und Patchlevel 
  • Datenbankinfrastruktur: Zugrundeliegende Server, Betriebssysteme inklusive Versionen und Patchlevel sowie Storage, Storage-Konfiguration und Netzwerk
  • Datenbankkonfiguration und Setup: Standardinstallation und Konfigurationen sowie Database User. Wichtig ist immer auch die Information, ob für die Installation in der Vergangenheit auch „In-Place-Migrations“ auf neue Versionen stattgefunden haben.
  • Monitoring: Ist ein Monitoring zu Database Performance, Storage Performance und Utilization sowie CPU Utilization und Netzwerk Utilization aufgesetzt? Gibt es für wichtige Parameter Schwellwerte und werden diese regelmäßig gemessen und festgehalten? Ist ein ausreichendes Alerting aufgesetzt und sind Regelwerke in Form von Work Instructions definiert?
  • Datenbank Availability Konzept und Implementierung: Failover- und Backup-Konzept mit detaillierter Beschreibung aller Prozesse, regelmäßige Tests der gesamten Prozesse und Überprüfen aller relevanten Work Instructions. Genaue Beschreibung der letzten Tests (vor allem Restore) sowie Festhalten der Ergebnisse. Wenn RAC und Dataguard genutzt werden, sollte deren Implementierung detailliert beschrieben werden.
  • Datenbank Disaster Recovery Fähigkeit und Test: DR Konzept und Test sowie letzter DR Test und genaue Beschreibung des Tests und der Ergebnisse. Wichtig ist hier, auch die Anwendung vollständig miteinzubeziehen und Tests nicht auf das Recovery der Datenbank zu beschränken. Hierzu gehört auch Transaktionskonsistenz über alle Teile der Anwendung und alle Schnittstellen zu anderen Systemen.
  • Datenbankschnittstellen: Abhängigkeiten zwischen verschiedenen Datenbanken und allen Schnittstellen von Datenbanken und Anwendungen müssen detailliert dokumentiert sein.

 

Methods

Die Methodik im Rahmen von Risikomanagement ist immer auch von den zu analysierenden Bereichen abhängig und kann zahlreiche Facetten haben. Dies wollen wir hier am Beispiel von Oracle Datenbanken konkretisieren. Die Vorgehensweise basiert auf dem M_o_R Prozess.

  • Identify: Identify bezogen auf die Verfügbarkeit von Oracle Datenbanken kann nicht allein auf der Basis von historischen Daten zu Incidents und Problems (inklusive Root Cause Analysis) erfolgen, auch wenn deren konsequente Auswertung zu einer proaktiven Stabilisierung beiträgt. Anzahl und Häufigkeit unkritischer Incidents lassen alleine keinen Rückschluss auf das Ausfallrisiko und vor allem auf den potentiellen Impact zu. Die oben beschriebenen Parameter bieten eine wesentlich zielführendere Analyse.
  • Assess: Assess besteht nach M_o_R zum einen aus Estimate und zum anderen aus Evaluate. Estimate dient der Priorisierung von Risiken. Welche Risiken sind mit Blick auf Oracle Datenbanken wie zu bewerten? Hier sind neben den klassischen Themen wie Software-Version, Patchlevel und zugrundeliegende Infrastruktur vor allem auch DR Test und Recovery-Fähigkeit wichtig. Evaluate ist das Verstehen von Risiken durch das Abwägen von Threats und Opportunities von Aktivitäten.
  • Plan: In der Phase Plan sollen Maßnahmen für Threats und Opportunities vorbereitet werden. Ziel ist es, Threats zu minimieren und Opportunities zu maximieren. 
  • Implement: Geplante Maßnahmen werden ergriffen und die Implementierung überwacht.


Tools

Die Festlegung der Tools steht immer am Ende des Prozesses. Sie konzentriert sich wesentlich auf die Bereiche Datenerhebung und Datenanalyse. Die Datenerhebung muss hierbei über klassische CMDB-Informationen hinausgehen und zentrale Themen wie Continuity (Backup/Restore, Failover), Recovery und Schnittstellen abdecken. 

Summary

Wesentliche Bausteine eines erfolgreichen Risikomanagements in Bezug auf Datenbanken müssen stets mit Blick auf formulierte Ziele vorgenommen werde. Will man Risiken kennen, sie bewerten und überwachen, hängt der Erfolg wesentlich von hinreichenden Informationen, regelmäßigen und vollständigen Tests sowie einem sinnvollen Monitoring ab.

Zu den wichtigen Informationen gehören vor allem für alle kritischen Datenbanken Version und Patchlevel der Datenbank-Software sowie die Datenbankinfrastruktur (Server, OS, Storage, Network). Zudem sind Datenbankkonfiguration und Setup von zentraler Bedeutung, genauso wie alle Database User, alle Abhängigkeiten zwischen Datenbanken, und die Schnittstellen von Datenbanken zu Anwendungen.

Zu den entscheidenden Faktoren für die Verfügbarkeit gehört neben diesen Informationen eine Reihe von Konzepten  - und vor allem von regelmäßigen Tests. Hierzu zählen das Failover-Konzept und dessen regelmäßiger Test, das Backup-/Restore-Konzept und Restore-Tests sowie der Disaster Recovery Test. Gerade die beiden letztgenannten müssen unter produktionsähnlichen Bedingungen unter Einbeziehung von Anwendungen und unter Berücksichtigung aller Datenbankschnittstellen durchgeführt werden. Testaufbau, Durchführung und Ergebnisse sind genau zu dokumentieren, die Tests müssen nach erheblichen Veränderungen (Datenbankgröße, neue Schnittstellen, neue Releases von Anwendungen) stets wiederholt werden.

Diese Informationen schaffen die Voraussetzung Ausfallwahrscheinlichkeiten besser einschätzen zu können, die Folgen von Ausfällen genauer spezifizieren zu können, sowie Recovery-Fähigkeit zumindest für wichtige Systeme zu schaffen.

 

Appendix: The M_o_R Framework

The AXELOS Management of Risk Pocketbook is guided to put on effective framework for risk management in place. The framework is based on four basic concepts:

  • M_o_R Principles
  • M_o_R Approach
  • M_o_R Process
  • Embedding and reviewing M_o_R

 

M_o_R Principles

Basis to develop and maintain an enterprise risk management. High level statements providing for general guidance for enterprise risk management, such as:

  • Aligns with objectives: Risk management needs to be continuously aligned with enterprise objectives.
  • Fits the context: Fitting the current context requires an accurate understanding of changing internal and external contexts.
  • Engages stakeholders: Requires knowing the stakeholder and to build up a sufficient communication
  • Provides clear guidance: Stakeholders need to see how risk management identifies, assesses and controls risks. Important to Risk Management is a coherent approach across all units.
  • Informs decision-making: Risk management is responsible to provide sufficient information to decision-makers.
  • Facilitates continual improvement: Basis for continual improvement are historical data 
  • Creates a supportive culture: Risk management creates a culture, where risks, costs of prevention and consequences are known and where potential wins and losses are known
  • Achieves measurable value: Risk management should achieve measurable value to the enterprise by supporting a cost effective and efficient risk prevention

 

M_o_R Approach

Enterprise implementation of risk management principles, taking into account enterprise specific needs and objectives.

  • Risk management policy: Description of the formal risk management approach
  • Risk management process guide: Description of processes, roles and responsibilities
  • Risk management strategy: Detailed description of risk management implementation for an organizational unit or activity
  • Risk register: Documentation of all identified risk
  • Issue register: Documentation of all current unplanned situations
  • Risk improvement plan: Documentation of all actions required to improve risk management 
  • Risk communications plan: Description of how risk management communicates to all stakeholders
  • Risk response plan: Documentation of response plans to individual risk. Liked to risk register
  • Risk progress report: Regular report on progress of risk management actions 

 

M_o_R Process

See description in “Methods”.

 

Embedding and Reviewing M_o_R

Embedding risk management into organizational culture and to safeguard that risk management continues addressing enterprise requirements.

  • Changing the culture for risk management: Regardless of the size of the organization, risk management in terms of documented policies, process guides, strategy, plans and reports needs to be understood, valued and considered
  • Measuring the value: Risk management is not an end in itself. The value of risk management to the enterprise needs to be measured continuously. 
  • Overcoming the common barriers to success: Typical barriers are lack of organizational culture and understandable and manageable policies
  • Identifying and establishing opportunities for change

 

Zur Anmeldung gelangen Sie hier.

Haben Sie Fragen oder Feedback? Wir sind erreichbar unter: marketingnospam@avato.net

Impressum

Datum: Juni 2017
Autor: Josef Kraitz
Kontakt: marketingnospam@avato.net
www.avato-consulting.com
© 2017 avato consulting

 

Anmeldung Newsletter

Sie können sich hier auch für den regelmäßigen, kostenfreien Bezug unserer avato news anmelden. Nach erfolgter Registrierung erhalten Sie jede neue erscheinende Ausgabe als PDF-Dokument automatisch auf ihr angegebenes E-Mail-Konto zugesandt.
captcha
Alle mit * markierten Felder müssen ausgefüllt werden