Resilience Glossar
Business Continuity Management (BCM) - Betriebskontinuität bei Cyberangriffen
Business Continuity Management (BCM) stellt sicher, dass kritische Geschäftsprozesse bei einem Cyberangriff, Ransomware oder IT-Ausfall weiterlaufen oder schnell wiederhergestellt werden. Kernkonzepte: BIA (Business Impact Analysis), RTO (Recovery Time Objective), RPO (Recovery Point Objective), BCP (Business Continuity Plan), DRP (Disaster Recovery Plan), Offline-Backup-Strategie (3-2-1-1-0-Regel), Tabletop Exercises. ISO 22301 und BSI IT-Grundschutz Standard 200-4.
Business Continuity Management (BCM) ist die Disziplin, die sicherstellt, dass ein Unternehmen auch dann überlebt, wenn es gehackt wird. Nicht ob ein Cyberangriff kommt, sondern wann - und wie schnell das Unternehmen danach wieder operiert.
Kernkonzepte: RTO und RPO
RTO (Recovery Time Objective):
- Maximale akzeptable Ausfallzeit
- “Wie lange darf ein System maximal ausgefallen sein?”
- Beispiel: E-Mail-Server RTO = 4 Stunden
- Das System MUSS innerhalb dieser Zeit wiederhergestellt sein!
RPO (Recovery Point Objective):
- Maximaler akzeptabler Datenverlust
- “Wie viele Stunden/Tage an Daten dürfen verloren gehen?”
- Beispiel: Kundendatenbank RPO = 1 Stunde
- Backup-Frequenz muss kleiner als RPO sein!
Kosten-Nutzen-Balance
Niedrigeres RTO/RPO = teurere Infrastruktur:
| Ziel | Lösung | Kosten |
|---|---|---|
| RPO: 0s | Synchrone Replikation | Teuer |
| RPO: 15m | Asynchrone Replikation | Mittel |
| RPO: 24h | Tägliche Backups | Günstig |
| RTO: 0s | Hot Standby / Active-Active | Sehr teuer |
| RTO: 1h | Warm Standby | Mittel |
| RTO: 24h | Cold Recovery | Günstig, langsam |
Praxis-Beispiele für Ransomware-Szenario
| Szenario | RTO | RPO |
|---|---|---|
| Ohne BCM | 3-6 Monate | alles verloren |
| Mit BCM | 24-72h | < 24h (letzte saubere Backup) |
| Best in Class | 4-8h | < 1h (Immutable Backups, schnelle DR) |
Business Impact Analysis (BIA)
BIA-Methodik
-
Alle Geschäftsprozesse identifizieren:
- IT-Systeme, Anwendungen, Daten
- Abhängigkeiten: welches System braucht was?
-
Kritikalitätsbewertung:
- Finanzieller Schaden pro Ausfallstunde?
- Reputationsschaden?
- Regulatorische Konsequenzen?
- Kundenverlust?
-
RTO/RPO je Prozess festlegen:
| Prozess | RTO | RPO | Kritikalität |
|---|---|---|---|
| Online-Shop | 1h | 15m | Kritisch |
| ERP/SAP | 4h | 1h | Kritisch |
| 4h | 4h | Hoch | |
| Entwicklungs-Umgebung | 48h | 24h | Mittel |
| Archiv-System | 7d | 7d | Niedrig |
- Abhängigkeitskette:
- Online-Shop benötigt: Datenbank, Zahlungsanbieter, CDN
- Wenn Datenbank ausfällt → Shop fällt aus!
- Datenbankschutz muss RTO/RPO des Shops erfüllen!
BIA-Dokumentation (Template)
- Prozess: Auftragsverarbeitung
- System: SAP ERP
- Owner: Head of Operations
- RTO: 4 Stunden
- RPO: 1 Stunde
- Max. Kosten/h: 50.000 EUR Umsatzverlust
- Abhängigkeiten: SAP Datenbank, Active Directory, SAP-Appserver
- Notfall-Prozess: Manuelle Auftragserfassung in Excel (Workaround)
- Kontakt: SAP-Berater +49 XXX, SAP-Support 0800 XXX
Backup-Strategie für Cyberangriffe
3-2-1-1-0-Backup-Regel (Ransomware-resistent)
- 3: Drei Kopien der Daten (Produktionsdaten + 2 Backups)
- 2: Zwei verschiedene Medien (NAS + Tape ODER On-Premises NAS + Cloud-Backup)
- 1: Mindestens eine offsite-Kopie (anderes Gebäude, Stadt, Cloud)
- 1: Eine offline/air-gapped-Kopie - NICHT über Netzwerk erreichbar; Ransomware kann sie nicht verschlüsseln! Optionen: Tape (am Band), Cloud mit Object Lock, offsite rotierendes NAS
- 0: Null Fehler bei Restore-Tests - Backups regelmäßig TESTEN (nicht nur erstellen!); monatlicher Test: eine zufällige Datei wiederherstellen; quartalsweiser DR-Test: vollständige System-Wiederherstellung
Immutable Backups (technisch)
# AWS S3 Object Lock (WORM):
aws s3api put-object-lock-configuration \
--bucket backup-bucket \
--object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'
# COMPLIANCE-Mode: auch root kann nicht löschen!# Azure Backup Immutability:
Backup Vault → Properties → Immutable Vault: Enable + Lock
→ Niemand kann Backups löschen (auch nicht Admin!)
# Veeam Immutable Backup:
# Repository → Capacity Tier → S3-kompatibel → Immutability aktivieren
# Auch: Veeam mit Hardened Linux Repository (kein SSH = kein Entfernen)Backup-Isolation (wichtig!)
- Backup-Server: eigenes AD-Tier (nicht Domain Admin!)
- Backup-Credentials: in PAM, nicht im Domain Controller
- Backup-Netz: eigenes VLAN, nur Backup-Traffic erlaubt
- Ransomware-Test: kann der Angreifer das Backup-System erreichen?
BCP und Notfallpläne
BCP-Struktur
- Scope und Zweck
- Krisenorganisation (wer macht was?)
- Kommunikationsplan (intern + extern)
- Kritische Prozesse und Workarounds
- IT-Wiederherstellungspläne (DRP)
- Lieferanten- und Partner-Kontakte
- Test- und Übungsplan
Krisenorganisation
Krisenstab-Mitglieder:
- Incident Commander (Gesamtverantwortung)
- IT-Leiter / CISO (technische Koordination)
- Kommunikationsverantwortlicher (intern + extern)
- Rechtsabteilung (Meldepflichten, Vertragsrisiken)
- CFO (finanzielle Entscheidungen: Lösegeld, Versicherung)
- Betriebsrat (wenn Mitarbeiterdaten betroffen)
Eskalationsmatrix:
| Incident-Schwere | Eskalation |
|---|---|
| Server-Ausfall (< 1h) | IT-Team |
| Server-Ausfall (> 1h) | IT-Leiter |
| Ransomware | CISO + Management → Krisenstab |
| KRITIS-Incident | Krisenstab + BSI-Meldung |
Out-of-Band-Kommunikation (KRITISCH!)
- E-Mail-Server kompromittiert? → Wie kommunizieren?
- Mobiltelefon-Gruppen: Signal-Gruppe für Krisenstab
- Notfallhandy: nicht AD-joined, eigene SIM
- Papier-Dokumentation: Telefonliste offline verfügbar!
- Zusammenkunftsort: physischer War Room definiert
Workaround-Dokumentation (Beispiel)
- Prozess: Bestellannahme
- Normal: SAP-ERP-System
- Workaround bei Ausfall:
- Bestellungen per E-Mail an bestell@company.com
- Excel-Template:
\\fileserver\notfallformulare\bestellung.xlsx - Wenn Fileserver auch ausgefallen: Template auf USB-Stick im Tresor
- Manuelle Verarbeitung durch Muster-Abteilung
- Nacherfassung in SAP nach Wiederherstellung
Tabletop Exercises und Tests
Tabletop Exercise (schriftlich/mündlich)
- Szenario: Ransomware-Angriff, 50% der Server verschlüsselt
- Teilnehmer: Krisenstab + IT + Fachbereiche
- Dauer: 2-4 Stunden
- Moderator: AWARE7 oder externer Facilitator
Fragen/Entscheidungen durchspielen:
- Wann schalten wir ab?
- Wer informiert Kunden? Wann?
- Zahlen wir Lösegeld? Wer entscheidet?
- Wann rufen wir BSI und Polizei?
Erkenntnisse typischer Tabletop-Übungen:
- Out-of-Band-Kommunikation nicht vorbereitet
- Backup-Passwörter nur in AD (ebenfalls verschlüsselt!)
- Kontaktlisten veraltet
- Keine klare Entscheidungsverantwortung
DR-Test (technisch)
Jährlich: vollständige System-Wiederherstellung aus Backup
- Zeiterfassung: RTO eingehalten?
- RPO prüfen: wie alt ist der wiederhergestellte Datenstand?
- Protokoll: Test-Report für ISO 22301 / ISO 27001 Audit
Häufige BCM-Mängel (Audit-Findings)
- BCP nie getestet (Theorie ≠ Praxis)
- RTO/RPO nicht definiert (oder zu optimistisch)
- Backups existieren, werden nie wiederhergestellt
- Backup-System im selben Netz wie Produktion
- BCP-Dokumentation veraltet (Personal gewechselt, Systeme geändert)
- Keine Lieferanten-SLAs für Notfälle (z.B. Hardware-Lieferung)
BSI-Standard 200-4 (BCM)
- Anerkannt als BCM-Rahmenwerk in Deutschland
- Aufbau: ähnlich ISO 22301, aber auf Deutsch
- Zertifizierung: möglich (BSI-Zertifizierer)
- Kapitel: BIA-Methodik, Notfallkonzept, Übungsplanung
