Von Prävention zu Resilienz
Cybersicherheit hat lange darauf fokussiert, Incidents zu verhindern. Aber die Realität ist, dass Incidents auftreten werden — die Frage ist, wie gut Sie diese bewältigen können.
Operative Resilienz handelt davon, die Fähigkeit der Organisation aufzubauen, Störungen zu absorbieren, sich anzupassen und weiterhin zu liefern. Es ist ein Paradigmenwechsel von “das passiert uns nicht” zu “wenn es passiert, sind wir bereit”.
Die Grundfrage: Wenn Ihr wichtigstes System morgen ausfällt — wie schnell können Sie sich erholen? Und wissen Sie es sicher, oder glauben Sie es nur?
Die vier Säulen der Resilienz
1. Business Continuity (BCP) Pläne zur Aufrechterhaltung kritischer Geschäftsprozesse bei Störungen. Was ist kritisch? Wie machen wir weiter, wenn X nicht funktioniert?
2. Disaster Recovery (DR) Technische Pläne zur Wiederherstellung von IT-Systemen und Daten. Backup, Redundanz, Wiederherstellungsverfahren.
3. Incident Management Prozesse zur Erkennung, Behandlung und zum Lernen aus Sicherheitsvorfällen. Rollen, Eskalation, Kommunikation.
4. Krisenkommunikation Wie kommunizieren wir intern und extern in einer Krise? Wer sagt was zu wem?
NIS2-Anforderungen an Resilienz
NIS2 Artikel 21.2c fordert Business Continuity und Krisenmanagement, einschließlich Backup und Disaster Recovery.
Artikel 21.2b fordert die Behandlung von Sicherheitsvorfällen, einschließlich 24-Stunden-Meldung an das BSI.
Implizite Anforderung, dass Pläne in der Praxis funktionieren müssen. Ungetestete Prozesse sind unzuverlässig.
Maßnahmen müssen verhältnismäßig zum Risiko sein. Kritische Systeme erfordern robustere Resilienz.
Resilienz Schritt-für-Schritt aufbauen
- Kritische Prozesse und Systeme identifizieren Was muss funktionieren, damit das Unternehmen überlebt? Abhängigkeiten kartieren. Priorisierung basierend auf Geschäftsauswirkungen bei Ausfall.
- RTO und RPO definieren Wie schnell muss jeder kritische Prozess/jedes System wiederhergestellt werden (RTO)? Wie viel Datenverlust ist akzeptabel (RPO)? Diese steuern das Design der Lösungen.
- Technische Fähigkeiten implementieren Backup, Replikation, Redundanz, Failover. Sicherstellen, dass die Technik RTO/RPO erfüllen kann. Wiederherstellungsverfahren dokumentieren.
- Pläne und Verfahren erstellen Business Continuity Plan, DR-Plan, Incident-Plan, Krisenkommunikationsplan. Klare Rollen, Verantwortlichkeiten und Eskalationswege.
- Testen und üben Ungetestete Pläne funktionieren selten. Übungen durchführen: Tabletop, technische Tests, vollumfängliche Simulationen. Aus Ergebnissen lernen.
- Kontinuierlich verbessern Pläne basierend auf Erkenntnissen, Geschäftsänderungen und neuen Bedrohungen aktualisieren. Resilienz ist ein Prozess, kein Projekt.
Übungstypen
| Typ | Beschreibung | Häufigkeit |
|---|---|---|
| Tabletop | Diskussionsübung ohne technische Aktivierung. “Was tun wir, wenn X passiert?” | Quartalsweise |
| Walkthrough | Schritt-für-Schritt-Durchgang der Verfahren. Lücken identifizieren. | Halbjährlich |
| Funktional | Spezifische Fähigkeit testen, z.B. Backup-Wiederherstellung | Monatlich |
| Vollumfänglich | Echten Incident simulieren. Alle Prozesse aktivieren. | Jährlich |
Häufige Schwachstellen
Das Dokument existiert, aber niemand weiß, ob es funktioniert. 73% derjenigen, die testen, finden Schwachstellen.
Der Plan referenziert Systeme, die nicht mehr existieren, oder vermisst neue kritische Systeme.
DR-Plan existiert, aber kein Business Continuity Plan. IT kann wiederherstellen, aber das Geschäft weiß nicht, was zu tun ist.
Die Technik funktioniert, aber niemand weiß, wie man mit Kunden, Medien, Behörden kommuniziert.
Kritische Abhängigkeiten von Schlüsselpersonen, einzelnen Systemen oder Lieferanten.
Backups werden erstellt, aber niemand hat getestet, sie wiederherzustellen. "Schrödingers Backup."
Checkliste für Resilienz
Identifizierung:
- Kritische Geschäftsprozesse identifiziert
- Kritische Systeme kartiert
- Abhängigkeiten dokumentiert
- RTO und RPO definiert
Technische Fähigkeiten:
- Backup-Strategie implementiert
- Wiederherstellung getestet und verifiziert
- Redundanz für kritische Systeme
- Failover-Mechanismen vorhanden
Pläne und Prozesse:
- Business Continuity Plan dokumentiert
- DR-Plan dokumentiert
- Incident Management Plan dokumentiert
- Krisenkommunikationsplan dokumentiert
Test und Übung:
- Tabletop-Übung im letzten Quartal durchgeführt
- Technischer DR-Test im letzten Halbjahr durchgeführt
- Vollumfängliche Übung im letzten Jahr durchgeführt
- Erkenntnisse dokumentiert und Pläne aktualisiert
So kann Securapilot helfen
Securapilot unterstützt die Resilienzarbeit Ihrer Organisation:
- Business Continuity — BCP dokumentieren und verwalten
- Incident Management — Strukturierte Behandlung und Berichterstattung
- Risikomanagement — Bedrohungen der Resilienz identifizieren
- Dokumentation — Pläne und Verfahren an einem Ort
- Nachverfolgung — Übungen und Verbesserungsmaßnahmen verfolgen
Demo buchen und sehen Sie, wie wir Ihre Resilienzfähigkeiten unterstützen können.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Resilienz und Backup?
Backup ist eine technische Maßnahme zur Wiederherstellung von Daten. Resilienz ist die Fähigkeit der Organisation, trotz Störungen weiter zu funktionieren. Backup ist Teil der Resilienz, aber längst nicht alles.
Wie hängt Resilienz mit NIS2 zusammen?
NIS2 Artikel 21 fordert explizit Business Continuity und Krisenmanagement. Organisationen müssen kritische Dienste bei Störungen aufrechterhalten oder wiederherstellen können.
Wie oft sollten wir unsere Resilienz testen?
Mindestens jährlich für übergreifende Business Continuity. Backup-Wiederherstellung und technische DR öfter. Incident-Übungen 1-2 mal pro Jahr. Tabletop-Übungen können quartalsweise durchgeführt werden.
Was sind RTO und RPO?
RTO (Recovery Time Objective) ist die maximal akzeptable Zeit zur Wiederherstellung eines Dienstes. RPO (Recovery Point Objective) ist der maximal akzeptable Datenverlust, gemessen in Zeit. Beispiel: RTO 4 Stunden, RPO 1 Stunde.
