Risiko/Management/tmp

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

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

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

Auswirkungen sind ungünstige Effekte, sollte das Risiko eintreten

• die Gefahr
• die Chance

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

Risikomanagementprozess
 Phasen
  Risikoanalyse
  Risikobewertung
  Risikominimierung
  Risikokontrolle
  Risikoverfolgung

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.

Methoden der Risikoidentifikation

Brainstorming

Brainstorming

Delphi-Methode

Delphi-Methode

Post-Mortem-Analyse

Post-Mortem-Analyse

Fehlermöglichkeits- und Einflussanalyse (FMEA)

Fehlermöglichkeits- und Einflussanalyse

Szenariotechnik

Monte-Carlo-Simulation, Szenariotechnik

SWOT-Analyse

SWOT-Analyse

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

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

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.

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

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

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

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

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)

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.