|
|
| (59 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
| |
| | |
| ; Standish Group im Jahre 2009 Umfrage
| |
| * Nur ein Drittel aller IT-Projekte werden im geplanten Zeit- und Budgetrahmen beendet
| |
| * fast die Hälfte diese Vorgaben nicht erfüllen
| |
| * der Rest wird abgebrochen
| |
| | |
| ; IT-Projekte
| |
| | |
| === Risikobegriff ===
| |
| * „Risiko“ wird unterschiedlich beschrieben
| |
| * je nach Betrachtungsweise
| |
| | |
| ; Entscheidungsorientiert
| |
| * Abweichung/Varianz von Zielgrößen und Erwartungsgrößen
| |
| * Abweichung kann positiv oder negativ sein
| |
| * Je höher die Standardabweichung, umso größer das Risiko
| |
| | |
| ; Ausfallorientiert
| |
| ** negative Abweichung des realisierten Ergebnisses vom Erwartungswert
| |
| ** Risiko = Eintrittswahrscheinlichkeit x Auswirkungen
| |
| ** Einfache Gleichung für das Risiko
| |
| | |
| ; Je geringer die Eintrittswahrscheinlichkeit, umso seltener Auswirkungen sind ungünstige Effekte, sollte das Risiko eintreten
| |
| * die Gefahr
| |
| * die Chance
| |
| | |
| ; Risiken sind Teil des Geschäftes
| |
| * Einige der Risiken spielen dabei nie eine Rolle, andere können bedrohlich werden.
| |
| * Risikomanagement hilft, Risiken zu erkennen, zu analysieren, zu bewerten und mit den entsprechenden Techniken abzuschwächen.
| |
| | |
| === BSI-Standard 200-3 ===
| |
| * Risikoanalyse
| |
| | |
| === Methoden ===
| |
| * BSI-Standard 200-3
| |
| * Risikoanalyse auf der Basis von IT-Grundschutz
| |
| * klassische Risikoanalyse
| |
| * ISO 27001, 27005, 31000, 31010
| |
| * Penetrationstest
| |
| * Differenz-Sicherheitsanalyse
| |
| | |
| === Risikomanagement === | | === 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 === |
| Zeile 152: |
Zeile 84: |
|
| |
|
| === 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. |
|
| |
|
| ; Risikomanagementplanung | | ; Risikomanagementplanung |
| Zeile 208: |
Zeile 140: |
| * 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. |
|
| |
|
| === Methoden der Risikoidentifikation ===
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Option !! Beschreibung
| |
| |-
| |
| | [[Brainstorming]] ||
| |
| |-
| |
| | [[Delphi-Methode]] ||
| |
| |-
| |
| | [[Post-Mortem-Analyse]] ||
| |
| |-
| |
| | [[Fehlermöglichkeits- und Einflussanalyse]] || FMEA
| |
| |-
| |
| | [[Szenariotechnik]] || Monte-Carlo-Simulation
| |
| |-
| |
| | [[SWOT-Analyse]] ||
| |
| |-
| |
| | [[Bedrohungsbaum]] || Entscheidungsbaum, Fehleranalyse
| |
| |}
| |
|
| |
| === Aufbereitung identifizierter Risiken ===
| |
| * Identifizierte Risiken müssen aufbereitet werden
| |
| * damit diese den anderen Prozesse des Risikomanagement zur Verfügung stehen
| |
| * Hierfür eignet sich die Erstellung folgender Komponenten
| |
|
| |
| ==== Risikoregister ====
| |
| * Ursprungswerte aus der Risikoidentifikation
| |
| * später gefüllt mit den Ergebnissen der anderen Prozesse
| |
| * Liste identifizierter Risiken und mögliche Folgen
| |
| * Liste der möglichen Bewältigungsmaßnahmen, sofern bereits identifiziert
| |
| * Liste der Grundursachen identifizierter Risiken
| |
| * Liste der Risikokategorien
| |
|
| |
| === Qualitative Risikoanalyse ===
| |
| ; Schnelle und kosteneffektive Vorgehensweise
| |
| * Methoden zur Priorisierung der identifizierten Risiken
| |
| * Grundstein für die quantitative Risikoanalyse
| |
| * trägt zur Risikobewältigungsplanung bei
| |
| * bezieht Informationen aus der Risikomanagementplanung und der Risikoidentifikation
| |
| * Konzentration auf Risiken mit hoher Priorität
| |
|
| |
| ; Prioritäten identifizierter Risiken bewerten
| |
| * Anhand der Eintrittswahrscheinlichkeit
| |
| * daraus resultierenden Auswirkungen auf die gesteckten Ziele
| |
| * Zeitrahmen
| |
| * Risikotoleranz
| |
| * Budgetkosten
| |
|
| |
| ; Umfang und Qualität
| |
| * Bedeutung eines Risikos besser zu verstehen
| |
| * qualitative Bewertung der verfügbaren Informationen
| |
| * Risikobezogene Maßnahmen sind oftmals sehr zeitkritisch und können somit die Bedeutung oder Auswirkung eines Risikos stark erhöhen.
| |
|
| |
| ; Laufender Prozess
| |
|
| |
| ; Die qualitative Risikoanalyse sollte im Laufe des Projektes ständig wiederholt werden, da sich Änderungen an den Projektrisiken ergeben können.
| |
|
| |
| ; Aufbauend auf qualitativer Risikoanalyse
| |
| * durchgeführte Priorisierung der Risiken
| |
| * einige Risikomanager führen sie gerne direkt nach der Risikoidentifikation durch
| |
| * Auswirkungen werden analysiert
| |
| * numerische Einstufung der Risiken
| |
| * Somit wird gleichzeitig ein erster Ansatz für die Entscheidungsfindung erstellt
| |
|
| |
| === Risikobewältigungsplanung ===
| |
| ; Vorgehensweisen und Verfahren
| |
| * Erreichen von Projektzielen
| |
| * Gefahren vermeiden
| |
| * Aufbauend auf Risikoanalyse
| |
| * qualitativ und /oder quantitativ
| |
| * Risikoverantwortliche bestimmen
| |
| * welche Maßnahmen zur Risikobewältigung übernehmen
| |
| * Orientiert sich an ermittelten priorisierten Risiken
| |
| * Budget, Terminplan, Einsatzmittel und Maßnahmen
| |
| * Vor der Bewältigung müssen Bedeutung und Umfang eines Risikos klar sein
| |
|
| |
| ; Folgende Punkte muss jeder Beteiligte verinnerlicht haben
| |
| * kosteneffektiv
| |
| * termingerecht
| |
| * realistisch
| |
|
| |
| === Vorgaben an das Risikomanagement ===
| |
| * von betriebsinternen Projektmitgliedern
| |
| * von Vertragspartnern, Behörden, Gesetzgeber
| |
| * Vertragspartner (meist zeitliche, aber auch Qualitätsvorgaben)
| |
| * Gesetzgeber (Auflagen bzgl. des Datenschutzes und der Aufbewahrung von z.B E-Mails)
| |
| * Behörden (häufig sind dies Vorgaben bzgl. des Budgets, da bei Verzögerungen oder Mehrkosten diese erst genehmigt werden müssen)
| |
| * Prozesse im Risikomanagement
| |
| === Risikobewältigungsplanung ===
| |
| * Wie gehen wir Risiko um?
| |
| * Vermeiden/Minimieren
| |
| * z.B durch Verbesserung der Kommunikation innerhalb des Projektteams und den Vertragspartnern
| |
| * Vermindern
| |
| * z.B durch Änderungen an der Organisation um Projektziele oder Meilensteine nicht zu gefährden
| |
| * Abwälzen/Übertragen
| |
| * z.B an den Auftraggeber oder Lieferanten durch entsprechende Vertragsklauseln etc.
| |
| * Selbstübernehmen/Akzeptieren
| |
| * meist nur bei eher unbedeutenden Risiken/Bildung von Reserven
| |
| === Risikoinventur ===
| |
| ; Risikoinventur erfasst Schäden durch Risiken
| |
| * Hierbei spielen Eintrittswahrscheinlichkeit sowie Ursachen eine Rolle
| |
| * Grundlagen zur strukturierten Darstellung
| |
| * Vollständigkeit
| |
| * alle Risiken
| |
| * die erfolgreichen Abschluss eines Projektes gefährden können
| |
| * Abhängigkeiten (Interdependenzen)
| |
| * Viele Risiken verstärken sich extrem bei ihrem Eintritt
| |
|
| |
| ; Beispiel
| |
| * Es kommt in einem Serverraum zu einem Brand, durch ein defektes Netzteil
| |
| * Der Schaden steigt erheblich
| |
| * überfällige Wartung des Brandbekämpfungssystems
| |
| * langanhaltende Betriebsunterbrechung
| |
| * Hardware muss getauscht und ein Backup eingespielt werden
| |
| * Eine Gefährdung für die gesamte Produktion ist die Folge
| |
| * Der Schaden entsteht nicht durch Verlust der Hardware oder deren (Brandschutzversicherung)
| |
| * eigentlicher kaum messbare Schaden: Betriebsunterbrechung (keine Versicherung)
| |
| * Prozesse im Risikomanagement
| |
|
| |
| ; Risikocontrolling: Risikoinventur
| |
|
| |
| ; Quantifizierung
| |
| * Schadensausmaß richtet sich nach Eintrittswahrscheinlichkeit (starker Bezug)
| |
|
| |
| ; Rechtzeitigkeit
| |
| * Risiken müssen so früh wie nur irgendwie möglich erkannt werden
| |
| * damit noch genügend Reaktionszeit bleibt
| |
| * Schaden möglichst gering zu halten
| |
|
| |
| ; Kommunikation
| |
| * Während der Bewältigungsplanung sind Akzeptanzbereiche zu bilden
| |
| * durch die die jeweiligen Risikoträger bei Eintritt informiert werden
| |
|
| |
| ; Verantwortung
| |
| * Risiken müssen entsprechend ihrer Art, den jeweiligen Zuständigkeitsbereichen zugeordnet sein
| |
| * nach Eintritt des Risikos muss der Zuständige dann die geplanten Maßnahmen ergreifen
| |
|
| |
| === Bewertung und Messung von Risiken ===
| |
| ; Zwei Phasen
| |
| * Bruttobewertung
| |
| * grundsätzlichen Bedrohungspotenziale werden betrachtet
| |
| * wo liegen Schwerpunkte der Risikosteuerung
| |
| * Nettobewertung
| |
| * Risiken bereits bestehenden Steuerungs- und Kontrollmaßnahmen gegenüberstellen
| |
| * Aktuelle Risikolage
| |
| * Wir ermittelt
| |
| * Eignung und Angemessenheit bestehender Maßnahmen feststellen
| |
| * 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
| |
|
| |
| ; 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
| |
|
| |
| ; 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 === | | === Schlussfolgerung === |
| * Auch bei einfachem Angreifermodell sehr hohes Risiko | | * Auch bei einfachem Angreifermodell sehr hohes Risiko |
| Zeile 582: |
Zeile 145: |
| * Zeitliche Entwicklung beachten | | * Zeitliche Entwicklung beachten |
|
| |
|
| === Konstruktion sicherer Systeme ===
| | == Leitbild für das IT-Management == |
| * 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 angewandt 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]]
| |
| | |
| === Modellierung ===
| |
| [[Modellierung]]
| |
| | |
| === Validierung / Evaluierung ===
| |
| ;Testen
| |
| * Methodisches Testen des implementierten Systems
| |
| * Verifizierung der sicherheitsrelevanten Funktionen
| |
| | |
| ; Testziele, -pläne, -verfahren festlegen, dokumentieren.
| |
| * Vollständigkeit der Tests
| |
| * Code Review
| |
| * Evaluierung durch Dritte
| |
| | |
| === Sicherheitsgrundfunktionen ===
| |
| [[Sicherheitsgrundfunktionen]]
| |
| | |
| === 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
| |
| | |
| === 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. | | * 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. |
| Zeile 784: |
Zeile 152: |
| * 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 ===
| |
| == Quellen und weitere Informationen ==
| |
| # BITCOM: IT-Risiko- und Chancenmanagement im Unternehmen
| |
|
| |
| [[Kategorie:Tmp]] | | [[Kategorie:Tmp]] |