Grundschutz:Risikobetrachtung

Diese Seite ist derzeit noch ein Entwurf. Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.

---

Kurze Einführung

Die Risikobetrachtung ergänzt im GS++ die Standardanforderungen überall dort, wo diese allein nicht ausreichen oder bewusst davon abgewichen wird. Ziel ist nicht, möglichst viele Risiken zu dokumentieren, sondern belastbare Entscheidungen zu treffen: Welche Risiken sind relevant, wie hoch sind sie, wer verantwortet sie und welche Maßnahmen werden verbindlich umgesetzt.

In der Praxis funktioniert das am besten schlank und prozessorientiert. Ausgangspunkt sind nicht einzelne technische Systeme, sondern Geschäftsprozesse, die dazugehörigen Informationen, Anwendungen, IT-Systeme, Schnittstellen und beteiligten Personen.

Damit die Ergebnisse belastbar und vergleichbar sind, sollten vor dem Start die grundlegende Methodik, die Bewertungslogik und die Verantwortlichkeiten festgelegt sein. Erst dann lohnt sich der eigentliche Workshop zur Identifikation und Bewertung von Risikoszenarien.

Voraussetzungen

Bevor Du mit der eigentlichen Risikobetrachtung beginnst, sollten einige Grundbedingungen festgelegt sein. Das muss kein schwergewichtiges Methodendokument sein, aber die wesentlichen Regeln sollten einheitlich und dokumentiert vorliegen.

Mindestens geklärt sein sollten:

• welche Methode zur Risikoidentifizierung, Risikobewertung und Risikobehandlung verwendet wird (z.B. ISO 27005, ISO 31000, BSI 200‑3),
• welche Skalen und Kriterien für Auswirkung, Wahrscheinlichkeit und Priorisierung gelten,
• wer als Risikoeigentümer fachlich entscheidet,
• wann ein Risiko akzeptiert werden darf und wann es zwingend behandelt werden muss,
• welche Inputs verpflichtend in die Betrachtung einfließen.

Für die Praxis reicht oft ein kurzes Vorgehenspapier oder ein abgestimmtes Bewertungsblatt. Wichtig ist nicht die Länge, sondern dass alle Beteiligten nach denselben Regeln arbeiten.

Was vor dem ersten Termin vorliegen sollte

Für einen ersten belastbaren Durchlauf sollten mindestens diese Informationen vorliegen:

• ein klar abgegrenzter Geschäftsprozess oder Anwendungsbereich,
• die zugehörigen Informationen, Anwendungen, IT-Systeme und Schnittstellen,
• bekannte Bedrohungen, Schwachstellen, Vorfälle oder Abweichungen,
• der aktuelle Umsetzungsstand vorhandener Schutzmaßnahmen,
• eine Liste möglicher Risikoeigentümer.

Wenn diese Basis fehlt, wird die Risikobetrachtung meist abstrakt oder verliert sich in Vermutungen.

Wann Du sie durchführen solltest

Eine Risikobetrachtung ist besonders sinnvoll, wenn ein Prozess hohen Schutzbedarf hat, ein erhöhtes Sicherheitsniveau angestrebt wird, Anforderungen nicht umgesetzt werden, Ausnahmen erforderlich sind oder neue Technologien und Abhängigkeiten eingeführt werden.

Typische Auslöser sind zum Beispiel:

• eine neue Fachanwendung mit Schnittstellen zu Drittsystemen,
• ein Cloud-Dienst für sensible Daten,
• der Einsatz von KI oder andere Techniken, die im GS++ nicht berücksichtigt sind,
• ein nicht umgesetzter Härtungsstandard,
• eine Ausnahme bei MFA für ein Altsystem,
• ein Lieferantenwechsel mit administrativem Fernzugriff.

Sobald ein solcher Auslöser vorliegt, sollte nicht sofort mit Einzelszenarien begonnen werden. Zuerst sollten Scope, Methode, Bewertungsmaßstab und verantwortliche Personen feststehen.

Praxistaugliches Vorgehen

1. Scope klein und eindeutig schneiden

Beginne nicht mit dem gesamten Informationsverbund, sondern mit einem klar abgrenzbaren Geschäftsprozess. Geeignet ist zum Beispiel „Rechnungsfreigabe“, „Personaladministration“, „Kundenportal“ oder „Remote-Wartung von Produktionssystemen“.

Für den ersten Durchlauf sollte der Scope so gewählt sein, dass in einem Workshop in 60 bis 90 Minuten belastbare Szenarien erarbeitet werden können. Zu große Zuschnitte wie „Verwaltung“ oder „Office-IT“ sind in der Regel zu ungenau und führen zu abstrakten, schlecht bewertbaren Risiken.

2. Rollen vorab festlegen

Vor dem Workshop sollte klar sein:

• wer moderiert,
• wer den Prozess fachlich vertritt,
• wer technische Details liefert,
• wer später als Risikoeigentümer entscheidet.

Sinnvoll ist, den Risikoeigentümer nicht erst am Ende zu suchen. Für ein Kundenportal ist das typischerweise die fachlich verantwortliche Leitung des Portals, nicht allein der ISB oder die IT-Abteilung.

Der Risikoeigentümer sollte nicht nur benannt, sondern auch mit einer klaren Aufgabe versehen sein: Er entscheidet über Behandlung, befristete Akzeptanz und Priorität aus fachlicher Sicht. Der ISB, CISO oder das Security-Team kann methodisch unterstützen, sollte fachliche Geschäftsrisiken aber nicht allein akzeptieren.

3. Risiken als echte Szenarien formulieren

In der Praxis ist das der häufigste Qualitätsunterschied. Notiere keine Einzelbegriffe wie „Hacker“, „Ausfall“, „Malware“ oder „Feuer“, sondern vollständige Szenarien.

Schlecht:

• Hackerangriff auf Webserver
• Administratorfehler
• Cloud-Ausfall

Besser:

• Ein externer Angreifer nutzt eine ungepatchte Schwachstelle im Internet-exponierten Webserver des Kundenportals und liest dadurch personenbezogene Kundendaten aus.
• Eine Administratorin löscht bei einer fehlerhaften Änderung an der Firewall produktive Freigaben, wodurch die Rechnungsverarbeitung für mehrere Stunden stillsteht.
• Der Cloud-Anbieter stellt den Objektspeicher aufgrund einer Störung nicht bereit, wodurch revisionsrelevante Dokumente im Freigabeprozess vorübergehend nicht verfügbar sind.

Eine einfache, praxistaugliche Syntax ist:

Geschäftsprozess + Bedrohungsquelle + Schwachstelle/Vektor + betroffenes Objekt + Auswirkung.

Wo Informationen fehlen, sollten Annahmen und Unsicherheiten direkt am Szenario vermerkt werden. Das ist besser, als unklare Punkte stillschweigend zu unterstellen, und erleichtert die spätere Überprüfung.

Beispiel: „Der Fernzugriff des Dienstleistenden erfolgt vermutlich ohne gerätegebundene MFA; technische Bestätigung steht noch aus.“

4. Bestehende Maßnahmen gleich mit betrachten

Viele Risikobewertungen werden unrealistisch, weil nur das Szenario beschrieben wird, aber nicht der aktuelle Schutzstatus. Halte deshalb je Szenario sofort fest:

• welche Maßnahmen bereits umgesetzt sind,
• ob diese wirksam, teilweise wirksam oder nur formal vorhanden sind,
• welche Lücken offen sind.

Beispiel:

Beim Szenario „Kompromittierung eines Admin-Kontos“ können vorhandene Maßnahmen sein:

• MFA für Administrationszugänge: umgesetzt,
• getrennte Admin-Konten: teilweise umgesetzt,
• PAM: nicht umgesetzt,
• Protokollierung privilegierter Aktionen: umgesetzt,
• regelmäßige Rezertifizierung: nicht umgesetzt.

Dadurch wird die spätere Unterscheidung zwischen Brutto-, Netto- und Restrisiko deutlich einfacher.

Entscheidend ist die tatsächliche Ist-Situation, nicht der Soll-Zustand aus Richtlinien oder Konzepten. Eine Maßnahme gilt nur dann als wirksam umgesetzt, wenn sie im betrachteten Prozess oder Zielobjekt real vorhanden und nachweisbar ist.

5. Bewertung mit einfacher, stabiler Skala

Für die Praxis reicht zunächst meist eine qualitative 3x3- oder 4x4-Matrix. Entscheidend ist nicht mathematische Feinheit, sondern nachvollziehbare und wiederholbare Bewertung.

Wichtig ist, dass die Bewertung nicht frei aus dem Bauch erfolgt. Für jede Einstufung sollte kurz begründet werden, warum die Auswirkung oder Wahrscheinlichkeit so angesetzt wurde, zum Beispiel mit Bezug auf Schutzbedarf, Exponierung, bekannte Schwachstellen, Vorfälle oder vorhandene Kompensationen.

Bewerte pro Szenario mindestens:

• Schadensauswirkung,
• Eintrittswahrscheinlichkeit,
• vorhandene Maßnahmen,
• resultierende Priorität.

Eine bewährte Logik ist:

• Auswirkung: niedrig / mittel / hoch / sehr hoch
• Wahrscheinlichkeit: niedrig / mittel / hoch / sehr hoch
• Priorität: grün / gelb / rot

Wichtiger als die Farbe ist die Regel dahinter. Zum Beispiel:

• Grün: mit vorhandenem Sicherheitsniveau vertretbar
• Gelb: Managemententscheidung oder zusätzliche Maßnahme erforderlich
• Rot: Behandlung zwingend, keine bloße Beobachtung

Diese Regeln sollten vorab von der Institution festgelegt sein. In der Praxis genügt oft schon eine einfache Festlegung, wer gelbe Risiken akzeptieren darf und ab wann rote Risiken zwingend an die Leitung oder das zuständige Management eskaliert werden.

Bei Vertraulichkeitsverletzungen mit gemischten Datenbeständen ist es praxistauglich, am kritischsten Datensatz anzusetzen, sofern keine belastbare Segmentierung nachgewiesen ist.

Wenn Du die Wahrscheinlichkeit strukturierter bestimmen willst, kannst Du zwischen äußerem Angriffs- oder Ereignisdruck und interner Verwundbarkeit unterscheiden. Das macht Bewertungen robuster, ist aber kein Muss für einen ersten praxistauglichen Durchlauf.

5.1 Bewertungsgrundlage knapp dokumentieren

Für jedes bewertete Risiko sollte in ein bis zwei Sätzen nachvollziehbar sein, worauf die Einstufung beruht. Gute Begründungen verweisen auf Schutzbedarf, betroffene Daten, Exponierung, bekannte Schwachstellen, bestehende Maßnahmen, Vorfälle oder Erfahrungswerte.

Das spart später viel Diskussion, weil Bewertungen nicht neu geraten werden müssen. Gerade bei gelben und roten Risiken ist eine kurze Begründung wichtiger als eine feinere Matrix.

6. Risiken priorisieren, nicht sammeln

Nach dem Workshop sollte keine lange unsortierte Liste stehen bleiben. Für die operative Steuerung reichen oft die Top-Risiken je Prozess.

Eine gute Arbeitsregel:

• alle identifizierten Szenarien dokumentieren,
• nur die priorisierten Risiken in Maßnahmenplanung und Managementvorlage überführen,
• Dubletten zusammenführen,
• systemische Risiken referenzieren statt mehrfach neu analysieren.

Beispiel:

„Ausfall der zentralen Identitätsplattform“ muss nicht in jedem Einzelprozess vollständig neu bewertet werden. Es kann als systemisches Risiko zentral geführt und in betroffenen Prozessen referenziert werden.

Am Ende dieses Schritts sollte eine priorisierte Risikoliste vorliegen, in der jedes relevante Risiko mindestens einer verantwortlichen Person zugeordnet ist. Spätestens hier sollte klar sein, welche Risiken aktiv behandelt, welche weiter analysiert und welche zur Entscheidung vorgelegt werden.

7. Risikobehandlung konkret und prüfbar formulieren

Maßnahmen sollten so beschrieben sein, dass Umsetzungsverantwortliche wissen, was genau zu tun ist. Ungeeignet sind Formulierungen wie:

• Sicherheit verbessern
• Zugriff absichern
• Backup optimieren

Besser:

• Für alle privilegierten Konten bis 30.09. MFA verpflichtend aktivieren; Ausnahmen nur nach dokumentierter Freigabe.
• Für das Kundenportal monatliches Patch-Fenster mit maximal 14 Tagen Verzugszeit nach kritischen Security-Advisories einführen.
• Wiederherstellungstest für Backup des DMS quartalsweise durchführen und Zielwert „Recovery unter 4 Stunden“ nachweisen.

Für jedes priorisierte Risiko sollte bewusst entschieden werden, ob es reduziert, vermieden, übertragen oder formal akzeptiert wird. Reine Beobachtung reicht dann nicht aus, wenn das Risiko oberhalb des festgelegten Toleranzbereichs liegt.

So wird aus einem Risiko ein steuerbares Requirement im Maßnahmenplan.

Zusätzlich sollte kurz geprüft werden, ob die gewählte Maßnahme neue Probleme erzeugt. Mehr Vertraulichkeit kann zum Beispiel die Verfügbarkeit beeinträchtigen, wenn Wartung oder Wiederherstellung unnötig erschwert werden.

8. Akzeptanzen knapp, befristet und personifiziert halten

Risikoakzeptanzen sollten die Ausnahme sein und nicht das Ende der Diskussion. In der Praxis haben sich dafür vier Pflichtangaben bewährt:

• welches Risiko konkret akzeptiert wird,
• warum eine Behandlung aktuell nicht erfolgt,
• bis wann die Akzeptanz gilt,
• wer fachlich verantwortlich unterschreibt.

Beispiel:

„Das Restrisiko aus fehlender MFA für den Zugriff auf das Altverfahren X wird bis zum 31.12.2027 akzeptiert, da die Ablösung bis Q4/27 geplant ist. Bis dahin gelten IP-Restriktion, VPN-Pflicht und tägliches Monitoring der Admin-Logins als kompensierende Maßnahmen.“

Sinnvoll ist außerdem eine einfache Freigabelogik: geringe Risiken können im Fachbereich entschieden werden, mittlere Risiken benötigen meist eine dokumentierte Managemententscheidung, hohe Risiken sollten nicht ohne Eskalation akzeptiert werden. So bleibt das Verfahren auch bei Ausnahmen konsistent.

9. Maßnahmen mit Anforderungen verknüpfen

Sobald ein Risiko behandelt werden soll, muss daraus ein konkreter Eintrag im Maßnahmenplan oder Backlog entstehen. Bewährt hat sich eine einfache Nachverfolgbarkeit:

• Risiko-ID,
• Maßnahme-ID,
• Verantwortliche Person,
• Frist,
• Status,
• erwartete Risikoreduktion.

Ohne diese Verknüpfung bleibt die Risikobetrachtung oft ein Papierartefakt. Mit Verknüpfung wird sie steuerbar und auditierbar.

Maßnahmen sollten so klein und eindeutig geschnitten sein, dass sie einzeln geplant, umgesetzt und geprüft werden können. Statt „Administrationszugänge härten“ ist „MFA für privilegierte Konten aktivieren“ das bessere Requirement.

10. KVP ereignisgesteuert aufbauen

Nicht jede Risikobetrachtung muss vollständig jährlich neu erstellt werden. Praktischer ist eine Kombination aus Regelreview und klaren Auslösern.

Geeignete Auslöser sind:

• schwerer Sicherheitsvorfall,
• neue Bedrohungslage,
• Architekturänderung,
• neue kritische Schwachstelle,
• Wegfall einer kompensierenden Maßnahme,
• Wechsel eines wesentlichen Dienstleistenden.

Für besonders relevante Risiken sollten direkt Wirksamkeitsindikatoren festgelegt werden. Beispiele:

• Quote privilegierter Konten mit MFA = 100%
• Kritische Patches innerhalb von 14 Tagen eingespielt
• Erfolgreicher Restore-Test pro Quartal
• Keine unreviewten Admin-Accounts älter als 90 Tage

Akzeptierte Restrisiken sollten im nächsten Zyklus nicht einfach fortgeschrieben werden. Sie sollten erneut als reguläre Risiken betrachtet werden, insbesondere wenn sich Bedrohungslage, Architektur, Schutzmaßnahmen oder Geschäftsanforderungen verändert haben.

Kompakter Ablauf für die Praxis

Für einen ersten sauberen Durchlauf reicht oft dieses Muster:

1. Geschäftsprozess, Scope, Methode und Bewertungsmaßstab festlegen.
2. Fachseite, IT, methodische Begleitung und Risikoeigentümer in einen Termin bringen.
3. 5 bis 10 belastbare Risikoszenarien formulieren.
4. Vorhandene Maßnahmen und Lücken je Szenario dokumentieren.
5. Auswirkungen und Wahrscheinlichkeit nach einheitlicher Skala bewerten.
6. Top-Risiken priorisieren und verantwortlichen Personen zuordnen.
7. Maßnahmen oder befristete Akzeptanz beschließen.
8. Übertrag in Maßnahmenplan und Wiedervorlage sicherstellen.

Woran man eine brauchbare Risikobetrachtung erkennt

Eine praxistaugliche Risikobetrachtung ist knapp, konkret und entscheidungsorientiert. Sie beschreibt echte Szenarien, enthält benannte Verantwortliche, arbeitet mit einer einheitlichen Bewertungslogik, kennzeichnet Annahmen und Unsicherheiten, verweist auf bestehende Maßnahmen, führt zu umsetzbaren Aufgaben und macht sichtbar, welche Restrisiken bewusst getragen werden.

Unbrauchbar wird sie meist dann, wenn der Scope zu groß ist, Risiken nur aus Schlagworten bestehen, technische und fachliche Sicht nicht zusammengebracht werden oder Maßnahmen nicht in die Umsetzungsplanung überführt werden.

Integration in GS++‑Anforderungspaket

Ziel: Konsistenz zwischen Risikobetrachtung und GS++‑Anforderungs‑ und Umsetzungsplanung:

• alle Maßnahmen aus Risikobehandlungsplan als Anforderungen/Maßnahmen im GS++‑Anforderungspaket abbilden
• nicht umgesetzte Standardanforderungen mit zugehörigen Risikoszenarien verknüpfen
• Ergänzungen aus Risikobetrachtung (zusätzliche Anforderungen) im Anforderungspaket markieren
• sicherstellen, dass Planung, Monitoring und Auditierung auf dieselbe Risikobasis referenzieren

Ergebnis: durchgängige Verknüpfung von Anforderungspaket, Maßnahmenplan und Risikobetrachtung.

Voraussetzung dafür ist, dass Risiko-IDs, Maßnahmen, Verantwortlichkeiten und Entscheidungsstände einheitlich geführt werden. Nur dann bleiben Risikobetrachtung, Umsetzungsplanung und spätere Überwachung konsistent.