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. |
{{#seo: |title=Risikobetrachtung im Grundschutz++: Praxisnahe Kurzanleitung mit Beispielen |keywords=Risikobetrachtung, Grundschutz++, BSI, ISMS, Informationssicherheit, Risikoanalyse, Risikobewertung, Risikobehandlung, Restrisiko, Risikoakzeptanz, IT‑Sicherheit, Stand der Technik |description=Kurzanleitung zur Risikobetrachtung im BSI Grundschutz++. Mit konkreten Beispielen, klarer Szenario‑Syntax, Bewertungsskalen und umsetzbaren Maßnahmen für ISMS und NIS2‑Kontext.
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.
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.
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.
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.
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.
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.
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
Bei Vertraulichkeitsverletzungen mit gemischten Datenbeständen ist es praxistauglich, am kritischsten Datensatz anzusetzen, sofern keine belastbare Segmentierung nachgewiesen ist.
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.
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.
So wird aus einem Risiko ein steuerbares Requirement im Maßnahmenplan.
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.“
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.
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
Kompakter Ablauf für die Praxis
Für einen ersten sauberen Durchlauf reicht oft dieses Muster:
- Geschäftsprozess und Scope festlegen.
- Fachseite, IT und Risikoeigentümer in einen Termin bringen.
- 5 bis 10 belastbare Risikoszenarien formulieren.
- Vorhandene Maßnahmen und Lücken je Szenario dokumentieren.
- Auswirkungen und Wahrscheinlichkeit nach einheitlicher Skala bewerten.
- Top-Risiken priorisieren und verantwortlichen Personen zuordnen.
- Maßnahmen oder befristete Akzeptanz beschließen.
- Ü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, 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.
