Risiko/Management/tmp: Unterschied zwischen den Versionen
| Zeile 24: | Zeile 24: | ||
Ziele eines Unternehmens | Ziele eines Unternehmens | ||
Gewinnoptimierung, Marktetablierung, Existenzsicherung, ... | Gewinnoptimierung, Marktetablierung, Existenzsicherung, ... | ||
Betrachtung von Risiken | Betrachtung von Risiken | ||
essenzieller Bestandteil unternehmerischen Handelns | essenzieller Bestandteil unternehmerischen Handelns | ||
Risiken nicht nur als Gefahr ansehen | Risiken nicht nur als Gefahr ansehen | ||
Chance und notwendige Voraussetzung für die Zielerreichung | Chance und notwendige Voraussetzung für die Zielerreichung | ||
Risiken nicht rein negativ beurteilen | Risiken nicht rein negativ beurteilen | ||
mit Risiken richtig umgehen | mit Risiken richtig umgehen | ||
Risiken in Chancen umwandeln | Risiken in Chancen umwandeln | ||
Unternehmen muss jederzeit in der Lage sein | Unternehmen muss jederzeit in der Lage sein | ||
unternehmensweit konsistente Ertrags- und Risikoinformationen zu ermitteln | unternehmensweit konsistente Ertrags- und Risikoinformationen zu ermitteln | ||
Effizientes Risikomanagement von strategischer Bedeutung | Effizientes Risikomanagement von strategischer Bedeutung | ||
| Zeile 39: | Zeile 39: | ||
Erzeugt selbst Risiken | Erzeugt selbst Risiken | ||
=== Motivation === | === Motivation === | ||
Standish Group im Jahre 2009 Umfrage | Standish Group im Jahre 2009 Umfrage | ||
Nur ein Drittel aller IT-Projekte werden im geplanten Zeit- und Budgetrahmen beendet | Nur ein Drittel aller IT-Projekte werden im geplanten Zeit- und Budgetrahmen beendet | ||
fast die Hälfte diese Vorgaben nicht erfüllen | fast die Hälfte diese Vorgaben nicht erfüllen | ||
der Rest wird abgebrochen | der Rest wird abgebrochen | ||
=== Motivation === | === Motivation === | ||
IT-Projekte | IT-Projekte | ||
| Zeile 55: | Zeile 55: | ||
negative Abweichung des realisierten Ergebnisses vom Erwartungswert | negative Abweichung des realisierten Ergebnisses vom Erwartungswert | ||
Risiko = Eintrittswahrscheinlichkeit x Auswirkungen | Risiko = Eintrittswahrscheinlichkeit x Auswirkungen | ||
Einfache Gleichung für das Risiko | Einfache Gleichung für das Risiko | ||
=== Je geringer die Eintrittswahrscheinlichkeit, umso seltener | === Je geringer die Eintrittswahrscheinlichkeit, umso seltener === | ||
die Gefahr | die Gefahr | ||
die Chance | die Chance | ||
Auswirkungen sind ungünstige Effekte, sollte das Risiko eintreten | Auswirkungen sind ungünstige Effekte, sollte das Risiko eintreten | ||
=== Risiken sind Teil des Geschäftes === | === Risiken sind Teil des Geschäftes === | ||
Einige der Risiken spielen dabei nie eine Rolle, andere können bedrohlich werden. | 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. | Risikomanagement hilft, Risiken zu erkennen, zu analysieren, zu bewerten und mit den entsprechenden Techniken abzuschwächen. | ||
=== BSI-Standard 200-3 === | === BSI-Standard 200-3 === | ||
Risikoanalyse | Risikoanalyse | ||
| Zeile 68: | Zeile 68: | ||
BSI-Standard 200-3 | BSI-Standard 200-3 | ||
Risikoanalyse auf der Basis von IT-Grundschutz | Risikoanalyse auf der Basis von IT-Grundschutz | ||
klassische Risikoanalyse | klassische Risikoanalyse | ||
ISO 27001, 27005, 31000, 31010 | ISO 27001, 27005, 31000, 31010 | ||
Penetrationstest | Penetrationstest | ||
| Zeile 75: | Zeile 75: | ||
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 === | === Gründe === | ||
Expansion / Globalisierung der Geschäftstätigkeit | Expansion / Globalisierung der Geschäftstätigkeit | ||
Automatisierung von Geschäftsprozessen | Automatisierung von Geschäftsprozessen | ||
Steigende Abhängigkeit von Verfügbarkeit und Sicherheit der Datenverarbeitung | Steigende Abhängigkeit von Verfügbarkeit und Sicherheit der Datenverarbeitung | ||
Neuartige Geschäftsprozesse aufgrund steigender Marktdynamik durch neue Technologien | Neuartige Geschäftsprozesse aufgrund steigender Marktdynamik durch neue Technologien | ||
Inhärenten Risiken bei IT-Projekten im Vergleich zu anderen Projekten | Inhärenten Risiken bei IT-Projekten im Vergleich zu anderen Projekten | ||
=== Risikomanagement umfasst === | === Risikomanagement umfasst === | ||
| Zeile 90: | Zeile 90: | ||
Definition von Werttreibern oder kritischen Erfolgsfaktoren zur Erreichung von Zielen | Definition von Werttreibern oder kritischen Erfolgsfaktoren zur Erreichung von Zielen | ||
Festlegung einer Risikomanagement-Strategie | Festlegung einer Risikomanagement-Strategie | ||
abhängig von der Risikobereitschaft | abhängig von der Risikobereitschaft | ||
risikoavers, risikoneutral oder risikofreudig | risikoavers, risikoneutral oder risikofreudig | ||
Identifikation von Risiken | Identifikation von Risiken | ||
| Zeile 98: | Zeile 98: | ||
Monitoring, also Früherkennung | Monitoring, also Früherkennung | ||
Strukturierung und Dokumentation in einem Risikomanagementsystem | Strukturierung und Dokumentation in einem Risikomanagementsystem | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Risikomanagementprozess | Risikomanagementprozess | ||
Phasen | Phasen | ||
| Zeile 121: | Zeile 121: | ||
Jeder Prozess wird mindestens einmal durchlaufen | Jeder Prozess wird mindestens einmal durchlaufen | ||
Jeder Prozess tritt in einer oder mehreren Projektphasen auf | Jeder Prozess tritt in einer oder mehreren Projektphasen auf | ||
Überschneidung der Prozesse ist möglich | Überschneidung der Prozesse ist möglich | ||
Risikomanagement | Risikomanagement | ||
Risikomanagement-Prozesse | Risikomanagement-Prozesse | ||
Risikomanagementplanung | Risikomanagementplanung | ||
Wie wird das Risikomanagement organisiert? | Wie wird das Risikomanagement organisiert? | ||
Wie viel Risikomanagement ist nötig? | Wie viel Risikomanagement ist nötig? | ||
Haben wir Erfahrungswerte in dieser Projektart? | Haben wir Erfahrungswerte in dieser Projektart? | ||
Zuständigkeiten | Zuständigkeiten | ||
Checklisten | Checklisten | ||
Risikoidentifikation | Risikoidentifikation | ||
Identifizierung potenzieller Risiken | Identifizierung potenzieller Risiken | ||
Dokumentenanalyse | Dokumentenanalyse | ||
| Zeile 144: | Zeile 144: | ||
IT-Operations (Risiken aus dem laufenden Betrieb) | IT-Operations (Risiken aus dem laufenden Betrieb) | ||
Administrative Fehler | Administrative Fehler | ||
Systemausfall | Systemausfall | ||
IT-Security (Sicherheitsrisiken) | IT-Security (Sicherheitsrisiken) | ||
Unzureichende Sicherheits- und Schutzmaßnahmen für IT-Systeme | Unzureichende Sicherheits- und Schutzmaßnahmen für IT-Systeme | ||
Fehlende Autorisierung und Authentifizierung für Datenzugriff und -austausch | Fehlende Autorisierung und Authentifizierung für Datenzugriff und -austausch | ||
Nicht näher spezifizierte Risiken | Nicht näher spezifizierte Risiken | ||
Fehlende Akzeptanz / Ablehnung der Anwender gegenüber neuer Software | Fehlende Akzeptanz / Ablehnung der Anwender gegenüber neuer Software | ||
=== Konzeptionierungsfehler === | === Konzeptionierungsfehler === | ||
Aufgrund der beschriebenen Problematik ist erkennbar, dass das Risikomanagement fester Bestandteil aller IT-Projekte sein sollte. | Aufgrund der beschriebenen Problematik ist erkennbar, dass das Risikomanagement fester Bestandteil aller IT-Projekte sein sollte. | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Risikomanagementplanung | Risikomanagementplanung | ||
Wie sollen die Aktivitäten des Risikomanagement durchgeführt werden? | Wie sollen die Aktivitäten des Risikomanagement durchgeführt werden? | ||
Risikomanagementplanung legt Vorgehensweise fest | Risikomanagementplanung legt Vorgehensweise fest | ||
Planung soll sicherstellen | Planung soll sicherstellen | ||
Risikomanagement ist in Bezug auf Risiken und der Bedeutung des Projektes angemessen | Risikomanagement ist in Bezug auf Risiken und der Bedeutung des Projektes angemessen | ||
Es stehen ausreichende Ressourcen für die Aktivitäten zur Verfügung | Es stehen ausreichende Ressourcen für die Aktivitäten zur Verfügung | ||
Erfolgschancen erhöhen | Erfolgschancen erhöhen | ||
gut strukturierte und sorgfältig vorbereitete Planung | gut strukturierte und sorgfältig vorbereitete Planung | ||
erleichtert Durchführung der anderen Risikomanagement-Prozesse | erleichtert Durchführung der anderen Risikomanagement-Prozesse | ||
Erstellung eines Risikomanagementplans | Erstellung eines Risikomanagementplans | ||
Zusammenarbeit mit | Zusammenarbeit mit | ||
Projektleitern und -mitgliedern | Projektleitern und -mitgliedern | ||
Stakeholdern | Stakeholdern | ||
für das Risikomanagement im Unternehmen zuständige Mitarbeiter | für das Risikomanagement im Unternehmen zuständige Mitarbeiter | ||
Auswirkungen haben dabei Risikobereitschaft und Risikotoleranz | Auswirkungen haben dabei Risikobereitschaft und Risikotoleranz | ||
des Unternehmens und | des Unternehmens und | ||
der Projektbeteiligten | der Projektbeteiligten | ||
Hilfreich zur Erstellung | Hilfreich zur Erstellung | ||
bereits definierte Ansätze und Konzepte für das Risikomanagement im Unternehmen | bereits definierte Ansätze und Konzepte für das Risikomanagement im Unternehmen | ||
allgemein oder aus vorangegangenen Projekten | allgemein oder aus vorangegangenen Projekten | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Risikomanagementplan | Risikomanagementplan | ||
Inhalte | Inhalte | ||
| Zeile 186: | Zeile 186: | ||
Risikokategorien | Risikokategorien | ||
Strukturen für die Risikoidentifikation festlegen | Strukturen für die Risikoidentifikation festlegen | ||
Definition der Risikowahrscheinlichkeiten und -auswirkungen | Definition der Risikowahrscheinlichkeiten und -auswirkungen | ||
als Unterstützung der Risikoanalyse | als Unterstützung der Risikoanalyse | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Risikoidentifikation | Risikoidentifikation | ||
Für eine Beherrschung der Risiken, muss man diese zunächst kennen | Für eine Beherrschung der Risiken, muss man diese zunächst kennen | ||
| Zeile 196: | Zeile 196: | ||
es entwickeln sich neue oder übersehene Risiken | 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. | 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 | Nach Identifizierung von Risiken | ||
Priorisierung mit Hilfe der Risikoanalyse | Priorisierung mit Hilfe der Risikoanalyse | ||
Risikokategorien | |||
Für eine systematische Identifizierung der Risiken ist es wichtig, die verschiedenen Kategorien von Risiken zu kennen | 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. | 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. | Im betriebswirtschaftlichen Sinne gibt es z. B. die Unterscheidung von externen, internen, finanziellen und operativen Risiken. | ||
=== Prozesse im Risikomanagement | === Prozesse im Risikomanagement === | ||
Risikoidentifikation | Risikoidentifikation | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Methoden der Risikoidentifikation | Methoden der Risikoidentifikation | ||
=== Brainstorming === | === Brainstorming === | ||
Innerhalb einer Arbeitsgruppe Ideen sammeln | Innerhalb einer Arbeitsgruppe Ideen sammeln | ||
| Zeile 215: | Zeile 215: | ||
=== Delphi-Methode === | === Delphi-Methode === | ||
Befragungstechnik um eine von Experten erstellte Prognose zu erhalten | Befragungstechnik um eine von Experten erstellte Prognose zu erhalten | ||
Mit Hilfe eines Fragebogens | Mit Hilfe eines Fragebogens | ||
Ideen der Teilnehmer basierend auf Ihrem fachlichen Know-how zusammengefasst | Ideen der Teilnehmer basierend auf Ihrem fachlichen Know-how zusammengefasst | ||
Direkter Austausch der Experten untereinander muss unterbunden werden | Direkter Austausch der Experten untereinander muss unterbunden werden | ||
Antworten sollen frei von Beeinflussungen sein | Antworten sollen frei von Beeinflussungen sein | ||
Antworten werden zur Kommentierung an die anderen Experten weitergereicht | 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 | Nach einigen Durchläufen liegt ein aussagekräftiges Ergebnis vor, welches frei von Voreingenommenheiten sein sollte | ||
| Zeile 226: | Zeile 226: | ||
systematische Erhebung aller möglichen Ausfall- und Ursachenkombinationen | systematische Erhebung aller möglichen Ausfall- und Ursachenkombinationen | ||
daraus können potenzielle Risiken für das Projekt sichtbar werden | daraus können potenzielle Risiken für das Projekt sichtbar werden | ||
=== Prozesse im Risikomanagement | === Prozesse im Risikomanagement === | ||
Methoden der Risikoidentifikation | Methoden der Risikoidentifikation | ||
Fehlermöglichkeits- und Einflussanalyse (FMEA) | Fehlermöglichkeits- und Einflussanalyse (FMEA) | ||
Ein System wird in einzelne Betrachtungseinheiten/Funktionsbereiche zerlegt | Ein System wird in einzelne Betrachtungseinheiten/Funktionsbereiche zerlegt | ||
Auf Basis der einzelnen Funktionen werden Schwachstellen herausgebildet | Auf Basis der einzelnen Funktionen werden Schwachstellen herausgebildet | ||
potentielle Fehlermöglichkeiten erkennen | potentielle Fehlermöglichkeiten erkennen | ||
Ursachen und Auswirkungen werden systematisch anhand der Funktionsbereiche ermittelt | Ursachen und Auswirkungen werden systematisch anhand der Funktionsbereiche ermittelt | ||
=== Szenariotechnik === | === Szenariotechnik === | ||
| Zeile 238: | Zeile 238: | ||
Ziel: Ermittlung möglicher Worst-Case Szenarien bzw. das Finden neuer möglicher Risiken | Ziel: Ermittlung möglicher Worst-Case Szenarien bzw. das Finden neuer möglicher Risiken | ||
=== SWOT-Analyse === | === SWOT-Analyse === | ||
Projekt wird unter jedem der SWOT-Aspekte betrachtet | Projekt wird unter jedem der SWOT-Aspekte betrachtet | ||
erhöht die Bandbreite der betrachteten Risiken | erhöht die Bandbreite der betrachteten Risiken | ||
SWOT-Analyse ist ganzheitlicher und auch positiver ausgerichtet als andere Methoden | SWOT-Analyse ist ganzheitlicher und auch positiver ausgerichtet als andere Methoden | ||
| Zeile 244: | Zeile 244: | ||
ermöglicht eine direkte Umsetzung von Stärken und Chancen auf strategische oder operative Vorteile | 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 | Schnittstellenrisiken zwischen Projekten und dem Unternehmen können identifiziert werden | ||
=== Prozesse im Risikomanagement | === Prozesse im Risikomanagement === | ||
Risikoidentifikation: Aufbereitung identifizierter Risiken | Risikoidentifikation: Aufbereitung identifizierter Risiken | ||
Identifizierte Risiken müssen aufbereitet werden | Identifizierte Risiken müssen aufbereitet werden | ||
| Zeile 255: | Zeile 255: | ||
Liste der möglichen Bewältigungsmaßnahmen, sofern bereits identifiziert | Liste der möglichen Bewältigungsmaßnahmen, sofern bereits identifiziert | ||
Liste der Grundursachen identifizierter Risiken | Liste der Grundursachen identifizierter Risiken | ||
Liste der Risikokategorien | Liste der Risikokategorien | ||
=== Prozesse im Risikomanagement === | === Prozesse im Risikomanagement === | ||
Risikoanalyse: Qualitative Risikoanalyse | Risikoanalyse: Qualitative Risikoanalyse | ||
Schnelle und kosteneffektive Vorgehensweise | Schnelle und kosteneffektive Vorgehensweise | ||
Methoden zur Priorisierung der identifizierten Risiken | Methoden zur Priorisierung der identifizierten Risiken | ||
Grundstein für die quantitative Risikoanalyse | Grundstein für die quantitative Risikoanalyse | ||
trägt zur Risikobewältigungsplanung bei | trägt zur Risikobewältigungsplanung bei | ||
bezieht Informationen aus der Risikomanagementplanung und der Risikoidentifikation | bezieht Informationen aus der Risikomanagementplanung und der Risikoidentifikation | ||
Konzentration auf Risiken mit hoher Priorität | Konzentration auf Risiken mit hoher Priorität | ||
Prioritäten identifizierter Risiken bewerten | Prioritäten identifizierter Risiken bewerten | ||
Anhand der Eintrittswahrscheinlichkeit | Anhand der Eintrittswahrscheinlichkeit | ||
daraus resultierenden Auswirkungen auf die gesteckten Ziele | daraus resultierenden Auswirkungen auf die gesteckten Ziele | ||
Zeitrahmen | Zeitrahmen | ||
Risikotoleranz | Risikotoleranz | ||
Budgetkosten | Budgetkosten | ||
Umfang und Qualität | Umfang und Qualität | ||
Bedeutung eines Risikos besser zu verstehen | Bedeutung eines Risikos besser zu verstehen | ||
qualitative Bewertung der verfügbaren Informationen | 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. | Risikobezogene Maßnahmen sind oftmals sehr zeitkritisch und können somit die Bedeutung oder Auswirkung eines Risikos stark erhöhen. | ||
=== Laufender Prozess === | === Laufender Prozess === | ||
Die qualitative Risikoanalyse sollte im Laufe des Projektes ständig wiederholt werden, da sich Änderungen an den Projektrisiken ergeben können. | Die qualitative Risikoanalyse sollte im Laufe des Projektes ständig wiederholt werden, da sich Änderungen an den Projektrisiken ergeben können. | ||
=== Prozesse im Risikomanagement === | === Prozesse im Risikomanagement === | ||
Risikoanalyse: Quantitative Risikoanalyse | Risikoanalyse: Quantitative Risikoanalyse | ||
Aufbauend auf qualitativer Risikoanalyse | Aufbauend auf qualitativer Risikoanalyse | ||
durchgeführte Priorisierung der Risiken | durchgeführte Priorisierung der Risiken | ||
einige Risikomanager führen sie gerne direkt nach der Risikoidentifikation durch | einige Risikomanager führen sie gerne direkt nach der Risikoidentifikation durch | ||
Auswirkungen werden analysiert | Auswirkungen werden analysiert | ||
numerische Einstufung der Risiken | numerische Einstufung der Risiken | ||
Somit wird gleichzeitig ein erster Ansatz für die Entscheidungsfindung erstellt | Somit wird gleichzeitig ein erster Ansatz für die Entscheidungsfindung erstellt | ||
=== Methoden === | === Methoden === | ||
Monte-Carlo-Simulation (Szenariotechnik) | Monte-Carlo-Simulation (Szenariotechnik) | ||
Entscheidungsbaum-Analyse(Fehleranalyse) | Entscheidungsbaum-Analyse(Fehleranalyse) | ||
Ziele | Ziele | ||
Wahrscheinlichkeitsbestimmung von möglichen Ergebnissen | Wahrscheinlichkeitsbestimmung von möglichen Ergebnissen | ||
Identifizierung von Risiken mit der höchsten Aufmerksamkeit | Identifizierung von Risiken mit der höchsten Aufmerksamkeit | ||
Realistischen Bestimmung von Kosten, Terminen und Umfangszielen | Realistischen Bestimmung von Kosten, Terminen und Umfangszielen | ||
Bestimmung der besten Managemententscheidung, sollten einige Faktoren unbekannt sein | Bestimmung der besten Managemententscheidung, sollten einige Faktoren unbekannt sein | ||
=== Prozesse im Risikomanagement === | === Prozesse im Risikomanagement === | ||
Risikobewältigungsplanung | Risikobewältigungsplanung | ||
Vorgehensweisen und Verfahren | Vorgehensweisen und Verfahren | ||
Erreichen von Projektzielen | Erreichen von Projektzielen | ||
Gefahren vermeiden | Gefahren vermeiden | ||
Aufbauend auf Risikoanalyse | Aufbauend auf Risikoanalyse | ||
| Zeile 307: | Zeile 307: | ||
kosteneffektiv | kosteneffektiv | ||
termingerecht | termingerecht | ||
realistisch | realistisch | ||
=== Vorgaben an das Risikomanagement | === Vorgaben an das Risikomanagement === | ||
von betriebsinternen Projektmitgliedern | von betriebsinternen Projektmitgliedern | ||
von Vertragspartnern, Behörden, Gesetzgeber | von Vertragspartnern, Behörden, Gesetzgeber | ||
Vertragspartner (meist zeitliche, aber auch Qualitätsvorgaben) | Vertragspartner (meist zeitliche, aber auch Qualitätsvorgaben) | ||
Gesetzgeber (Auflagen bzgl. des Datenschutzes und der Aufbewahrung von z.B E-Mails) | 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) | 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 | Prozesse im Risikomanagement | ||
=== Risikobewältigungsplanung === | === Risikobewältigungsplanung === | ||
| Zeile 319: | Zeile 319: | ||
Vermeiden/Minimieren | Vermeiden/Minimieren | ||
z.B durch Verbesserung der Kommunikation innerhalb des Projektteams und den Vertragspartnern | z.B durch Verbesserung der Kommunikation innerhalb des Projektteams und den Vertragspartnern | ||
Vermindern | Vermindern | ||
z.B durch Änderungen an der Organisation um Projektziele oder Meilensteine nicht zu gefährden | z.B durch Änderungen an der Organisation um Projektziele oder Meilensteine nicht zu gefährden | ||
Abwälzen/Übertragen | Abwälzen/Übertragen | ||
z.B an den Auftraggeber oder Lieferanten durch entsprechende Vertragsklauseln etc. | z.B an den Auftraggeber oder Lieferanten durch entsprechende Vertragsklauseln etc. | ||
Selbstübernehmen/Akzeptieren | Selbstübernehmen/Akzeptieren | ||
meist nur bei eher unbedeutenden Risiken/Bildung von Reserven | meist nur bei eher unbedeutenden Risiken/Bildung von Reserven | ||
=== Prozesse im Risikomanagement === | === Prozesse im Risikomanagement === | ||
Risikocontrolling: Risikoinventur | Risikocontrolling: Risikoinventur | ||
Risikoinventur | Risikoinventur | ||
erfasst Schäden durch Risiken | erfasst Schäden durch Risiken | ||
Hierbei spielen Eintrittswahrscheinlichkeit sowie Ursachen eine Rolle | Hierbei spielen Eintrittswahrscheinlichkeit sowie Ursachen eine Rolle | ||
Grundlagen zur strukturierten Darstellung | Grundlagen zur strukturierten Darstellung | ||
Vollständigkeit | Vollständigkeit | ||
alle Risiken | alle Risiken | ||
| Zeile 338: | Zeile 338: | ||
Beispiel | Beispiel | ||
Es kommt in einem Serverraum zu einem Brand, durch ein defektes Netzteil | Es kommt in einem Serverraum zu einem Brand, durch ein defektes Netzteil | ||
Der Schaden steigt erheblich | Der Schaden steigt erheblich | ||
überfällige Wartung des Brandbekämpfungssystems | überfällige Wartung des Brandbekämpfungssystems | ||
langanhaltende Betriebsunterbrechung | langanhaltende Betriebsunterbrechung | ||
| Zeile 364: | Zeile 364: | ||
Bruttobewertung | Bruttobewertung | ||
grundsätzlichen Bedrohungspotenziale werden betrachtet | grundsätzlichen Bedrohungspotenziale werden betrachtet | ||
wo liegen Schwerpunkte der Risikosteuerung | wo liegen Schwerpunkte der Risikosteuerung | ||
Nettobewertung | Nettobewertung | ||
Risiken bereits bestehenden Steuerungs- und Kontrollmaßnahmen gegenüberstellen | Risiken bereits bestehenden Steuerungs- und Kontrollmaßnahmen gegenüberstellen | ||
Aktuelle Risikolage | Aktuelle Risikolage | ||
Wir ermittelt | Wir ermittelt | ||
Eignung und Angemessenheit bestehender Maßnahmen festgestellen | Eignung und Angemessenheit bestehender Maßnahmen festgestellen | ||
| Zeile 373: | Zeile 373: | ||
Vor einer Bewertung der Risiken | Vor einer Bewertung der Risiken | ||
Maßstab für Schadensausmaß und Eintrittswahrscheinlichkeit eingrenzen | Maßstab für Schadensausmaß und Eintrittswahrscheinlichkeit eingrenzen | ||
Schätzungen oder Erfahrungswerten durch die Verantwortlichen | Schätzungen oder Erfahrungswerten durch die Verantwortlichen | ||
Worst-Case-Szenario | Worst-Case-Szenario | ||
klare Grenzen zwischen den einzelnen Gefahrenstufen | klare Grenzen zwischen den einzelnen Gefahrenstufen | ||
Prozesse im Risikomanagement | Prozesse im Risikomanagement | ||
Bewertung und Messung von Risiken | Bewertung und Messung von Risiken | ||
Ampelmodell | Ampelmodell | ||
besonders geeignet | besonders geeignet | ||
Akzeptanzlinie | Akzeptanzlinie | ||
Rote Linie zwischen akzeptablen und kritischem Bereich | Rote Linie zwischen akzeptablen und kritischem Bereich | ||
Toleranzgrenze | Toleranzgrenze | ||
Rote Linie zwischen Grenzbereich und inakzeptablem Bereich | Rote Linie zwischen Grenzbereich und inakzeptablem Bereich | ||
Risiken, unterhalb dieser Linie, gelten als tolerierbar | Risiken, unterhalb dieser Linie, gelten als tolerierbar | ||
wenn es möglich ist | wenn es möglich ist | ||
durch Maßnahmen diese unter Kontrolle zu halten | durch Maßnahmen diese unter Kontrolle zu halten | ||
oder sogar in den akzeptablen Bereich zu bringen | oder sogar in den akzeptablen Bereich zu bringen | ||
Festlegung der Grenzen wird durch Verantwortliche vorgenommen | Festlegung der Grenzen wird durch Verantwortliche vorgenommen | ||
Bewertung und Messung von Risiken | Bewertung und Messung von Risiken | ||
Kriterien | Kriterien | ||
Ungewissheit | Ungewissheit | ||
Unsicherheit | Unsicherheit | ||
Abschätzungssicherheit | Abschätzungssicherheit | ||
Ahnungslosigkeit | Ahnungslosigkeit | ||
Ausbreitungsgrad des potenziellen Schadens | Ausbreitungsgrad des potenziellen Schadens | ||
zeitlicher Ausdehnungsgrad nach Eintritt | zeitlicher Ausdehnungsgrad nach Eintritt | ||
Möglichkeit den Ursprungszustand wiederherzustellen | Möglichkeit den Ursprungszustand wiederherzustellen | ||
z.B durch einspielen eines Backups | z.B durch einspielen eines Backups | ||
Verzögernde Wirkung des Schadens | Verzögernde Wirkung des Schadens | ||
evtl. nicht direkt sichtbar | evtl. nicht direkt sichtbar | ||
Mobilisierungspotenzial der beteiligten Mitarbeiter | Mobilisierungspotenzial der beteiligten Mitarbeiter | ||
nach einem Schaden weiter zu machen | nach einem Schaden weiter zu machen | ||
Ergebnis: qualitative und quantitative Bewertung von Risiken | Ergebnis: qualitative und quantitative Bewertung von Risiken | ||
quantitativen Bewertung | quantitativen Bewertung | ||
Schadenshöhe/Intensität der Auswirkung | Schadenshöhe/Intensität der Auswirkung | ||
Eintrittswahrscheinlichkeit | Eintrittswahrscheinlichkeit | ||
qualitative Bewertung | qualitative Bewertung | ||
Aggregation (Zusammenlegung) von Risiken im Hinblick auf die Erreichung von Zielen | Aggregation (Zusammenlegung) von Risiken im Hinblick auf die Erreichung von Zielen | ||
Bewertung und Messung von Risiken | Bewertung und Messung von Risiken | ||
| Zeile 417: | Zeile 417: | ||
Erfahrungen bei vorrangegangenen Projekten: | Erfahrungen bei vorrangegangenen Projekten: | ||
Änderungen während des Projekts | Änderungen während des Projekts | ||
z. B. Änderung der Meilensteinen | z. B. Änderung der Meilensteinen | ||
oder im schlimmsten Fall am eigentlichen Projektziel | oder im schlimmsten Fall am eigentlichen Projektziel | ||
Dies sind Risiken, die komplette Projekte bedrohen oder sogar stoppen können | Dies sind Risiken, die komplette Projekte bedrohen oder sogar stoppen können | ||
| Zeile 427: | Zeile 427: | ||
Kein klar definiertes Ziel | Kein klar definiertes Ziel | ||
Mangelhaftes Anforderungsmanagement während des Planungsprozesses, ergeben stetig neue Projektänderungen | Mangelhaftes Anforderungsmanagement während des Planungsprozesses, ergeben stetig neue Projektänderungen | ||
Oftmals wird der Benutzer nicht in die Planung mit einbezogen | Oftmals wird der Benutzer nicht in die Planung mit einbezogen | ||
Wie wahrscheinlich ist das Risiko? | Wie wahrscheinlich ist das Risiko? | ||
Eintrittswahrscheinlichkeit 5 – sehr hoch | Eintrittswahrscheinlichkeit 5 – sehr hoch | ||
Schadenswirkung 4 – hoch | Schadenswirkung 4 – hoch | ||
Risikofaktor | Risikofaktor | ||
Wahrscheinlichkeit (5) * Schadenswirkung (4) = Risikofaktor (20) | Wahrscheinlichkeit (5) * Schadenswirkung (4) = Risikofaktor (20) | ||
Mit dem errechneten Risikofaktor landet dieses Risiko im nicht tolerierbaren Bereich (Stern Abb.). | Mit dem errechneten Risikofaktor landet dieses Risiko im nicht tolerierbaren Bereich (Stern Abb.). | ||
Bewertung und Messung von Risiken | Bewertung und Messung von Risiken | ||
Berechnung des Faktors eines Risikos | Berechnung des Faktors eines Risikos | ||
Beispiele für weitere Risiken (Gefahrenbereiche) | Beispiele für weitere Risiken (Gefahrenbereiche) | ||
Einsatz neuer Technologien | Einsatz neuer Technologien | ||
W(4) * S(5) = RF(20) | W(4) * S(5) = RF(20) | ||
Implementierungen ohne Entwurf | Implementierungen ohne Entwurf | ||
W(4) * S(4) = RF(16) | W(4) * S(4) = RF(16) | ||
Unmotivierte Mitarbeiter | Unmotivierte Mitarbeiter | ||
W(3) * S(5) = RF(15) | W(3) * S(5) = RF(15) | ||
Mitarbeiterfluktuation | Mitarbeiterfluktuation | ||
W(2) * S(4) = RF(8) | W(2) * S(4) = RF(8) | ||
Machtkämpfe | Machtkämpfe | ||
W(1) * S(2) = RF(2) | W(1) * S(2) = RF(2) | ||
Unzureichende Reviews | Unzureichende Reviews | ||
W(3) * S(4) = RF(12) | W(3) * S(4) = RF(12) | ||
Legende: | Legende: | ||
W = Wahrscheinlichkeit S = Schadenswirkung RF = Risikofaktor | W = Wahrscheinlichkeit S = Schadenswirkung RF = Risikofaktor | ||
Qualität des IT-Managements | Qualität des IT-Managements | ||
Kernpunkte | Kernpunkte | ||
| Zeile 459: | Zeile 459: | ||
Sind die Ziele der IT von allen Mitarbeitern verstanden? | Sind die Ziele der IT von allen Mitarbeitern verstanden? | ||
Sind die IT-Risiken erkannt, verstanden und unter Kontrolle? | Sind die IT-Risiken erkannt, verstanden und unter Kontrolle? | ||
Ist die Qualität der IT-Systeme angemessen für die geschäftlichen Anforderungen? | Ist die Qualität der IT-Systeme angemessen für die geschäftlichen Anforderungen? | ||
Beschaffung und Einführung neuer Systeme | Beschaffung und Einführung neuer Systeme | ||
Liefern neue Projekte voraussichtlich Lösungen, die den geschäftlichen Anforderungen genügen? | Liefern neue Projekte voraussichtlich Lösungen, die den geschäftlichen Anforderungen genügen? | ||
Werden neue Projekte voraussichtlich im vorgesehenen Zeit- und Kostenrahmen abgeschlossen? | 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 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? | Können Änderungen an IT-Systemen durchgeführt werden ohne die Geschäftsprozesse zu behindern? | ||
Betrieb und Unterstützung | Betrieb und Unterstützung | ||
Werden IT-Dienstleistungen entsprechend der geschäftlichen Prioritäten ausgeführt? | Werden IT-Dienstleistungen entsprechend der geschäftlichen Prioritäten ausgeführt? | ||
Sind die Kosten optimiert? | Sind die Kosten optimiert? | ||
Können die Mitarbeiter mit den IT-Systemen effektiv und sicher umgehen? | Können die Mitarbeiter mit den IT-Systemen effektiv und sicher umgehen? | ||
Ist eine angemessene Vertraulichkeit, Integrität und Verfügbarkeit gewährleistet? | Ist eine angemessene Vertraulichkeit, Integrität und Verfügbarkeit gewährleistet? | ||
Überwachung | Überwachung | ||
Kann die IT-Performance gemessen werden? | Kann die IT-Performance gemessen werden? | ||
Können IT-Probleme rechtzeitig erkannt werden? | Können IT-Probleme rechtzeitig erkannt werden? | ||
Risikokommunikation und -berichterstattung | Risikokommunikation und -berichterstattung | ||
Ständige Kommunikation innerhalb und außerhalb eines IT-Projektes | Ständige Kommunikation innerhalb und außerhalb eines IT-Projektes | ||
vielleicht wichtigster Punkt für erfolgreiches Risikomanagement | vielleicht wichtigster Punkt für erfolgreiches Risikomanagement | ||
| Zeile 492: | Zeile 492: | ||
Ist die Risikoanalyse aktuell? | Ist die Risikoanalyse aktuell? | ||
Welche Risiken sind hinzugekommen, welche evtl. aufgelöst worden? | Welche Risiken sind hinzugekommen, welche evtl. aufgelöst worden? | ||
Ist ein Trend abzusehen? | Ist ein Trend abzusehen? | ||
Bewertung der getroffenen Maßnahmen zur Risikobewältigung | Bewertung der getroffenen Maßnahmen zur Risikobewältigung | ||
Erfolg wird durch Beeinflussung der ergriffenen Maßnahmen messbar | Erfolg wird durch Beeinflussung der ergriffenen Maßnahmen messbar | ||
Überwachung von Maßnahmen | Überwachung von Maßnahmen | ||
Fragen | Fragen | ||
Wer Überwacht die Maßnahmen? | Wer Überwacht die Maßnahmen? | ||
Wer setzt diese eigentlich um? | Wer setzt diese eigentlich um? | ||
RASCI Methode | RASCI Methode | ||
Überwachung befasst sich zum größten Teil mit folgenden Fragen | Überwachung befasst sich zum größten Teil mit folgenden Fragen | ||
Responsible (R) | Responsible (R) | ||
| Zeile 510: | Zeile 510: | ||
Wer hilft bei der Umsetzung („Experte“)? | Wer hilft bei der Umsetzung („Experte“)? | ||
Informed (I) | Informed (I) | ||
Wer muss benachrichtigt werden? | Wer muss benachrichtigt werden? | ||
Bewertung | Bewertung | ||
Risikomanagement sollte nicht als lästige Pflicht angesehen werden | Risikomanagement sollte nicht als lästige Pflicht angesehen werden | ||
sondern als eine Chance | sondern als eine Chance | ||
IT-Prozesse optimieren | IT-Prozesse optimieren | ||
Risikoverständnis und Sicherheitsniveau im Unternehmen verbessern | Risikoverständnis und Sicherheitsniveau im Unternehmen verbessern | ||
Wirtschaftlicher Nutzen des Risikomanagement | Wirtschaftlicher Nutzen des Risikomanagement | ||
Je nach der Größe und Bedeutung eines Projektes | Je nach der Größe und Bedeutung eines Projektes | ||
kann das Risikomanagement in seinem Umfang unterschiedlich ausgelegt werden. | kann das Risikomanagement in seinem Umfang unterschiedlich ausgelegt werden. | ||
Bei kleineren Projekten | Bei kleineren Projekten | ||
erscheint es unter Umständen weniger sinnvoll, aufwendige Analysen wie z. B. die FMEA durchzuführen | 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 | Hier kann mit einfachen Mitteln bereits ein adäquates Risikomanagement betreiben werden | ||
Brainstorming | Brainstorming | ||
guter Dokumentation | guter Dokumentation | ||
Kommunikation der Risiken | Kommunikation der Risiken | ||
Risiken können nicht immer vollständig eliminiert werden | Risiken können nicht immer vollständig eliminiert werden | ||
| Zeile 531: | Zeile 531: | ||
Risikoanalyse (risk assessment) | Risikoanalyse (risk assessment) | ||
Risikobewertung anhand Wahrscheinlichkeiten | Risikobewertung anhand Wahrscheinlichkeiten | ||
Eintreten verschiedener Bedrohungen | Eintreten verschiedener Bedrohungen | ||
potentieller Schadenshöhe | potentieller Schadenshöhe | ||
Bewertung der Eintrittswahrscheinlichkeit | Bewertung der Eintrittswahrscheinlichkeit | ||
| Zeile 586: | Zeile 586: | ||
Entwicklungsprozess | Entwicklungsprozess | ||
Dezidierte Methoden bislang kaum entwickelt | Dezidierte Methoden bislang kaum entwickelt | ||
allgemeine methodische in der Regel | allgemeine methodische in der Regel | ||
top-down Vorgehensweise aus Software-Engineering | top-down Vorgehensweise aus Software-Engineering | ||
Schwierig, da Angreifer viele Möglichkeiten hat | Schwierig, da Angreifer viele Möglichkeiten hat | ||
=== Allgemeine Prinzipien === | === Allgemeine Prinzipien === | ||
1975 Saltzer und Schröder | 1975 Saltzer und Schröder | ||
Heute noch gültig | |||
=== Allgemeine Konstruktionsprinzipien === | === Allgemeine Konstruktionsprinzipien === | ||
Erlaubnis-Prinzip | Erlaubnis-Prinzip | ||
| Zeile 616: | Zeile 616: | ||
Rollenbasierte Rechte | Rollenbasierte Rechte | ||
Akzeptanz (economy of mechanism) | Akzeptanz (economy of mechanism) | ||
=== Benutzerakzeptanz | === Benutzerakzeptanz === | ||
Sicherheitsmechanismen müssen einfach zu nutzen sein | Sicherheitsmechanismen müssen einfach zu nutzen sein | ||
routinemäßig und automatisch angewendet werden | routinemäßig und automatisch angewendet werden | ||
=== Offener Entwurf (open design) === | === Offener Entwurf (open design) === | ||
| Zeile 628: | Zeile 628: | ||
Keep it simple, stupid. | Keep it simple, stupid. | ||
„Halte es einfach, Dummkopf!“; sinngemäß: Mach's so einfach wie möglich | „Halte es einfach, Dummkopf!“; sinngemäß: Mach's so einfach wie möglich | ||
Keep it simple [and] stupid | Keep it simple [and] stupid | ||
„Halte es einfach und [dumm=] beschränkt“ | „Halte es einfach und [dumm=] beschränkt“ | ||
sinngemäß: „Mit einfachsten Mitteln verständlich und bewältigbar.“ | sinngemäß: „Mit einfachsten Mitteln verständlich und bewältigbar.“ | ||
| Zeile 634: | Zeile 634: | ||
„Gestalte es kurz und einfach“ | „Gestalte es kurz und einfach“ | ||
aus dem Bereich des Marketing | aus dem Bereich des Marketing | ||
Keep it simple and smart | Keep it simple and smart | ||
„Mach es einfach und schlau“ | „Mach es einfach und schlau“ | ||
Keep it simple and straightforward | Keep it simple and straightforward | ||
„Gestalte es einfach und überschaubar“ | „Gestalte es einfach und überschaubar“ | ||
Keep it safe and sound | Keep it safe and sound | ||
„Halte es sicher und stimmig“ | „Halte es sicher und stimmig“ | ||
Keep it sweet and simple | Keep it sweet and simple | ||
„Gestalte es gefällig und einfach“ | „Gestalte es gefällig und einfach“ | ||
KISS-Prinzip | KISS-Prinzip | ||
| Zeile 656: | Zeile 656: | ||
entwerfe Düsentriebwerk, dass | entwerfe Düsentriebwerk, dass | ||
mit wenigen einfachen Werkzeugen | mit wenigen einfachen Werkzeugen | ||
von einem durchschnittlichen Ingenieur | von einem durchschnittlichen Ingenieur | ||
im Felde unter Kampfbedingungen | im Felde unter Kampfbedingungen | ||
mit nur diesen Werkzeugen reparierbar ist | mit nur diesen Werkzeugen reparierbar ist | ||
„stupid" | „stupid" | ||
zielt auf die Beziehung zwischen der Art und Weise, wie Dinge zu Bruch gehen, und deren Ausgereiftheit bezüglich der Reparatur | 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 | Es soll ein möglichst einfacher und „beschränkter“ Ansatz sein | ||
| Zeile 665: | Zeile 665: | ||
Hintergründe | Hintergründe | ||
Verbreitet ist das KISS-Prinzip in | Verbreitet ist das KISS-Prinzip in | ||
den United States Air Force | den United States Air Force | ||
der Softwareentwicklung | der Softwareentwicklung | ||
Designprinzip | Designprinzip | ||
beschreibt es im Gegensatz zu einer Problemlösung in der Form einer Fehlerumgehung ("workaround") | 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 | die möglichst einfache, minimalistische und leicht verständliche Lösung eines Problems | ||
Beispiel ist die TCP/IP-Protokollfamilie | Beispiel ist die TCP/IP-Protokollfamilie | ||
| Zeile 674: | Zeile 674: | ||
obwohl sie für ein kleines Netzwerksystem entwickelt wurden | obwohl sie für ein kleines Netzwerksystem entwickelt wurden | ||
Forschungszentren der DARPA | Forschungszentren der DARPA | ||
KISS-Prinzip immer häufiger im allgemeinen Zusammenhang mit komplexen Planungsaufgaben | KISS-Prinzip immer häufiger im allgemeinen Zusammenhang mit komplexen Planungsaufgaben | ||
„Keep It Short and Simple“-Version an englischen Schulen und Universitäten | „Keep It Short and Simple“-Version an englischen Schulen und Universitäten | ||
| Zeile 682: | Zeile 682: | ||
=== Modellierung, Entwurf und Betrieb (I) === | === Modellierung, Entwurf und Betrieb (I) === | ||
Vergleich | Vergleich | ||
Soll-Zustand | Soll-Zustand | ||
beschreibt Schutzbedarf | beschreibt Schutzbedarf | ||
Ist-Zustand | Ist-Zustand | ||
beschreibt Bedrohungs- und Risikoanalyse | beschreibt Bedrohungs- und Risikoanalyse | ||
Ergebnis | Ergebnis | ||
Maßnahmen zur Abwehr der Bedrohungen | Maßnahmen zur Abwehr der Bedrohungen | ||
| Zeile 693: | Zeile 693: | ||
Aufwand | Aufwand | ||
=== Modellierung, Entwurf und Betrieb (II) === | === Modellierung, Entwurf und Betrieb (II) === | ||
Erfassung der erforderlichen Maßnahmen | Erfassung der erforderlichen Maßnahmen | ||
zur Erfüllung des Schutzbedarfs in Sicherheitsstrategie (security policy) | zur Erfüllung des Schutzbedarfs in Sicherheitsstrategie (security policy) | ||
informell oder präzise formalisiert | informell oder präzise formalisiert | ||
| Zeile 700: | Zeile 700: | ||
Kriterienkataloge definieren Funktionsklassen für Anwendungsszenarien | Kriterienkataloge definieren Funktionsklassen für Anwendungsszenarien | ||
europäische ITSEC | europäische ITSEC | ||
internationale Common Criteria | internationale Common Criteria | ||
Anwender sollte klären | Anwender sollte klären | ||
ob seine Sicherheitsanforderungen bereits von einer dieser Klassen abgedeckt wird | ob seine Sicherheitsanforderungen bereits von einer dieser Klassen abgedeckt wird | ||
welche Kombination von Grundfunktionen er braucht | welche Kombination von Grundfunktionen er braucht | ||
| Zeile 753: | Zeile 753: | ||
=== Sicherheitsgrundfunktionen (III) === | === Sicherheitsgrundfunktionen (III) === | ||
Baukasten | Baukasten | ||
Rechteverwaltung | |||
Basis zur Abwehr von Bedrohung der Integrität und Vertraulichkeit | Basis zur Abwehr von Bedrohung der Integrität und Vertraulichkeit | ||
Sicherheitsanforderungen legen Rechte für zu schützende Objekte fest | Sicherheitsanforderungen legen Rechte für zu schützende Objekte fest | ||
| Zeile 824: | Zeile 824: | ||
BSI-Standard 100-3 | BSI-Standard 100-3 | ||
Ergänzende Sicherheitsanalyse | Ergänzende Sicherheitsanalyse | ||
Eine „Ergänzende Sicherheitsanalyse“ | Eine „Ergänzende Sicherheitsanalyse“ | ||
ist durchzuführen, wenn: | ist durchzuführen, wenn: | ||
hoher oder sehr hoher Schutzbedarf | hoher oder sehr hoher Schutzbedarf | ||
zusätzlicher Analysebedarf | zusätzlicher Analysebedarf | ||
für bestimmte Aspekte kein geeigneter Grundschutz-Katalog | für bestimmte Aspekte kein geeigneter Grundschutz-Katalog | ||
Risikoanalyse | Risikoanalyse | ||
Zweistufiges BSI-Modell | Zweistufiges BSI-Modell | ||
(1) Für | (1) Für | ||
normalern Schutzbedarf | normalern Schutzbedarf | ||
übliche Einsatzszenarien | übliche Einsatzszenarien | ||
existierende Bausteine | existierende Bausteine | ||
qualitative Methode zur Risikoanalyse und -bewertung in der IT-Grundschutz-Vorgehensweise enthalten | qualitative Methode zur Risikoanalyse und -bewertung in der IT-Grundschutz-Vorgehensweise enthalten | ||
beim Einsatz ähnlicher IT-Umgebungen und vergleichbarer Umfeldbedingungen meistens vergleichbare Bedrohungen | beim Einsatz ähnlicher IT-Umgebungen und vergleichbarer Umfeldbedingungen meistens vergleichbare Bedrohungen | ||
(2) Für | (2) Für | ||
höheren Schutzbedarf | höheren Schutzbedarf | ||
unübliche Einsatzszenarien | unübliche Einsatzszenarien | ||
| Zeile 846: | Zeile 846: | ||
Vor einer Risikoanalyse, sollten folgende Vorarbeiten abgeschlossen sein | Vor einer Risikoanalyse, sollten folgende Vorarbeiten abgeschlossen sein | ||
Initiierung des Informationssicherheitsprozess | Initiierung des Informationssicherheitsprozess | ||
Definition des Geltungsbereiches für die Sicherheitskonzeption | Definition des Geltungsbereiches für die Sicherheitskonzeption | ||
Strukturanalyse | Strukturanalyse | ||
Schutzbedarfsfeststellung | Schutzbedarfsfeststellung | ||
Modellierung | Modellierung | ||
Basis-Sicherheitscheck | Basis-Sicherheitscheck | ||
ergänzende Sicherheitsanalyse | ergänzende Sicherheitsanalyse | ||
Erstellung der Gefährdungsübersicht | Erstellung der Gefährdungsübersicht | ||
| Zeile 857: | Zeile 857: | ||
Ausgangspunkt | Ausgangspunkt | ||
relevante Gefährdungen au den IT-Grundschutz-Katalogen | relevante Gefährdungen au den IT-Grundschutz-Katalogen | ||
für betrachtete Zielobjekte | für betrachtete Zielobjekte | ||
Bedrohungen, Schwachstellen und Risiken werden nicht separat untersucht | Bedrohungen, Schwachstellen und Risiken werden nicht separat untersucht | ||
Ziel | Ziel | ||
Übersicht der Gefährdungen, die auf die betrachteten Zielobjekte wirken | Übersicht der Gefährdungen, die auf die betrachteten Zielobjekte wirken | ||
Vorgehen | Vorgehen | ||
Reduzierung des Informationsverbundes auf die betrachteten Komponenten | Reduzierung des Informationsverbundes auf die betrachteten Komponenten | ||
Zielobjekte streichen, für die kein Bedarf einer Risikoanalyse besteht | Zielobjekte streichen, für die kein Bedarf einer Risikoanalyse besteht | ||
Bausteine streichen, für die kein Zielobjekt mehr übrig ist | Bausteine streichen, für die kein Zielobjekt mehr übrig ist | ||
| Zeile 869: | Zeile 869: | ||
Vorgehen | Vorgehen | ||
Bausteine der IT-Grundschutz-Katalogen verweisen auf Gefährdungen | Bausteine der IT-Grundschutz-Katalogen verweisen auf Gefährdungen | ||
Je Zielobjekt werden Nummer und Titel dieser Gefährdungen aus den Bausteinen zusammengetragen | Je Zielobjekt werden Nummer und Titel dieser Gefährdungen aus den Bausteinen zusammengetragen | ||
und dem jeweiligen Zielobjekt zugeordnet | und dem jeweiligen Zielobjekt zugeordnet | ||
Gefährdungen aus den Bausteinen der Schichten 1 separat behandeln | Gefährdungen aus den Bausteinen der Schichten 1 separat behandeln | ||
| Zeile 875: | Zeile 875: | ||
Ergebnis | Ergebnis | ||
Tabelle, die jedem Zielobjekt eine Liste mit relevanten Gefährdungen zuordnet | Tabelle, die jedem Zielobjekt eine Liste mit relevanten Gefährdungen zuordnet | ||
doppelte oder mehrfach genannten Gefährdungen entfernen | doppelte oder mehrfach genannten Gefährdungen entfernen | ||
Gefährdungen pro Zielobjekt thematisch sortieren | Gefährdungen pro Zielobjekt thematisch sortieren | ||
Einige Gefährdungen der Grundschutz-Kataloge | Einige Gefährdungen der Grundschutz-Kataloge | ||
behandeln ähnliche Sicherheitsprobleme oder | behandeln ähnliche Sicherheitsprobleme oder | ||
unterschiedliche Ausprägungen der gleichen Bedrohung | unterschiedliche Ausprägungen der gleichen Bedrohung | ||
Beispiel | Beispiel | ||
| Zeile 888: | Zeile 888: | ||
Grundwerte | Grundwerte | ||
Vertraulichkeit | Vertraulichkeit | ||
Integrität | Integrität | ||
Verfügbarkeit | Verfügbarkeit | ||
Für übergeordnetes Zielobjekt | Für übergeordnetes Zielobjekt | ||
gesamter Informationsverbund | gesamter Informationsverbund | ||
kann Zuordnung entfallen | kann Zuordnung entfallen | ||
Ergebnis | Ergebnis | ||
Gefährdungsübersicht für | Gefährdungsübersicht für | ||
die betrachteten Zielobjekte | die betrachteten Zielobjekte | ||
dient als Ausgangspunkt | dient als Ausgangspunkt | ||
für die nachfolgende Ermittlung | für die nachfolgende Ermittlung | ||
zusätzlicher Gefährdungen. | zusätzlicher Gefährdungen. | ||
Ermittlung zusätzlicher Gefährdungen | Ermittlung zusätzlicher Gefährdungen | ||
| Zeile 942: | Zeile 942: | ||
=== Quellen und weitere Informationen === | === Quellen und weitere Informationen === | ||
BITCOM: IT-Risiko- und Chancenmanagement im Unternehmen | |||
=== Prozesse im Risikomanagement === | |||
Leitbild für das IT Management | 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. | 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. | 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. | 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. | 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. | 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. | 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 === | |||
[[Kategorie:Tmp]] | [[Kategorie:Tmp]] | ||
Version vom 8. Juni 2023, 22:21 Uhr
topic - Kurzbeschreibung
Beschreibung
Anhang
Siehe auch
Sicherheit
Dokumentation
RFC
Man-Pages
Info-Pages
Links
Einzelnachweise
Projekt
Weblinks
TMP
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.