Risikomanagement (IT-Sicherheit)

IT-Sicherheits-Risikomanagement ist der strukturierte Umgang mit Informationssicherheitsrisiken. Im Gegensatz zu einem starren Maßnahmenkatalog fragt ISO 27001: “Welche Risiken hat unser Unternehmen spezifisch - und wie gehen wir damit um?”

Der Risikomanagement-Zyklus (ISO 27001)

┌─────────────────────────────────────────────────────┐
│                 RISIKOBEURTEILUNG                   │
│                                                     │
│  Kontext festlegen          Assets identifizieren   │
│       ↓                           ↓                 │
│  Bedrohungen             Schwachstellen             │
│  identifizieren          identifizieren             │
│       ↓                           ↓                 │
│       └──────── Risiken bewerten ─┘                 │
│                     ↓                               │
│              Risikoakzeptanz?                       │
└─────────────────────────────────────────────────────┘
          ↓ (wenn Risiko inakzeptabel)
┌─────────────────────────────────────────────────────┐
│               RISIKOBEHANDLUNG                      │
│                                                     │
│  Vermeiden  │  Reduzieren  │  Übertragen  │ Akzept. │
└─────────────────────────────────────────────────────┘
          ↓
┌─────────────────────────────────────────────────────┐
│    MONITORING & REVIEW (kontinuierlich)             │
└─────────────────────────────────────────────────────┘

Schritt 1: Assets identifizieren und klassifizieren

Asset-Typen

Primäre Assets (direkt wertvoll):

• Daten: Kundendaten, Finanzdaten, IP, Mitarbeiterdaten
• Prozesse: Auftragsabwicklung, HR-Prozesse
• Personen: Schlüsselmitarbeiter, Administratoren

Unterstützende Assets (ermöglichen Primär-Assets):

• IT-Systeme: Server, Workstations, Netzwerkgeräte
• Software: ERP, CRM, Datenbanken
• Infrastruktur: Rechenzentrum, Stromversorgung

Klassifizierung (CIA-Triade)

Vertraulichkeit (Confidentiality): “Was passiert wenn diese Information öffentlich wird?” → Öffentlich / Intern / Vertraulich / Streng Vertraulich

Integrität (Integrity): “Was passiert wenn diese Daten verändert werden?” → Niedrig / Mittel / Hoch / Kritisch

Verfügbarkeit (Availability): “Was passiert wenn dieses System 1h/1Tag ausfällt?”

• RTO: Recovery Time Objective
• RPO: Recovery Point Objective

Schritt 2: Risiken bewerten

Qualitative Methode (5×5-Matrix)

Risiko = Eintrittswahrscheinlichkeit × Schadensauswirkung

Wahrscheinlichkeit:

Wert	Stufe	Häufigkeit
1	Sehr unwahrscheinlich	< 1% pro Jahr
2	Unwahrscheinlich	1-5% pro Jahr
3	Möglich	5-20% pro Jahr
4	Wahrscheinlich	20-50% pro Jahr
5	Sehr wahrscheinlich	> 50% pro Jahr

Auswirkung:

Wert	Stufe	Bedeutung
1	Vernachlässigbar	Keine spürbaren Folgen
2	Gering	Geringer Schaden, intern lösbar
3	Erheblich	Spürbare Beeinträchtigung, externer Aufwand
4	Schwerwiegend	Erheblicher Schaden, Reputationsschaden
5	Katastrophal	Existenzgefährdend, insolvenzgefährdend

Risikoniveau:

Score	Stufe	Handlung
1-4	Niedrig	Akzeptieren oder kostengünstig behandeln
5-9	Mittel	Behandlung geplant
10-16	Hoch	Sofortige Behandlung erforderlich
17-25	Kritisch	Sofortige Eskalation, Notfallmaßnahme

Beispiel: Risikobewertung (Ausschnitt)

ID  | Szenario                    | W | A | Risk | Behandlung
────────────────────────────────────────────────────────────
R01 | Ransomware auf Fileserver   | 4 | 5 |  20  | Kritisch → Backup + EDR
R02 | Phishing → CEO-Fraud        | 4 | 3 |  12  | Hoch → Awareness + DMARC
R03 | Insider-Datendiebstahl      | 2 | 4 |   8  | Mittel → DLP + PAM
R04 | DDoS auf Webshop            | 3 | 3 |   9  | Mittel → CDN + Scrubbing
R05 | Physischer Einbruch RZ      | 1 | 5 |   5  | Niedrig → Zugangskontrolle
R06 | SW-Lieferanten-Kompromiss   | 2 | 5 |  10  | Hoch → Vendor Assessment

Schritt 3: Risikobehandlungsoptionen

1. Vermeiden (Risk Avoidance): Aktivität/Prozess, der das Risiko verursacht, wird eingestellt. Beispiel: Cloud-Dienst in nicht-EU-Land → nicht nutzen

2. Reduzieren (Risk Reduction/Mitigation): Maßnahmen senken Wahrscheinlichkeit oder Auswirkung. Beispiel: MFA → reduziert Phishing-Erfolgswahrscheinlichkeit; Backup → reduziert Ransomware-Auswirkung

3. Übertragen (Risk Transfer): Risiko an Dritte auslagern. Beispiel: Cyber-Versicherung (Auswirkung übertragen); Outsourcing (Risiko teilweise übertragen)

Achtung: Verantwortung bleibt beim Unternehmen (DSGVO!)

4. Akzeptieren (Risk Acceptance): Bewusste Entscheidung: Risiko ist tolerierbar. Beispiel: Veraltetes System mit CVSS 4.2 in isoliertem Netz Voraussetzung: Dokumentiert, Geschäftsführung informiert

Statement of Applicability und Risikobehandlung

ISO 27001 Kapitel 6.1.3 verknüpft Risikobewertung mit Controls. Für jeden der 93 Controls in Anhang A wird dokumentiert:

Control A.8.5 Secure Authentication:
  Bezug: Risiko R02 (Phishing → Credential-Kompromittierung)
  Anwendbar: Ja
  Begründung: Wir nutzen MS365 mit Remote-Zugang → MFA kritisch
  Implementiert: Ja (2024-11)
  Nachweis: MFA-Policy, Azure AD Conditional Access Config

Control A.7.2 Physical Entry Controls:
  Bezug: Risiko R05 (physischer Einbruch)
  Anwendbar: Ja (Büro mit Serverraum)
  Implementiert: Teilweise (Zugang gesichert, aber kein Protokoll)
  Maßnahme: Protokollierung bis 2026-06 implementieren

Risikoakzeptanz und Risikoappetit

Risikoakzeptanzgrenze definieren

Beispiel-Unternehmensrichtlinie:

“Risiken mit einem Score > 12 werden nicht akzeptiert. Alle Risiken > 12 müssen durch Maßnahmen auf ≤ 12 reduziert werden.”

Anforderungen an akzeptierte Risiken (Accepted Risk)

Akzeptierte Risiken müssen:

• Dokumentiert sein (Datum, Begründung)
• Vom Management genehmigt sein (GF-Unterschrift)
• Regelmäßig überprüft werden (mindestens jährlich)
• Nur temporär akzeptiert werden (mit Zieldatum für Behebung)

Beispiel-Formular:

Feld	Inhalt
Risk ID	R15
Beschreibung	Legacy-System XY ohne Patch-Support
Risk Score	15 (HOCH)
Akzeptiert bis	2027-01 (Ablöse geplant)
Begründung	Kosten der Ablöse > Schadenpotenzial in Übergangszeit
Kompensation	Netzwerksegmentierung, erhöhtes Monitoring
Genehmigt von	Max Muster, Geschäftsführer (Datum)

Kontinuierliches Risikomanagement

Wann muss die Risikobewertung überarbeitet werden?

Anlassbezogen:

• Neue Technologien oder Dienste eingeführt
• Organisatorische Änderungen (Übernahme, Restrukturierung)
• Sicherheitsvorfall eingetreten
• Neue regulatorische Anforderungen (NIS2, DSGVO-Änderung)
• Neue Bedrohungslagen (neue Malware-Familien, APT-Berichte)
• Ergebnisse des internen Audits

Regelmäßig (mindestens):

• Jährliche Überprüfung aller Risiken (ISO 27001 Pflicht)
• Quartalsweise: Neue Bedrohungen einbeziehen?
• Management Review: GF erhält Risiko-Übersicht jährlich

KPIs für Risikomanagement

• Anzahl offener kritischer Risiken
• % behandelter Risiken nach Plan
• Durchschnittliche Behandlungszeit
• Anzahl akzeptierter Risiken > Risikoappetit (Ausnahmen)