Risiko/Management/tmp

topic - Kurzbeschreibung

Anhang

Siehe auch

• Risiko/Management/tmp

TMP

Themenfeld 8

Risikoanalyse
Exkurs

IT-Risikomanagement

Motivation

Ziele eines Unternehmens
Gewinnoptimierung, Marktetablierung, Existenzsicherung, ...
Betrachtung von Risiken 
essenzieller Bestandteil unternehmerischen Handelns
Risiken nicht nur als Gefahr ansehen
Chance und notwendige Voraussetzung für die Zielerreichung 
Risiken nicht rein negativ beurteilen
mit Risiken richtig umgehen 
Risiken in Chancen umwandeln
Unternehmen muss jederzeit in der Lage sein 
unternehmensweit konsistente Ertrags- und Risikoinformationen zu ermitteln
Effizientes Risikomanagement von strategischer Bedeutung
wenn Risiken gesteuert und kontrolliert werden, trägt dies positiv und langfristig zu Unternehmenserfolg und Wachstum bei
Doppelrolle der Informationstechnologie
Voraussetzungen für die Aggregation von Daten zu aussagefähigen Ertrags- und Risikoinformationen
Erzeugt selbst Risiken

Motivation

Standish Group im Jahre 2009 Umfrage 
Nur ein Drittel aller IT-Projekte werden im geplanten Zeit- und Budgetrahmen beendet 
fast die Hälfte diese Vorgaben nicht erfüllen 
der Rest wird abgebrochen 

Motivation

IT-Projekte
Risikobegriff
„Risiko“ wird unterschiedlich beschrieben
je nach Betrachtungsweise
Entscheidungsorientiert
Abweichung/Varianz von Zielgrößen und Erwartungsgrößen
Abweichung kann positiv oder negativ sein
Je höher die Standardabweichung, umso größer das Risiko
Ausfallorientiert
negative Abweichung des realisierten Ergebnisses vom Erwartungswert
Risiko = Eintrittswahrscheinlichkeit x Auswirkungen
Einfache Gleichung für das Risiko 

Je geringer die Eintrittswahrscheinlichkeit, umso seltener

die Gefahr 
die Chance
Auswirkungen sind ungünstige Effekte, sollte das Risiko eintreten

Risiken sind Teil des Geschäftes

Einige der Risiken spielen dabei nie eine Rolle, andere können bedrohlich werden. 
Risikomanagement hilft, Risiken zu erkennen, zu analysieren, zu bewerten und mit den entsprechenden Techniken abzuschwächen. 

BSI-Standard 200-3

Risikoanalyse

Methoden

BSI-Standard 200-3
Risikoanalyse auf der Basis von IT-Grundschutz
klassische Risikoanalyse 
ISO 27001, 27005, 31000, 31010
Penetrationstest
Differenz-Sicherheitsanalyse

Risikomanagement

Bedeutung
Risikomanagement gewinnt an Bedeutung
strategischen Bedeutung von 
IT-Projekten 
IT-Projekte werden anspruchsvoller und komplexer 

Gründe

Expansion / Globalisierung der Geschäftstätigkeit
Automatisierung von Geschäftsprozessen
Steigende Abhängigkeit von Verfügbarkeit und Sicherheit der Datenverarbeitung
Neuartige Geschäftsprozesse aufgrund steigender Marktdynamik durch neue Technologien 
Inhärenten Risiken bei IT-Projekten im Vergleich zu anderen Projekten

Risikomanagement umfasst

Festlegungen von Zielen auf Basis der Definition einer Strategie
ggf. auch Visionen der das Risikomanagement anwendenden Stelle
Ohne konkrete Ziele lassen sich keine Abweichungen messen
Definition von Werttreibern oder kritischen Erfolgsfaktoren zur Erreichung von Zielen
Festlegung einer Risikomanagement-Strategie
abhängig von der Risikobereitschaft 
risikoavers, risikoneutral oder risikofreudig
Identifikation von Risiken
Bewertung/Messung von Risiken
Bewältigung von Risiken
Steuerung der Risikoabwehr
Monitoring, also Früherkennung
Strukturierung und Dokumentation in einem Risikomanagementsystem
Prozesse im Risikomanagement 
Prozesse im Risikomanagement 
Risikomanagementprozess
Phasen
Risikoanalyse
Risikobewertung
Risikominimierung
Risikokontrolle
Risikoverfolgung
Informationssicherheit-Risikomanagement-Prozess
Informationssicherheit-Risikomanagement-Prozess
Risikomanagement
Teile des Risikomanagements
Erkennung und Bewertung von Risiken
Erarbeitung und Umsetzung von Maßnahmen
optimale Lösung finden
Risiken auf akzeptable Restrisiken reduzieren
wichtigste Gefahrenquellen erkennen und abschwächen
Für jeden dieser Prozesse gilt
In Abhängigkeit der Bedürfnisse
wird der Aufwand einer oder mehrerer Personen gefordert
Jeder Prozess wird mindestens einmal durchlaufen
Jeder Prozess tritt in einer oder mehreren Projektphasen auf
Überschneidung der Prozesse ist möglich 
Risikomanagement
Risikomanagement-Prozesse
Risikomanagementplanung 
Wie wird das Risikomanagement organisiert?
Wie viel Risikomanagement ist nötig?
Haben wir Erfahrungswerte in dieser Projektart?
Zuständigkeiten
Checklisten 
Risikoidentifikation 
Identifizierung potenzieller Risiken
Dokumentenanalyse
Brainstorming
SWOT-Analyse
Ursache-Wirkungs-Analysen
Qualitative Risikoanalyse
Eintrittswahrscheinlichkeit sowie Auswirkung
Priorisierung (z. B. A, B und C-Risiken)
Risikomanagement
Bedeutung
Weitere Risiken
IT-Operations (Risiken aus dem laufenden Betrieb)
Administrative Fehler
Systemausfall 
IT-Security (Sicherheitsrisiken)
Unzureichende Sicherheits- und Schutzmaßnahmen für IT-Systeme
Fehlende Autorisierung und Authentifizierung für Datenzugriff und -austausch 
Nicht näher spezifizierte Risiken
Fehlende Akzeptanz / Ablehnung der Anwender gegenüber neuer Software

Konzeptionierungsfehler

Aufgrund der beschriebenen Problematik ist erkennbar, dass das Risikomanagement fester Bestandteil aller IT-Projekte sein sollte. 
Prozesse im Risikomanagement 
Risikomanagementplanung
Wie sollen die Aktivitäten des Risikomanagement durchgeführt werden?
Risikomanagementplanung legt Vorgehensweise fest
Planung soll sicherstellen
Risikomanagement ist in Bezug auf Risiken und der Bedeutung des Projektes angemessen 
Es stehen ausreichende Ressourcen für die Aktivitäten zur Verfügung 
Erfolgschancen erhöhen
gut strukturierte und sorgfältig vorbereitete Planung 
erleichtert Durchführung der anderen Risikomanagement-Prozesse 
Erstellung eines Risikomanagementplans
Zusammenarbeit mit 
Projektleitern und -mitgliedern
Stakeholdern 
für das Risikomanagement im Unternehmen zuständige Mitarbeiter
Auswirkungen haben dabei Risikobereitschaft und Risikotoleranz 
des Unternehmens und 
der Projektbeteiligten
Hilfreich zur Erstellung 
bereits definierte Ansätze und Konzepte für das Risikomanagement im Unternehmen 
allgemein oder aus vorangegangenen Projekten
Prozesse im Risikomanagement 
Risikomanagementplan
Inhalte
Methodologie
Ansätze, Werkzeuge und Datenquellen für das Risikomanagement
Rollen und Verantwortlichkeiten
Organisation des Projektteams, Hierarchien
Budgetierung
Kostenschätzung, benötigte Einsatzmittel
Zeitliche Planung
Festlegung von Terminen für die Ausführung des Risikomanagement-Prozesses während der Projektlaufzeit
Risikokategorien
Strukturen für die Risikoidentifikation festlegen
Definition der Risikowahrscheinlichkeiten und -auswirkungen 
als Unterstützung der Risikoanalyse 
Prozesse im Risikomanagement 
Risikoidentifikation
Für eine Beherrschung der Risiken, muss man diese zunächst kennen
Bestimmung von Risiken unterschiedlicher Art
Kontinuierliche Durchführung und Bestimmung
einzelne Risiken sind zu Beginn nicht absehbar
es entwickeln sich neue oder übersehene Risiken
Projektteam sollte in den Prozess einbezogen werden, damit es sich für die Risiken und die entsprechenden Risikobewältigungs- maßnahmen zuständig und verantwortlich fühlt.
Nach Identifizierung von Risiken 
Priorisierung mit Hilfe der Risikoanalyse
 Risikokategorien
Für eine systematische Identifizierung der Risiken ist es wichtig, die verschiedenen Kategorien von Risiken zu kennen
Die Unterteilung kann dabei je nach Verständnis, Betrachtungsweise und Kontext unterschiedlich sein. 
Im betriebswirtschaftlichen Sinne gibt es z. B. die Unterscheidung von externen, internen, finanziellen und operativen Risiken.

Prozesse im Risikomanagement

Risikoidentifikation
Prozesse im Risikomanagement 
Methoden der Risikoidentifikation 

Brainstorming

Innerhalb einer Arbeitsgruppe Ideen sammeln
ermöglicht die Identifikation von Risiken in kurzer Zeit
Quantität geht (zunächst) vor Qualität
wie im Brainstorming üblich, ohne Äußerung von Kritik
Auswertungsphase
anschließend werden die Vorschläge bewertet und genauer definiert

Delphi-Methode

Befragungstechnik um eine von Experten erstellte Prognose zu erhalten
Mit Hilfe eines Fragebogens 
Ideen der Teilnehmer basierend auf Ihrem fachlichen Know-how zusammengefasst
Direkter Austausch der Experten untereinander muss unterbunden werden
Antworten sollen frei von Beeinflussungen sein 
Antworten werden zur Kommentierung an die anderen Experten weitergereicht
Nach einigen Durchläufen liegt ein aussagekräftiges Ergebnis vor, welches frei von Voreingenommenheiten sein sollte

Post-Mortem-Analyse

Analyse vorangegangener Projekte
Analyse vorangegangener Projekte, welche die Ziele oder Erwartungen nicht erfüllt haben
systematische Erhebung aller möglichen Ausfall- und Ursachenkombinationen
daraus können potenzielle Risiken für das Projekt sichtbar werden

Prozesse im Risikomanagement

Methoden der Risikoidentifikation 
Fehlermöglichkeits- und Einflussanalyse (FMEA)
Ein System wird in einzelne Betrachtungseinheiten/Funktionsbereiche zerlegt
Auf Basis der einzelnen Funktionen werden Schwachstellen herausgebildet
potentielle Fehlermöglichkeiten erkennen 
Ursachen und Auswirkungen werden systematisch anhand der Funktionsbereiche ermittelt

Szenariotechnik

künftige Entwicklungen bzw. Szenarien anhand von definierten Risiken durchspielen
Auswirkungen bestimmter Konstellationen von Einzelrisiken auf das Gesamtrisiko betrachten und ausgewerten
Ziel: Ermittlung möglicher Worst-Case Szenarien bzw. das Finden neuer möglicher Risiken

SWOT-Analyse

Projekt wird unter jedem der SWOT-Aspekte betrachtet 
erhöht die Bandbreite der betrachteten Risiken
SWOT-Analyse ist ganzheitlicher und auch positiver ausgerichtet als andere Methoden
Risiken werden nicht nur als negativer Aspekt betrachtet werden, sondern ebenso die Stärken und Chancen
ermöglicht eine direkte Umsetzung von Stärken und Chancen auf strategische oder operative Vorteile
Schnittstellenrisiken zwischen Projekten und dem Unternehmen können identifiziert werden

Prozesse im Risikomanagement

Risikoidentifikation: Aufbereitung identifizierter Risiken
Identifizierte Risiken müssen aufbereitet werden
damit diese den anderen Prozesse des Risikomanagement zur Verfügung stehen
Hierfür eignet sich die Erstellung folgender Komponenten

Risikoregister

Ursprungswerte aus der Risikoidentifikation
später gefüllt mit den Ergebnissen der anderen Prozesse
Liste identifizierter Risiken und mögliche Folgen
Liste der möglichen Bewältigungsmaßnahmen, sofern bereits identifiziert
Liste der Grundursachen identifizierter Risiken
Liste der Risikokategorien 

Prozesse im Risikomanagement

Risikoanalyse: Qualitative Risikoanalyse
Schnelle und kosteneffektive Vorgehensweise
Methoden zur Priorisierung der identifizierten Risiken 
Grundstein für die quantitative Risikoanalyse
trägt zur Risikobewältigungsplanung bei
bezieht Informationen aus der Risikomanagementplanung und der Risikoidentifikation
Konzentration auf Risiken mit hoher Priorität 
Prioritäten identifizierter Risiken bewerten
Anhand der Eintrittswahrscheinlichkeit 
daraus resultierenden Auswirkungen auf die gesteckten Ziele
Zeitrahmen
Risikotoleranz
Budgetkosten 
Umfang und Qualität
Bedeutung eines Risikos besser zu verstehen
qualitative Bewertung der verfügbaren Informationen  
Risikobezogene Maßnahmen sind oftmals sehr zeitkritisch und können somit die Bedeutung oder Auswirkung eines Risikos stark erhöhen. 

Laufender Prozess

Die qualitative Risikoanalyse sollte im Laufe des Projektes ständig wiederholt werden, da sich Änderungen an den Projektrisiken ergeben können. 

Prozesse im Risikomanagement

Risikoanalyse: Quantitative Risikoanalyse
Aufbauend auf qualitativer Risikoanalyse 
durchgeführte Priorisierung der Risiken
einige Risikomanager führen sie gerne direkt nach der Risikoidentifikation durch
Auswirkungen werden analysiert 
numerische Einstufung der Risiken
Somit wird gleichzeitig ein erster Ansatz für die Entscheidungsfindung erstellt

Methoden

Monte-Carlo-Simulation (Szenariotechnik) 
Entscheidungsbaum-Analyse(Fehleranalyse) 
Ziele
Wahrscheinlichkeitsbestimmung von möglichen Ergebnissen
Identifizierung von Risiken mit der höchsten Aufmerksamkeit
Realistischen Bestimmung von Kosten, Terminen und Umfangszielen
Bestimmung der besten Managemententscheidung, sollten einige Faktoren unbekannt sein 

Prozesse im Risikomanagement

Risikobewältigungsplanung
Vorgehensweisen und Verfahren
Erreichen von Projektzielen 
Gefahren vermeiden
Aufbauend auf Risikoanalyse
qualitativ und /oder quantitativ
Risikoverantwortliche bestimmen
welche Maßnahmen zur Risikobewältigung übernehmen
Orientiert sich an ermittelten priorisierten Risiken
Budget, Terminplan, Einsatzmittel und Maßnahmen
Vor der Bewältigung müssen Bedeutung und Umfang eines Risikos klar sein
Folgende Punkte muss jeder Beteiligte verinnerlicht haben
kosteneffektiv
termingerecht
realistisch 

Vorgaben an das Risikomanagement

von betriebsinternen Projektmitgliedern
von Vertragspartnern, Behörden, Gesetzgeber
Vertragspartner (meist zeitliche, aber auch Qualitätsvorgaben)
Gesetzgeber (Auflagen bzgl. des Datenschutzes und der Aufbewahrung von z.B E-Mails)
Behörden (häufig sind dies Vorgaben bzgl. des Budgets, da bei Verzögerungen oder Mehrkosten diese erst genehmigt werden müssen) 
Prozesse im Risikomanagement

Risikobewältigungsplanung

Wie gehen wir Risiko um?
Vermeiden/Minimieren
z.B durch Verbesserung der Kommunikation innerhalb des Projektteams und den Vertragspartnern
Vermindern 
z.B durch Änderungen an der Organisation um Projektziele oder Meilensteine nicht zu gefährden
Abwälzen/Übertragen 
z.B an den Auftraggeber oder Lieferanten durch entsprechende Vertragsklauseln etc.
Selbstübernehmen/Akzeptieren 
meist nur bei eher unbedeutenden Risiken/Bildung von Reserven

Prozesse im Risikomanagement

Risikocontrolling: Risikoinventur
Risikoinventur 
erfasst Schäden durch Risiken  
Hierbei spielen Eintrittswahrscheinlichkeit sowie Ursachen eine Rolle
Grundlagen zur strukturierten Darstellung 
Vollständigkeit
alle Risiken
die erfolgreichen Abschluss eines Projektes gefährden können
Abhängigkeiten (Interdependenzen)
Viele Risiken verstärken sich extrem bei ihrem Eintritt
Beispiel
Es kommt in einem Serverraum zu einem Brand, durch ein defektes Netzteil
Der Schaden steigt erheblich 
überfällige Wartung des Brandbekämpfungssystems
langanhaltende Betriebsunterbrechung
Hardware muss getauscht und ein Backup eingespielt werden
Eine Gefährdung für die gesamte Produktion ist die Folge
Der Schaden entsteht nicht durch Verlust der Hardware oder deren (Brandschutzversicherung)
eigentlicher kaum messbare Schaden: Betriebsunterbrechung (keine Versicherung)
Prozesse im Risikomanagement
Risikocontrolling: Risikoinventur
Quantifizierung
Schadensausmaß richtet sich nach Eintrittswahrscheinlichkeit (starker Bezug)
Rechtzeitigkeit
Risiken müssen so früh wie nur irgendwie möglich erkannt werden
damit noch genügend Reaktionszeit bleibt
Schaden möglichst gering zu halten
Kommunikation
Während der Bewältigungsplanung sind Akzeptanzbereiche zu bilden
durch die die jeweiligen Risikoträger bei Eintritt informiert werden
Verantwortung
Risiken müssen entsprechend ihrer Art, den jeweiligen Zuständigkeitsbereichen zugeordnet sein
nach Eintritt des Risikos muss der Zuständige dann die geplanten Maßnahmen ergreifen
Prozesse im Risikomanagement
Bewertung und Messung von Risiken
Zwei Phasen
Bruttobewertung
grundsätzlichen Bedrohungspotenziale werden betrachtet
wo liegen Schwerpunkte der Risikosteuerung 
Nettobewertung
Risiken bereits bestehenden Steuerungs- und Kontrollmaßnahmen gegenüberstellen
Aktuelle Risikolage 
Wir ermittelt
Eignung und Angemessenheit bestehender Maßnahmen festgestellen
Maßstäbe eingrenzen
Vor einer Bewertung der Risiken
Maßstab für Schadensausmaß und Eintrittswahrscheinlichkeit eingrenzen
Schätzungen oder Erfahrungswerten durch die Verantwortlichen 
Worst-Case-Szenario
klare Grenzen zwischen den einzelnen Gefahrenstufen
Prozesse im Risikomanagement
Bewertung und Messung von Risiken
Ampelmodell 
besonders geeignet
Akzeptanzlinie
Rote Linie zwischen akzeptablen und kritischem Bereich
Toleranzgrenze
Rote Linie zwischen Grenzbereich und inakzeptablem Bereich 
Risiken, unterhalb dieser Linie, gelten als tolerierbar
wenn es möglich ist
durch Maßnahmen diese unter Kontrolle zu halten 
oder sogar in den akzeptablen Bereich zu bringen
Festlegung der Grenzen wird durch Verantwortliche vorgenommen
Bewertung und Messung von Risiken
Kriterien
Ungewissheit 
Unsicherheit
Abschätzungssicherheit
Ahnungslosigkeit
Ausbreitungsgrad des potenziellen Schadens
zeitlicher Ausdehnungsgrad nach Eintritt 
Möglichkeit den Ursprungszustand wiederherzustellen 
z.B durch einspielen eines Backups
Verzögernde Wirkung des Schadens
evtl. nicht direkt sichtbar
Mobilisierungspotenzial der beteiligten Mitarbeiter 
nach einem Schaden weiter zu machen
Ergebnis: qualitative und quantitative Bewertung von Risiken
quantitativen Bewertung 
Schadenshöhe/Intensität der Auswirkung 
Eintrittswahrscheinlichkeit
qualitative Bewertung 
Aggregation (Zusammenlegung) von Risiken im Hinblick auf die Erreichung von Zielen
Bewertung und Messung von Risiken
Bewertung und Messung von Risiken
Berechnung des Faktors eines Risikos
Eintrittswahrscheinlichkeit * Schadenshöhe = Risikofaktor
Berechnung des Faktors eines Risikos
Risikobewertung am Beispiel „Changemanagement“
Erfahrungen bei vorrangegangenen Projekten:
Änderungen während des Projekts
z. B. Änderung der Meilensteinen 
oder im schlimmsten Fall am eigentlichen Projektziel
Dies sind Risiken, die komplette Projekte bedrohen oder sogar stoppen können
Ein Risiko beeinträchtigt hierbei meist nicht nur eine Säule des gesamten Projekts
Oft ist die Rede von einem Dreieck in dem sich ein Projektmanager bewegt
Umso mehr dieser sich auf einen Punkt fokussiert, umso mehr entfernt er sich andererseits von einem anderen
Changemanagement hat großen Einfluss auf zeitlichen Rahmen und das Projektbudget
Warum besteht das Risiko?
Kein klar definiertes Ziel
Mangelhaftes Anforderungsmanagement während des Planungsprozesses, ergeben stetig neue Projektänderungen
Oftmals wird der Benutzer nicht in die Planung mit einbezogen 
Wie wahrscheinlich ist das Risiko?
Eintrittswahrscheinlichkeit 5 – sehr hoch
Schadenswirkung 4 – hoch 
Risikofaktor
Wahrscheinlichkeit (5) * Schadenswirkung (4) = Risikofaktor (20) 
Mit dem errechneten Risikofaktor landet dieses Risiko im nicht tolerierbaren Bereich (Stern Abb.). 
Bewertung und Messung von Risiken
Berechnung des Faktors eines Risikos
Beispiele für weitere Risiken (Gefahrenbereiche)
Einsatz neuer Technologien 
W(4) * S(5) = RF(20)
Implementierungen ohne Entwurf 
W(4) * S(4) = RF(16)
Unmotivierte Mitarbeiter 
W(3) * S(5) = RF(15)
Mitarbeiterfluktuation 
W(2) * S(4) = RF(8)
Machtkämpfe 
W(1) * S(2) = RF(2)
Unzureichende Reviews 
W(3) * S(4) = RF(12) 

Legende: 
W = Wahrscheinlichkeit S = Schadenswirkung RF = Risikofaktor 
Qualität des IT-Managements
Kernpunkte
Planung und Organisation
Sind IT-Strategie und Geschäftsstrategie aufeinander abgestimmt?
Kann das Unternehmen seine IT-Ressourcen optimal nutzen?
Sind die Ziele der IT von allen Mitarbeitern verstanden?
Sind die IT-Risiken erkannt, verstanden und unter Kontrolle?
Ist die Qualität der IT-Systeme angemessen für die geschäftlichen Anforderungen? 
Beschaffung und Einführung neuer Systeme
Liefern neue Projekte voraussichtlich Lösungen, die den geschäftlichen Anforderungen genügen?
Werden neue Projekte voraussichtlich im vorgesehenen Zeit- und Kostenrahmen abgeschlossen?
Können neue Systeme eine ordnungsgemäße Verarbeitung nach der Einführung sicherstellen?
Können Änderungen an IT-Systemen durchgeführt werden ohne die Geschäftsprozesse zu behindern? 
Betrieb und Unterstützung
Werden IT-Dienstleistungen entsprechend der geschäftlichen Prioritäten ausgeführt?
Sind die Kosten optimiert?
Können die Mitarbeiter mit den IT-Systemen effektiv und sicher umgehen?
Ist eine angemessene Vertraulichkeit, Integrität und Verfügbarkeit gewährleistet? 
Überwachung
Kann die IT-Performance gemessen werden?
Können IT-Probleme rechtzeitig erkannt werden?
Risikokommunikation und -berichterstattung 
Ständige Kommunikation innerhalb und außerhalb eines IT-Projektes
vielleicht wichtigster Punkt für erfolgreiches Risikomanagement
Evaluierung und Modifizierung während eines Projektes nicht ausgeschlossen werden
Meetings abhalten
Effektivität der Risikoevaluierung und des Risikomanagements einordnen
Feedback verwenden, um den Prozess zu verbessern
Die wichtigsten Aspekte
Kommunikation der Risikoinformationen an alle Stakeholder
Motivation zum freien Informationsfluss über alle Risiken
Regelmäßige Updates für alle Teammitglieder
Einfache Kommunikationsformen untereinander
Allen Teammitgliedern muss ständiger Zugriff zu den Risikoinformationen zur Verfügung stehen
Standardberichtsformat hat sich Zeit bewährt
Inhalt dieses Berichts ist der aktuelle Stand des gesamten Risikomanagementplans
Bericht umfasst folgende Punkte
Wann wurde die letzte Risikoinventur durchgeführt?
Ist die Risikoanalyse aktuell?
Welche Risiken sind hinzugekommen, welche evtl. aufgelöst worden?
Ist ein Trend abzusehen? 
Bewertung der getroffenen Maßnahmen zur Risikobewältigung 
Erfolg wird durch Beeinflussung der ergriffenen Maßnahmen messbar
Überwachung von Maßnahmen 
Fragen
Wer Überwacht die Maßnahmen?
Wer setzt diese eigentlich um? 
RASCI Methode 
Überwachung befasst sich zum größten Teil mit folgenden Fragen
Responsible (R)
Wer ist verantwortlich?
Approved/Accountable (A)
Wer hat es abgesegnet?
Supports (S)
Wer setzt es um?
Consults (C)
Wer hilft bei der Umsetzung („Experte“)?
Informed (I)
Wer muss benachrichtigt werden? 
Bewertung
Risikomanagement sollte nicht als lästige Pflicht angesehen werden
sondern als eine Chance 
IT-Prozesse optimieren 
Risikoverständnis und Sicherheitsniveau im Unternehmen verbessern
Wirtschaftlicher Nutzen des Risikomanagement
Je nach der Größe und Bedeutung eines Projektes
kann das Risikomanagement in seinem Umfang unterschiedlich ausgelegt werden. 
Bei kleineren Projekten 
erscheint es unter Umständen weniger sinnvoll, aufwendige Analysen wie z. B. die FMEA durchzuführen
Hier kann mit einfachen Mitteln bereits ein adäquates Risikomanagement betreiben werden
Brainstorming 
guter Dokumentation 
Kommunikation der Risiken
Risiken können nicht immer vollständig eliminiert werden
aber durch das Risikomanagement beherrschbar bleiben

Bedrohungsanalyse
Risikoanalyse (risk assessment)
Risikobewertung anhand Wahrscheinlichkeiten
Eintreten verschiedener Bedrohungen 
potentieller Schadenshöhe
Bewertung der Eintrittswahrscheinlichkeit
Geschätzter Aufwand zur Angriffsdurchführung
Anzahl der Angriffsschritte
Komplexität Angriffsschritte
Nutzen für den Angreifer
finanziell
politisch
Reputation
Motive des Angreifers, Angreifertyp
Script Kiddie
Hacker
Mitarbeiter
Wirtschaftsspion
politische Aktivisten
Ressourcen / Kenntnisse des Angreifers
Know How
Werkzeuge
Zugänge
Bedrohungsanalyse
Angriffsbäume
Systematische Ermittlung potentieller Ursachen für Bedrohungen
organisatorisch
technisch
benutzerbedingt
Vorteile von Angriffsbäume
Bedrohungsmodelle werden besser verstanden
Bedrohungen besser erkennbar
Schutzmaßnahmen besser erkennbar
Berechnungen der Sicherheit
Sicherheit verschiedener Systeme vergleichbar
Visualisierung über Bedrohungs-/Angriffsbäume (attack tree)
Wurzel definiert mögliches Angriffsziel
Zeichenziele zur Erreichung des Gesamtziels ergeben die nächste Ebene
Verwendung von UND- und ODER-Knoten, um Bedingungen zu formulieren
Bedeutung des Erreichens von Zeichenzielen
Äste verknüpfen Zwischenziele mit höheren Zielen
Blätter des Baumes beschreiben einzelne Angriffsschritte
Bedrohungsbaum
Maskierungsangriff
Bedrohungsanalyse
Bedrohungsmatix
Bedrohungsanalyse
Risikoberechnung
Schlussfolgerung
Auch bei einfachem Angreifermodell sehr hohes Risiko
Passworte sollten nur verschlüsselt übertragen werden!
Zeitliche Entwicklung beachten

Konstruktion sicherer Systeme
Konstruktion sicherer Systeme
Entwicklungsprozess
Dezidierte Methoden bislang kaum entwickelt
allgemeine methodische in der Regel 
top-down Vorgehensweise aus Software-Engineering
Schwierig, da Angreifer viele Möglichkeiten hat
allgemeine Prinzipien
1975 Saltzer und Schröder
Heute noch gültig

Allgemeine Konstruktionsprinzipien
Erlaubnis-Prinzip
Vollständigkeits-Prinzip
Need-To-Know-Prinzip
Prinzip der Benutzerakzeptanz
Erlaubnis (fail-safe defaults)
Grundsätzlich jeder Zugriff verboten (default deny)
nur durch explizite Erlaubnis wird Zugriffsrecht gewährt.
Configfiles
Apache
SMB
Vollständigkeit (complete mediation)
Jeder Zugriff ist auf Zulässigkeit zu prüfen!
System, das nur beim Öffnen Erlaubnis prüft, nicht bei jedem Schreiben, verletzt das Prinzip
Rechte können sich zwischendurch verändert haben.
Need-to-Know
Prinzip der minimalen Rechte
Jedes Subjekt bekommt nur genau die Zugriffsrechte, die es zur Erfüllung seiner Aufgaben benötigt.
System, in dem ein Admnistratoren unbeschränkte Rechte hat, verstößt gegen dieses Prinzip.
AppAmor
SELinux
Rollenbasierte Rechte
Akzeptanz (economy of mechanism)
Benutzerakzeptanz 
Sicherheitsmechanismen müssen einfach zu nutzen sein 
routinemäßig und automatisch angewendet werden
Offener Entwurf (open design)
Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abhängig sein
Verwendete Verfahren und Mechanismen, die beim Entwurf des Systems verwendet werden, müssen offen gelegt werden
No security through obscurity
Sicherheit kryptografischer Verfahren sollte nicht darauf basieren, dass Verschlüsselungsverfahren nicht bekannt ist.
„Schlüssel unter der Fußmatte“
KISS - Prinzip
Keep it simple, stupid.
„Halte es einfach, Dummkopf!“; sinngemäß: Mach's so einfach wie möglich
Keep it simple [and] stupid 
„Halte es einfach und [dumm=] beschränkt“
sinngemäß: „Mit einfachsten Mitteln verständlich und bewältigbar.“
Keep it short and simple 	
„Gestalte es kurz und einfach“
aus dem Bereich des Marketing
Keep it simple and smart 
„Mach es einfach und schlau“
Keep it simple and straightforward 
„Gestalte es einfach und überschaubar“
Keep it safe and sound 	
„Halte es sicher und stimmig“
Keep it sweet and simple 
„Gestalte es gefällig und einfach“
KISS-Prinzip
Hintergründe
Grundaussage: Wähle die einfache Lösung
Wissenschaftlich
Bevorzuge die Theorie, die weniger Annahmen machen muss, um gemachte Beobachtungen zu erklären
Vergleichbar dem Prinzip der Einfachheit
Angeblich von Clarence "Kelly" Johnson geprägt
Ingenieur bei Lockheed Skunk Works (Hersteller von Militärflugzeugen)
Lange als "Keep it simple, stupid" interpretiert
Johnson: 'Keep it simple [&] stupid'
so von vielen Autoren verwendet
Aufgabe zur Verdeutlichung des Prinzips
entwerfe Düsentriebwerk, dass
mit wenigen einfachen Werkzeugen
von einem durchschnittlichen Ingenieur 
im Felde unter Kampfbedingungen 
mit nur diesen Werkzeugen reparierbar ist
„stupid" 
zielt auf die Beziehung zwischen der Art und Weise, wie Dinge zu Bruch gehen, und deren Ausgereiftheit bezüglich der Reparatur
Es soll ein möglichst einfacher und „beschränkter“ Ansatz sein

KISS-Prinzip

Hintergründe
Verbreitet ist das KISS-Prinzip in
den United States Air Force 
der Softwareentwicklung
Designprinzip 
beschreibt es im Gegensatz zu einer Problemlösung in der Form einer Fehlerumgehung ("workaround") 
die möglichst einfache, minimalistische und leicht verständliche Lösung eines Problems
Beispiel ist die TCP/IP-Protokollfamilie
einfacher Aufbau der Protokolle führt zu enormer Skalierbarkeit
obwohl sie für ein kleines Netzwerksystem entwickelt wurden
Forschungszentren der DARPA
KISS-Prinzip immer häufiger im allgemeinen Zusammenhang mit komplexen Planungsaufgaben 

„Keep It Short and Simple“-Version an englischen Schulen und Universitäten
Schreiben von Essays, Inhaltsangaben und Interpretationen

Modellierung Modellierung, Entwurf und Betrieb (I)

Vergleich
Soll-Zustand 
beschreibt Schutzbedarf
Ist-Zustand
beschreibt Bedrohungs- und Risikoanalyse 
Ergebnis
Maßnahmen zur Abwehr der Bedrohungen
Klassifizierung der Maßnahmen
Wichtigkeit
Kosten
Aufwand

Modellierung, Entwurf und Betrieb (II)

Erfassung der erforderlichen Maßnahmen 
zur Erfüllung des Schutzbedarfs in Sicherheitsstrategie (security policy)
informell oder präzise formalisiert
Klassen von Anwendungen haben ähnliche Schutzbedürfnisse
deshalb können allgemeine Sicherheitsgrundfunktionen eingesetzt werden.
Kriterienkataloge definieren Funktionsklassen für Anwendungsszenarien
europäische ITSEC
internationale Common Criteria 
Anwender sollte klären 
ob seine Sicherheitsanforderungen bereits von einer dieser Klassen abgedeckt wird
welche Kombination von Grundfunktionen er braucht

Modellierung, Entwurf und Betrieb (III)

Systemarchitektur
Architekturgrobentwurf
Identifikation der zu schützenden Komponenten
Definition der Sicherheitskomponenten
Feinentwurf
Verfeinerung und detaillierte Spezifikation der Komponenten
präziser Rahmen für Implementierung
Wahl der nötigen Datenstrukturen, Algorithmen
Nutzung von Standardmechanismen
kryptografische Protokolle, Passwortschutz, ACLs, Protokolle zur Schlüsselverteilung,…

Validierung / Evaluierung

Testen
Methodisches Testen des implementierten Systems
Wenn möglich: Verifizierung der sicherheitsrelevanten Funktionen
Testziele, -pläne, -verfahren festlegen, dokumentieren.
Vollständigkeit der Tests
Code Review
Evaluierung durch Dritte

Sicherheitsgrundfunktionen (I)

Baukasten
Identifikation und Authentifikation
Rechteverwaltung
Rechteprüfung
Vollständigkeitsprinzip
Ausnahmen
Beweissicherung
Wiederaufbereitung
Gewährleistung der Funktionalität

Sicherheitsgrundfunktionen (II)

Baukasten
Identifikation und Authentifikation
Objekte / Subjekte müssen eindeutig identifizierbar sein
Identität nachweisen können
Abwehr von Maskierungsangriffen, unautorisierten Zugriffen
Sicherheitsanforderungen legen fest
ob und wenn ja, welche Subjekte zwar zu identifizieren, aber nicht zu authentifizieren sind.
Betriebssystem
Authentifikation nur bei Login
Gültigkeit späterer Aktionen beruhen auf Gültigkeit dieser Kontrolle
Internet-Banking
Authentifikation bei jeder relevanten Aktion (TAN)
Angabe, welche Aktionen zur Abwehr systematischer Angriffsversuche ergriffen werden
Protokollieren, Sperrung der Kennung

Sicherheitsgrundfunktionen (III)

Baukasten
 Rechteverwaltung
Basis zur Abwehr von Bedrohung der Integrität und Vertraulichkeit
Sicherheitsanforderungen legen Rechte für zu schützende Objekte fest
Vergabe (UNIX: owner-Prinzip)
Wahrnehmung
Rechteprüfung
Zugriffskontrolle
Bei welchen Aktionen muss Rechteprüfung stattfinden?
Vollständigkeitsprinzip
Jeder Zugriff sollte kontrolliert werden
Oft prüfen nur beim öffnen einer Datei
Danach Konformitätsprüfung: Wenn lesen, dann weiterlesen.
File Handles
Ausnahmen
Welche Aktionen bei unautorisierten Zugriffen
permission denied
Sicherheitsgrundfunktionen (IV)
Baukasten
Beweissicherung
Nichtabstreitbarkeit
Protokollierung
Computer-Forensik
Wiederaufbereitung
Maßnahmen zur Wiederaufbereitung von gemeinsam aber exklusiv nutzbaren Betriebsmitteln
Prozessor, Register, Cache
Gewährleistung der Funktionalität
Maßnahmen zur Gewährleistung der Verfügbarkeit
Abwehr von DoS
Priorisierung von Funktionalitäten
Einfaches Modell der Datenübertragung
Passiver Angreifer: nur abhören, nicht manipulieren
Bedrohung für Vertraulichkeit
Aktiver Angreifer: abhören, ändern, löschen, duplizieren
Bedrohung für Vertraulichkeit, Integrität, Authentizität
Unterschied Authentizität/Verbindlichkeit
Authentizität: Bob ist sicher, dass Daten von Alice kommen
Verbindlichkeit: Bob kann dies gegenüber Dritten beweisen
Modell I: Sichere Kommunikation über einen unsicheren Kanal
Modell II: Schutz durch Zugangskontrolle
Bewertungskriterien
Kriterienkataloge stellen Bewertungsschema zur Verfügung
Zertifikate
Nationale internationale Kataloge
Orange Book (US)
Grünbuch (DE)
ITSEC (Europa)
Common Criteria (international)
Themenfeld 8
Risikoanalyse
8.1	Die elementaren Gefährdungen sowie andere Gefährdungsübersichten
8.2	Vorgehen bei der Risikobewertung und Risikobehandlung
8.3	Beispiel für die Risikobewertung

Bedrohungsbaum
Möglicher Angriffspfad

BSI-Standard 100-3
Inhalte
1	Einleitung
2	Vorarbeiten
3	Erstellung der Gefährdungsübersicht
4	Ermittlung zusätzlicher Gefährdungen
5	Gefährdungsbewertung
6	Behandlung von Risiken
7	Konsolidierung des IT-Sicherheitskonzepts
8	Rückführung in den IT-Sicherheitsprozess
BSI-Standard 100-3
Ergänzende Sicherheitsanalyse
Eine „Ergänzende Sicherheitsanalyse“ 
ist durchzuführen, wenn: 
hoher oder sehr hoher Schutzbedarf
zusätzlicher Analysebedarf
für bestimmte Aspekte kein geeigneter Grundschutz-Katalog
Risikoanalyse 
Zweistufiges BSI-Modell
(1) Für 
normalern Schutzbedarf
übliche Einsatzszenarien
existierende Bausteine
qualitative Methode zur Risikoanalyse und -bewertung in der IT-Grundschutz-Vorgehensweise enthalten
beim Einsatz ähnlicher IT-Umgebungen und vergleichbarer Umfeldbedingungen meistens vergleichbare Bedrohungen 
(2) Für 
höheren Schutzbedarf
unübliche Einsatzszenarien
unzureichende Abdeckung mit Bausteinen
durch Management festgestellten Bedarf	
vereinfachte Risikoanalyse und -bewertung nach BSI-Standard 100-3
Vorarbeiten
Vor einer Risikoanalyse, sollten folgende Vorarbeiten abgeschlossen sein
Initiierung des Informationssicherheitsprozess
Definition des Geltungsbereiches für die Sicherheitskonzeption 
Strukturanalyse
Schutzbedarfsfeststellung 
Modellierung 
Basis-Sicherheitscheck 
ergänzende Sicherheitsanalyse
Erstellung der Gefährdungsübersicht
Erstellung der Gefährdungsübersicht
Vorgehen
Ausgangspunkt
relevante Gefährdungen au den IT-Grundschutz-Katalogen
für betrachtete Zielobjekte 
Bedrohungen, Schwachstellen und Risiken werden nicht separat untersucht
Ziel
Übersicht der Gefährdungen, die auf die betrachteten Zielobjekte wirken
Vorgehen
Reduzierung des Informationsverbundes auf die betrachteten Komponenten 
Zielobjekte streichen, für die kein Bedarf einer Risikoanalyse besteht
Bausteine streichen, für die kein Zielobjekt mehr übrig ist
in der Regel nur in den Schichten 2 bis 5
Erstellung der Gefährdungsübersicht
Vorgehen
Bausteine der IT-Grundschutz-Katalogen verweisen auf Gefährdungen
Je Zielobjekt werden Nummer und Titel dieser Gefährdungen aus den Bausteinen zusammengetragen 
und dem jeweiligen Zielobjekt zugeordnet
Gefährdungen aus den Bausteinen der Schichten 1 separat behandeln
spezielles Zielobjekt „gesamter Informationsverbund“

Ergebnis
Tabelle, die jedem Zielobjekt eine Liste mit relevanten Gefährdungen zuordnet 
doppelte oder mehrfach genannten Gefährdungen entfernen
Gefährdungen pro Zielobjekt thematisch sortieren
Einige Gefährdungen der Grundschutz-Kataloge
behandeln ähnliche Sicherheitsprobleme oder 
unterschiedliche Ausprägungen der gleichen Bedrohung
Beispiel
G 1.2 Ausfall des IT-Systems und G 4.31 Ausfall oder Störung von Netzkomponenten
Erstellung der Gefährdungsübersicht
Vorgehen
Zur Analyse in der Tabelle pro Zielobjekt Schutzbedarf vermerken
Grundwerte
Vertraulichkeit
Integrität 
Verfügbarkeit 
Für übergeordnetes Zielobjekt 
gesamter Informationsverbund 
kann Zuordnung entfallen
Ergebnis
Gefährdungsübersicht für 
die betrachteten Zielobjekte
dient als Ausgangspunkt 
für die nachfolgende Ermittlung 
zusätzlicher Gefährdungen.
Ermittlung zusätzlicher Gefährdungen
Ermittlung zusätzlicher Gefährdungen
Moderiertes Brainstorming
klarer Auftrag und Zeitbegrenzung
Gefährdungen, die nicht in den Grundschutzkatalogen aufgeführt sind
Realistische Gefährdungen mit nennenswerten Schäden
Grundwerte berücksichtigen
Schichtenmodell beachten
Höhere Gewalt
organisatorische Mängel
menschliche Fehlhandlungen
technisches Versagen
Außen-/Innentäter
Externe Quellen zu Rate ziehen
Gefährdungsbewertung
Gefährdungsbewertung
Eignung
Sind die IT-Sicherheitsmaßnahmen zur Abwehr der jeweiligen Gefährdungen geeignet?
Zusammenwirken
Wirken die IT-Sicherheitsmaßnahmen sinnvoll zusammen?
Benutzerfreundlichkeit
Sind die IT-Sicherheitsmaßnahmen einfach anzuwenden?
Angemessenheit
Sind die IT-Sicherheitsmaßnahmen angemessen?
Gefährdungsbewertung
Sind die vorgesehenen IT-Sicherheitsmaßnahmen ausreichend?
Prüfung der identifizierten Gefährdungen pro Zielobjekt
Prüfkriterien
Vollständigkeit
Mechanismenstärke
Zuverlässigkeit
Ergebnis: OK = Ja/Nein
Maßnahmenauswahl
Risikosteuerungsstrategien
Risikosteuerungsstrategien
Risikovermeidung
Risikoverminderung
Risikobegrenzung
Risikoüberwälzung
Risikoakzeptanz
Konsolidierung der Maßnahmen
Quellen und weitere Informationen
BITCOM: IT-Risiko- und Chancenmanagement im Unternehmen

Prozesse im Risikomanagement 
Leitbild für das IT Management
Angesichts der immer weiter steigenden Bedeutung der IT (Informationstechnologie) und den damit verbundenen Anforderungen, sowie einer Komplexität an IT-Infrastruktur Projekten, erfordert dies eine reibungslose Integration in die bestehenden Geschäftsprozesse. 
Um dies sicherzustellen, wurde die sogenannte IT-Governance, eine Weiterentwicklung der Corporate Governance, entworfen. 
Die IT-Governance richtet sich nach den Kernpunkten des COBIT Modells für das IT-Management. 
Das Modell ist generell anwendbar, international akzeptiert und lehnt sich besonders an die IT-Prozesse und die bestehenden Kontrollziele an. 
In einem Unternehmen sollten diese Kontrollziele nach Möglichkeit erreicht werden, um eine verlässliche Anwendung der IT zu gewährleisten. 
COBIT beschäftigt sich mit der Organisation von Daten, Anwendungen, Anlagen, der Technologie und dem Personal um die gestellten Anforderungen an die Geschäftsprozesse zu erfüllen.

Bedrohungsanalyse

Risikograph