Zum Inhalt springen

Risikoanalyse

Die Risikoanalyse bildet das Fundament eines jeden Informationssicherheitsmanagementsystems (ISMS). Sie ist der strukturierte Prozess zur systematischen Identifikation, Bewertung und Behandlung von Risiken im Bereich der Informationssicherheit. Ohne eine fundierte Risikoanalyse können Organisationen ihre kritischen Informationswerte nicht angemessen schützen.

Navigation: ISMS → Risikobewertung

risk-1

  • Transparenz schaffen: Potenzielle Gefahren für Informationswerte sichtbar machen
  • Priorisierung ermöglichen: Ressourcen gezielt auf die größten Risiken konzentrieren
  • Compliance sicherstellen: Regulatorische Anforderungen (ISO 27001, BSI IT-Grundschutz) erfüllen
  • Proaktivität fördern: Von reaktiver zu präventiver Sicherheitsstrategie wechseln

Gemäß ISO 27001:2022 ist die Risikoanalyse nicht optional, sondern zentraler Bestandteil des ISMS. Sie dient als Grundlage für:

  • Die Auswahl angemessener Sicherheitsmaßnahmen (Controls aus ISO 27001 Anhang A)
  • Die Erstellung des Statement of Applicability (SoA)
  • Die kontinuierliche Verbesserung der Informationssicherheit

Praxis-Tipp: Eine Risikoanalyse ist besonders dann erforderlich, wenn Assets einen hohen oder sehr hohen Schutzbedarf in Bezug auf Vertraulichkeit, Integrität oder Verfügbarkeit aufweisen.

Methodische Ansätze: ISO 27001 vs. BSI IT-Grundschutz

Abschnitt betitelt „Methodische Ansätze: ISO 27001 vs. BSI IT-Grundschutz“

Charakteristika:

  • Flexibel und individuell: Organisation definiert eigene Methodik
  • Risikobasiert: Kontinuierliche Bewertung und Anpassung
  • International anerkannt: Weltweiter Standard
  • Anspruchsvoll: Erfordert methodische Reife

Geeignet für:

  • International tätige Unternehmen
  • Organisationen mit spezifischen Anforderungen
  • Branchen mit hohen regulatorischen Anforderungen (Finanzwesen, Gesundheitswesen)

Charakteristika:

  • Strukturiert und umfassend: Vordefinierte Module und Gefährdungskataloge
  • Schichtenmodell: Mehrere Sicherheitsebenen reduzieren Abhängigkeit von präziser Bewertung
  • Praxisorientiert: Basiert auf bewährten Standards
  • Geführt: Klare Vorgaben und Leitlinien

Geeignet für:

  • Deutsche Behörden und öffentliche Verwaltung
  • Unternehmen mit komplexen IT-Landschaften
  • Organisationen mit weniger Erfahrung in Risikobewertung

Best Practice: Viele Organisationen kombinieren beide Ansätze - nutzen die Struktur des IT-Grundschutzes mit der Flexibilität von ISO 27001.

Ziel: Vollständige Erfassung aller schützenswerten Informationswerte

Vorgehen:

  • Inventarisierung: Hardware, Software, Daten, Prozesse und Personen erfassen
  • Gruppierung: Ähnliche Assets zu Target Object Groups (TOG) zusammenfassen
  • Klassifizierung: Schutzbedarf (normal, hoch, sehr hoch) festlegen

Praxis-Beispiel: Statt 500 einzelne Server zu bewerten, werden diese nach Betriebssystem, Funktion oder Kritikalität gruppiert (z.B. “Alle Oracle Linux Server - Produktion”).

risk-3

Ziel: Bedrohungen und Schwachstellen systematisch erfassen

Komponenten:

  • Bedrohungen (Threats): Was könnte schief gehen?
  • Schwachstellen (Vulnerabilities): Wo sind wir verwundbar?
  • Schadensszenarien: Was wären die Folgen?

Kataloge und Quellen:

  • BSI IT-Grundschutz-Kompendium (Gefährdungskatalog)
  • CVE-Datenbanken für technische Schwachstellen
  • Branchenspezifische Threat Intelligence

risk-4

Zentrale Konzepte:

Definition: Das Risiko ohne jegliche Schutzmaßnahmen, also die “nackte” Bedrohungslage.

Beispiel: Unverschlüsselte Datenübertragung bei Server-Migration

  • Eintrittswahrscheinlichkeit: Hoch
  • Schadenspotenzial: 175.000€
  • Inhärentes Risiko: Hoch

Definition: Das akzeptable Risikoniveau nach Umsetzung von Maßnahmen - im Einklang mit der Risikobereitschaft der Organisation.

Festlegung basiert auf:

  • Regulatorischen Anforderungen
  • Geschäftszielen
  • Stakeholder-Erwartungen
  • Kosten-Nutzen-Abwägung

risk-5

Vier Strategien:

  • Häufigste Strategie: Controls implementieren
  • Beispiel: Verschlüsselung, Zugriffskontrollen, Monitoring
  • Umsetzung: Controls aus ISO 27001 Anhang A auswählen
  • Aktivität einstellen: Risikoquelle eliminieren
  • Beispiel: Verzicht auf Cloud-Speicherung kritischer Daten
  • Wann sinnvoll: Risiko übersteigt jeden möglichen Nutzen
  • Verantwortung verlagern: Versicherung oder Outsourcing
  • Beispiel: Cyber-Versicherung, Managed Security Services
  • Wichtig: Risiko bleibt bestehen, nur Verantwortung wird geteilt
  • Bewusste Entscheidung: Risiko tolerieren
  • Voraussetzung: Innerhalb der Risikotoleranz
  • Dokumentation: Formale Akzeptanz durch Management erforderlich

risk-6

Navigation: ISMS → Risikobewertung → Risiko öffnen

Die Maßnahme, mit der Sie ein Risiko mindern, hängen Sie direkt an das Risiko. Der Weg dorthin ist in der Oberfläche leicht zu übersehen:

  1. Im Risiko zuerst die Risikobewertung ausfüllen. Ohne bewertetes inhärentes Risiko lässt sich keine Behandlung anlegen.
  2. Unter Risikobehandlung eine Behandlung erstellen, die Strategie wählen (etwa Akzeptanz) und das Zielrisiko setzen.
  3. Speichern.
  4. In der Tabelle der Behandlungen die waagerechte Bildlaufleiste am unteren Rand nach rechts ziehen. Die Spalte mit dem Drei-Punkte-Menü steht ganz rechts und ist im Standardzuschnitt nicht sichtbar.
  5. Drei-Punkte-Menü → Control hinzufügen, die Control aus dem Katalog wählen, etwa 5.18 Zugangsrechte, und zuweisen.

Diese Zuweisung wirkt an zwei Stellen. Das Risiko hängt an einer Zielobjektgruppe. Weisen Sie dem Risiko eine Control zu, ist sie damit auch der Zielobjektgruppe zugeordnet und erscheint in der Modellierung im Reiter Kontrollen. Ein zweites Anlegen dort entfällt.

Controls lassen sich auf zwei Wegen zuordnen, und beide landen im selben Datenbestand:

WegAusgangspunktWann er passt
Über die Risikobewertungein konkretes RisikoDie Control ist die Antwort auf ein bewertetes Risiko. Die Zuordnung zur Zielobjektgruppe entsteht nebenbei.
Über die Modellierungeine ZielobjektgruppeDie Control gehört zur Grundabsicherung der Gruppe, unabhängig von einem einzelnen Risiko.

Welchen Weg Sie wählen, ist eine Frage der Blickrichtung, nicht des Ergebnisses. Risikogetrieben arbeiten Sie von der Bedrohung zur Maßnahme, in der Modellierung vom Objekt zur Maßnahme.

Der Umsetzungsstatus gehört an die Control, nicht an das Risiko. Öffnen Sie die Control, Bearbeiten, Umsetzungsstatus auf Umgesetzt, Speichern. Erst dieser Schritt bewegt die Gap-Analyse.

Definition: Das verbleibende Risiko nach Umsetzung aller Maßnahmen.

Prozess:

  1. Wirksamkeit der implementierten Controls bewerten
  2. Restrisiko neu berechnen
  3. Mit Zielrisiko vergleichen
  4. Bei Bedarf weitere Maßnahmen ergreifen oder formal akzeptieren

Praxis-Tipp: Restrisiko ist nie Null: Es geht um ein akzeptables Niveau, nicht um Perfektion.

risk-7

  1. Risikoidentifikation (Gelb)

    • Bedrohungen zuweisen
    • Schwachstellen dokumentieren
    • Schadensszenarien definieren
  2. Risikobewertung (Gelb)

    • Inhärentes Risiko festlegen
    • Zielrisiko definieren
    • Dokumentation ergänzen
  3. Risikobehandlung (Gelb)

    • Strategie wählen
    • Maßnahmen planen
    • Verantwortliche zuweisen
  4. Risikominderung (Gelb)

    • Controls implementieren
    • Maßnahmen umsetzen
    • Status überwachen
  5. Restrisiko (Grün = Abgeschlossen)

    • Restrisiko bewerten
    • Akzeptanz einholen
    • Dokumentation vervollständigen

Farbcodierung:

  • Grün: Schritt abgeschlossen
  • Gelb: In Bearbeitung
  • Grau: Noch nicht begonnen

risk-8

Globale Rolle: ISMS_RISKS_ANALYSIS_ACCESS

  • Grundvoraussetzung für Zugriff auf Risikoanalyse

Granulare Berechtigungen:

  • Risks - Read/Create/Edit/Delete
  • Threats - Assign/Edit/Delete
  • Measures - Create/Edit/Delete
  • Controls - Assign/Edit/Delete
  • Vulnerabilities - Create/Edit/Delete

Asset: Jeder Wert für die Organisation (Hardware, Software, Daten, Prozesse, Personal)

Control: Sicherheitsmaßnahme zur Risikominderung (technisch, organisatorisch, physisch)

CVE: Common Vulnerabilities and Exposures - Datenbank bekannter Schwachstellen

GRC: Governance, Risk Management, and Compliance

Inhärentes Risiko: Risiko ohne Berücksichtigung von Kontrollen

Restrisiko: Verbleibendes Risiko nach Umsetzung von Maßnahmen

SoA: Statement of Applicability - Anwendbarkeitserklärung für ISO 27001

TOG: Target Object Group - Gruppierung ähnlicher Assets im ISMS

Zielrisiko: Angestrebtes/akzeptables Risikoniveau