Cyber Resilience

Cyber Resilience erweitert den klassischen Sicherheitsansatz: Während Cybersecurity darauf zielt, Angriffe zu verhindern, geht Cyber Resilience davon aus, dass Angriffe erfolgreich sein werden (“Assume Breach”). Das Ziel ist dann, Schäden zu minimieren, schnell zu erkennen, zu reagieren und den Betrieb aufrechtzuerhalten.

Cyber Resilience vs. Cybersecurity

Merkmal	Cybersecurity (Prävention)	Cyber Resilience (Absorption + Recovery)
Frage	”Wie verhindern wir Angriffe?"	"Was tun wenn ein Angriff erfolgreich ist?”
Fokus	Firewall, AV, Patch-Management, Authentifizierung	Backup, IR-Plan, Kommunikation, Business Continuity
Metrik	”Wir haben 0 Incidents dieses Jahr”	MTTD + MTTR
Denkweise	Festung bauen	Assume Breach - plane für den Ernstfall

Beide sind notwendig:

• Nur Prävention: kein Plan für den Ernstfall
• Nur Resilience: warum überhaupt Prävention?
• Kombiniert: professionelle Sicherheitsstrategie

Regulatorischer Rahmen

DORA (Digital Operational Resilience Act):

• EU-Regulierung für Finanzsektor (ab Januar 2025)
• Fordert explizit Cyber Resilience, nicht nur Compliance
• TLPT (Threat-Led Penetration Testing) für systemrelevante Institute
• 5 Säulen: ICT Risk Management, Incident Reporting, TLPT, ICT Third-Party Risk, Information Sharing

NIS2 und Resilience:

• Art. 21: “Business Continuity” als Pflichtmaßnahme
• Backup-Konzepte, Krisenmanagement, Disaster Recovery

Die 5 Resilience-Dimensionen (NIST SP 800-160)

1. Anticipate (Antizipieren)

• Bedrohungen voraussehen
• Threat Intelligence nutzen
• Red Team Übungen
• “Was wird wahrscheinlich als nächstes angreifen?“

2. Withstand (Standhalten)

• Angriff läuft - Auswirkungen minimieren
• Redundanz: kein Single Point of Failure
• Segmentierung: Ausbreitung stoppen
• Isolation: befallene Systeme abschneiden

3. Recover (Erholen)

• Business Continuity trotz Incident
• Backup und Restore (getestet!)
• Disaster Recovery Plan
• Kommunikation intern + extern

4. Adapt (Anpassen)

• Aus Incidents lernen
• Prozesse verbessern
• Controls verstärken wo Lücken gefunden
• Post-Incident Review obligatorisch

5. Prepare (Vorbereiten)

• Tabletop Exercises (simulierte Incidents)
• Regelmäßige Backuptests
• IR-Plan aktuell halten
• Mitarbeiter für Krisen schulen

Kennzahlen (KPIs) für Cyber Resilience

MTTD - Mean Time to Detect:

• Zeit von Incident bis Erkennung
• Ziel: < 24h für kritische Systeme
• Branchenschnitt 2024: 207 Tage (IBM)!

MTTR - Mean Time to Respond/Recover:

• Zeit von Erkennung bis Wiederherstellung
• Ziel: < 4h für kritische Systeme, < 24h für wichtige

Business-Impact-Ziele nach System-Typ:

System-Typ	RTO	RPO
ERP/Finanzen	4h	1h
E-Mail	8h	4h
File-Server	24h	4h
Webseite	8h	24h
Archive	72h	24h

Resilience-Maßnahmen praktisch

1. Immutable Backups (unveränderliche Sicherungen)

Ransomware kann diese Backups nicht löschen oder verschlüsseln:

• AWS S3 Object Lock (WORM: Write Once Read Many)
• Azure Blob Storage Immutability Policy
• Veeam Hardened Repository (Linux, ext4)
• Air-Gap: physisch getrennt, kein Netz-Zugriff

2. Redundanz für kritische Dienste

• Active Directory: min. 2 Domain Controller
• E-Mail: MX-Failover-Server konfiguriert?
• Internet: 2 ISPs (Load Balancing oder Failover)
• Rechenzentrum: 2 Standorte (Georedundanz)

3. Kommunikationsplan für Incidents

• Out-of-Band-Kommunikation (nicht über die betroffene IT!)
• Notfall-Handyliste: CEO, CTO, CISO, Legal, PR
• Krisenkommunikations-Template: was sagen wir Kunden?
• BSI-Meldung: 24h für NIS2-Betroffene!
• Datenschutzbehörde: 72h bei DSGVO-relevantem Vorfall

4. Tabletop Exercises (Krisensimulation)

• Realistische Szenarien: “Ransomware heute um 08:00 Uhr”
• Kein Technik - Prozess und Entscheidungen üben
• Teilnehmer: IT, Management, Legal, PR, Geschäftsführung
• Frequenz: min. 1x/Jahr

5. Recovery-Tests

• Backup ist wertlos wenn Restore nicht funktioniert!
• Quartalsweise: Datei-Restore aus Backup
• Halbjährlich: Server-Restore in Testumgebung
• Jährlich: vollständiger DR-Test (alles aus Backups aufbauen)