|
|
| (132 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| === Motivation ===
| | '''IT-Risikomanagement''' - QUELLENSAMMLUNG |
| ; 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 === | | === Risikomanagement === |
| Bedeutung
| | ; Bedeutung |
| Risikomanagement gewinnt an Bedeutung
| | * Risikomanagement gewinnt an Bedeutung |
| strategischen Bedeutung von
| | * strategischen Bedeutung von IT-Projekten |
| IT-Projekten
| | * IT-Projekte werden anspruchsvoller und komplexer |
| 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 === | | === Risikomanagement umfasst === |
| Festlegungen von Zielen auf Basis der Definition einer Strategie
| | ; Festlegungen von Zielen auf Basis der Definition einer Strategie |
| ggf. auch Visionen der das Risikomanagement anwendenden Stelle
| | * ggf. auch Visionen der das Risikomanagement anwendenden Stelle |
| Ohne konkrete Ziele lassen sich keine Abweichungen messen
| | * 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:
| | ; Definition von Werttreibern oder kritischen Erfolgsfaktoren zur Erreichung von Zielen |
| W = Wahrscheinlichkeit S = Schadenswirkung RF = Risikofaktor
| | * Festlegung einer Risikomanagement-Strategie |
| Qualität des IT-Managements
| | * abhängig von der Risikobereitschaft |
| Kernpunkte
| | ** risikoavers, risikoneutral oder risikofreudig |
| 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
| | ; Identifikation von Risiken |
| 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 ===
| | ; Bewertung/Messung von Risiken |
| === Bedrohungsmatix ===
| |
| === Bedrohungsanalyse ===
| |
| === Risikoberechnung ===
| |
| === Schlussfolgerung ===
| |
| Auch bei einfachem Angreifermodell sehr hohes Risiko
| |
| Passworte sollten nur verschlüsselt übertragen werden!
| |
| Zeitliche Entwicklung beachten
| |
|
| |
|
| === Konstruktion sicherer Systeme ===
| | ; Bewältigung von Risiken |
| 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) ===
| | ; Steuerung der Risikoabwehr |
| 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
| | ; Monitoring, also Früherkennung |
| Schreiben von Essays, Inhaltsangaben und Interpretationen
| | * Strukturierung und Dokumentation in einem Risikomanagementsystem |
|
| |
|
| === Modellierung ===
| | ; Prozesse im Risikomanagement |
| ==== Modellierung, Entwurf und Betrieb (I) ====
| | * Risikomanagementprozess |
| Vergleich
| | ** Phasen |
| Soll-Zustand
| | *** Risikoanalyse |
| beschreibt Schutzbedarf
| | *** Risikobewertung |
| Ist-Zustand
| | *** Risikominimierung |
| beschreibt Bedrohungs- und Risikoanalyse
| | *** Risikokontrolle |
| Ergebnis
| | *** Risikoverfolgung |
| Maßnahmen zur Abwehr der Bedrohungen
| |
| Klassifizierung der Maßnahmen
| |
| Wichtigkeit
| |
| Kosten
| |
| Aufwand
| |
|
| |
|
| ==== Modellierung, Entwurf und Betrieb (II) ====
| | ; Informationssicherheit-Risikomanagement-Prozess |
| Erfassung der erforderlichen Maßnahmen
| | * Risikomanagement |
| zur Erfüllung des Schutzbedarfs in Sicherheitsstrategie (security policy)
| | ** Teile des Risikomanagements |
| informell oder präzise formalisiert
| | *** Erkennung und Bewertung von Risiken |
| Klassen von Anwendungen haben ähnliche Schutzbedürfnisse
| | *** Erarbeitung und Umsetzung von Maßnahmen |
| deshalb können allgemeine Sicherheitsgrundfunktionen eingesetzt werden.
| | *** optimale Lösung finden |
| Kriterienkataloge definieren Funktionsklassen für Anwendungsszenarien
| | *** Risiken auf akzeptable Restrisiken reduzieren |
| europäische ITSEC
| | *** wichtigste Gefahrenquellen erkennen und abschwächen |
| 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) ====
| | ; Für jeden dieser Prozesse gilt |
| Systemarchitektur
| | * In Abhängigkeit der Bedürfnisse |
| Architekturgrobentwurf
| | * wird der Aufwand einer oder mehrerer Personen gefordert |
| Identifikation der zu schützenden Komponenten
| | * Jeder Prozess wird mindestens einmal durchlaufen |
| Definition der Sicherheitskomponenten
| | * Jeder Prozess tritt in einer oder mehreren Projektphasen auf |
| Feinentwurf
| | Überschneidung der Prozesse ist möglich |
| 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 ===
| | ; Risikomanagement |
| Testen
| | * Risikomanagement-Prozesse |
| Methodisches Testen des implementierten Systems
| | ** Risikomanagementplanung |
| Wenn möglich: Verifizierung der sicherheitsrelevanten Funktionen
| | * Wie wird das Risikomanagement organisiert? |
| Testziele, -pläne, -verfahren festlegen, dokumentieren.
| | * Wie viel Risikomanagement ist nötig? |
| Vollständigkeit der Tests
| | * Haben wir Erfahrungswerte in dieser Projektart? |
| Code Review
| | * Zuständigkeiten |
| Evaluierung durch Dritte
| | * Checklisten |
|
| |
|
| === Sicherheitsgrundfunktionen (I) ===
| | ; Risikoidentifikation |
| Baukasten
| | * Identifizierung potenzieller Risiken |
| Identifikation und Authentifikation
| | * Dokumentenanalyse |
| Rechteverwaltung
| | * Brainstorming |
| Rechteprüfung
| | * SWOT-Analyse |
| Vollständigkeitsprinzip
| | * Ursache-Wirkungs-Analysen |
| Ausnahmen
| | * Qualitative Risikoanalyse |
| Beweissicherung
| | * Eintrittswahrscheinlichkeit sowie Auswirkung |
| Wiederaufbereitung
| | * Priorisierung (z. B. A, B und C-Risiken) |
| Gewährleistung der Funktionalität
| |
|
| |
|
| ==== Sicherheitsgrundfunktionen (II) ====
| | ; Risikomanagement |
| Baukasten
| | * Bedeutung |
| Identifikation und Authentifikation
| | * Weitere Risiken |
| Objekte / Subjekte müssen eindeutig identifizierbar sein
| | * IT-Operations (Risiken aus dem laufenden Betrieb) |
| Identität nachweisen können
| | * Administrative Fehler |
| Abwehr von Maskierungsangriffen, unautorisierten Zugriffen
| | * Systemausfall |
| Sicherheitsanforderungen legen fest
| | * IT-Security (Sicherheitsrisiken) |
| ob und wenn ja, welche Subjekte zwar zu identifizieren, aber nicht zu authentifizieren sind.
| | * Unzureichende Sicherheits- und Schutzmaßnahmen für IT-Systeme |
| Betriebssystem
| | * Fehlende Autorisierung und Authentifizierung für Datenzugriff und -austausch |
| Authentifikation nur bei Login
| | * Nicht näher spezifizierte Risiken |
| Gültigkeit späterer Aktionen beruhen auf Gültigkeit dieser Kontrolle
| | * Fehlende Akzeptanz / Ablehnung der Anwender gegenüber neuer Software |
| Internet-Banking
| |
| Authentifikation bei jeder relevanten Aktion (TAN)
| |
| Angabe, welche Aktionen zur Abwehr systematischer Angriffsversuche ergriffen werden
| |
| Protokollieren, Sperrung der Kennung
| |
|
| |
|
| === Sicherheitsgrundfunktionen (III) === | | === Konzeptionierungsfehler === |
| Baukasten
| | Aufgrund der beschriebenen Problematik ist erkennbar, dass das Risikomanagement fester Bestandteil aller IT-Projekte sein sollte. |
| 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
| | ; Risikomanagementplanung |
| Möglicher Angriffspfad
| | * 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 |
|
| |
|
| BSI-Standard 100-3
| | ; Risikokategorien |
| Inhalte
| | * Für eine systematische Identifizierung der Risiken ist es wichtig, die verschiedenen Kategorien von Risiken zu kennen |
| 1 Einleitung
| | * Die Unterteilung kann dabei je nach Verständnis, Betrachtungsweise und Kontext unterschiedlich sein. |
| 2 Vorarbeiten
| | * Im betriebswirtschaftlichen Sinne gibt es z. B. die Unterscheidung von externen, internen, finanziellen und operativen Risiken. |
| 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
| | === Schlussfolgerung === |
| Tabelle, die jedem Zielobjekt eine Liste mit relevanten Gefährdungen zuordnet
| | * Auch bei einfachem Angreifermodell sehr hohes Risiko |
| doppelte oder mehrfach genannten Gefährdungen entfernen
| | * Passworte sollten nur verschlüsselt übertragen werden! |
| Gefährdungen pro Zielobjekt thematisch sortieren
| | * Zeitliche Entwicklung beachten |
| 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 ===
| |
|
| |
|
| | == 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. |
| [[Kategorie:Tmp]] | | [[Kategorie:Tmp]] |