Risikoanalyse nach BSI-Standard 200-3: Wann sie nötig ist und wie sie gesteuert wird

Problem in der Praxis

Es gibt zwei gegenläufige Fehlhaltungen. Die eine analysiert alles und erstickt im Aufwand - auch für unkritische, gut abgedeckte Objekte. Die andere analysiert nichts und übersieht, dass Objekte mit hohem oder sehr hohem Schutzbedarf, untypische Szenarien oder schlecht abbildbare Komponenten über die Standardabdeckung hinausreichen.

Hinzu kommt ein Anschlussproblem: Oft bleibt die Analyse eine einmalige Tabellenübung - Risiken ohne Eigentümer, Restrisiken nie formal gezeichnet, kein Nachweis für die gewählte Behandlung.

CISO-Einordnung

Der 200-3 setzt die Methodik-Vorarbeiten voraus - Strukturanalyse, Schutzbedarfsfeststellung, Modellierung und IT-Grundschutz-Check. Daraus ergibt sich die Liste der zu analysierenden Objekte.

Der Auslöser ist klar umrissen: Eine Risikoanalyse ist anzustoßen, wenn für ein Zielobjekt mindestens eine von drei Bedingungen gilt - hoher oder sehr hoher Schutzbedarf in einem der Grundwerte Vertraulichkeit, Integrität oder Verfügbarkeit; keine hinreichende Abbildbarkeit mit vorhandenen Bausteinen; oder ein vom IT-Grundschutz nicht vorgesehenes Einsatzszenario. So fließt knappe Kapazität dorthin, wo das Standardvorgehen nicht ausreicht.

Beachten Sie die Begriffsunschärfe: Im 200-3 umfasst "Risikoanalyse" Beurteilung und Behandlung, während "Risk Analysis" nach ISO 31000 und ISO/IEC 27005 nur ein Teilschritt ist.

Umsetzungsperspektive

Das Verfahren ist ein Vier-Schritt-Workflow mit Rückführung.

1 - Gefährdungsübersicht. Grundlage sind die elementaren Gefährdungen des Kompendiums - produktneutrale Kategorien, die reale Gefahren statt fehlender Maßnahmen benennen und meist schwerpunktmäßig einem Grundwert zugeordnet sind. Eigene Bedrohungskataloge erübrigen sich: Für hinreichend mit Bausteinen abbildbare Zielobjekte liefern die Bausteine die dort bereits ermittelten elementaren Gefährdungen als Ausgangspunkt; darüber hinaus wird auch bei diesen Zielobjekten die Liste der elementaren Gefährdungen herangezogen und geprüft, ob weitere elementare Gefährdungen für das Zielobjekt relevant sind. Für nicht abbildbare Zielobjekte wird die Liste der elementaren Gefährdungen herangezogen und je Zielobjekt geprüft, welche Gefährdungen relevant sind. Je Zielobjekt wird eingestuft, ob eine Gefährdung direkt, indirekt (durch eine allgemeinere abgedeckt) oder nicht relevant ist; szenariospezifische Zusatzgefährdungen kommen aus moderiertem Brainstorming der Fachbeteiligten hinzu.

2 - Risikoeinstufung. Das Risiko ergibt sich aus Eintrittshäufigkeit und Schadenshöhe; die Höhe schätzt die Institution, die Häufigkeit eher das Fachpersonal. Pragmatisch ist ein qualitatives Vorgehen mit wenigen Stufen. Eine Risikomatrix führt beide zu Kategorien von gering bis sehr hoch zusammen; ihre Belegung ist organisationsspezifisch, die vom BSI gezeigte Matrix nur ein Beispiel.

3 - Risikobehandlung. Für jedes nicht akzeptable Risiko wird eine von vier Optionen gewählt: Vermeidung (A), Reduktion bzw. Modifikation (B), Transfer oder Teilung etwa per Versicherung oder Auslagerung (C) oder Akzeptanz auf nachvollziehbarer Faktenlage (D); welche zulässig ist, hängt vom Risikoappetit ab. Die Anforderungen bei erhöhtem Schutzbedarf liefern Anhaltspunkte über den Stand der Technik hinaus - empfehlenswert, aber nicht automatisch verbindlich.

4 - Konsolidierung und Rückführung. Die Maßnahmen werden je Zielobjekt auf Eignung, widerspruchsfreies Zusammenwirken, Benutzerfreundlichkeit und Angemessenheit geprüft; ungeeignete oder zu teure werden ersetzt. Dann geht das Ergebnis über einen erneuten IT-Grundschutz-Check und die Umsetzung in den Sicherheitsprozess zurück.

Bewährt hat sich die zweistufige Bewertung - erst unter Annahme umgesetzter oder geplanter Basis- und Standard-Anforderungen, dann mit den Behandlungsmaßnahmen; der Vorher-Nachher-Vergleich macht die Wirksamkeit sichtbar.

Typische Fehler

1. Risikoanalysen werden flächendeckend statt fokussiert gefahren und binden so Kapazität.
2. Die scheinbare Präzision der Matrix wird überschätzt; aus groben Schätzungen werden harte Zahlen.
3. Akzeptanz (Option D) wird zum stillen Standard, weil Behandlung Aufwand bedeutet.
4. Restrisiken werden nicht formal gezeichnet und keinem Eigentümer zugeordnet.
5. Ergebnisse werden nicht ins Sicherheitskonzept zurückgeführt und nicht neu bewertet.

Risiken und Trade-offs

Qualitative Bewertung ist schnell, kann aber Risiken einebnen; quantitative Verfahren wirken präziser, erkaufen das mit Datenhunger und Scheingenauigkeit. Transfer verschiebt zudem nur den finanziellen Teil, nicht die operative Verantwortung und nicht Reputations- oder Rechtsfolgen.

Entscheidungspunkte

• Welche Schwellen lösen verbindlich eine Risikoanalyse aus, und wer stellt das fest?
• Welche Risikomatrix, Stufen und Akzeptanzkriterien gelten organisationsweit?
• Wer ist Risikoeigentümer, und auf welcher Ebene werden Restrisiken gezeichnet?
• In welchem Rhythmus werden Risiken neu bewertet?

Praktische Empfehlungen

1. Verankern Sie eine von der Leitung freigegebene Richtlinie zum Umgang mit Risiken: Pflichtfälle, Methodik, Akzeptanzkriterien, Verantwortliche und Aktualisierungsturnus.
2. Steuern Sie den Analyseumfang über Schutzbedarf und Abbildbarkeit, nicht Vollständigkeit.
3. Halten Sie die Bewertung qualitativ; mehr Stufen nur, wo sie Entscheidungen verändern.
4. Dokumentieren Sie je Risiko Eigentümer, Option und Begründung und legen Sie Restrisiken der Leitung vor.
5. Führen Sie jedes Ergebnis ins Sicherheitskonzept zurück und führen Sie ein Risikoverzeichnis fort.

Relevante Normreferenzen

• BSI-Standard 200-3 (Risikoanalyse auf der Basis von IT-Grundschutz): maßgebliche Fundstelle für das Vorgehen.
• BSI-Standard 200-2 (IT-Grundschutz-Methodik): liefert die vorgelagerten Schritte.
• ISO/IEC 27005 und ISO 31000: Referenzrahmen für das Risikomanagement (ISO-Ausgabenstand jeweils prüfen).