In diesem Artikel 11 Abschnitte
Nach einem Ransomware-Vorfall ist «alles möglichst schnell wieder einschalten» kein belastbarer Plan. Ein sicherer Wiederanlauf folgt einer festgelegten Reihenfolge: zuerst Lage und Vertrauensbasis klären, dann Kernabhängigkeiten herstellen und erst danach Fachsysteme sowie Arbeitsplätze zurückbringen. Diese Prioritäten sollten vor einem Vorfall mit der Geschäftsleitung vereinbart und praktisch getestet sein.
Kurz gesagt
- Isolieren und untersuchen Sie betroffene Systeme, bevor eine Wiederherstellung beginnt.
- Priorisieren Sie Geschäftsprozesse und ihre technischen Abhängigkeiten, nicht einzelne Server nach Bauchgefühl.
- Stellen Sie Identitäten, Netzwerkbasis, Protokollierung und saubere Administrationswege kontrolliert bereit.
- Prüfen Sie Backups auf Verfügbarkeit, Integrität und einen geeigneten Wiederherstellungspunkt.
- Dokumentieren Sie Entscheidungen und testen Sie den Wiederanlauf regelmässig.
Recovery beginnt mit Geschäftsfragen
Die technische Reihenfolge ergibt sich aus dem Betrieb. Welche Leistungen müssen zuerst wieder verfügbar sein? Was kann vorübergehend manuell erledigt werden? Welche Unterbrechung ist tragbar, und wie viel Datenverlust wäre im jeweiligen Prozess akzeptabel?
Aus diesen Antworten entstehen zwei Planungsgrössen. Das Recovery Time Objective (RTO) beschreibt die angestrebte Zeit bis zur Wiederherstellung eines Dienstes. Das Recovery Point Objective (RPO) beschreibt, auf welchen Datenstand zurückgegangen werden darf. Beides sind Zielwerte für Planung und Tests, keine Garantie. Ein pauschales RTO für die gesamte Firma hilft wenig, wenn Lohnlauf, Telefonie, Produktion und Archiv unterschiedliche Anforderungen haben.
NIST empfiehlt, organisatorische Ressourcen zu identifizieren und zu priorisieren, damit Recovery-Pläne und Tests realistisch aufgebaut werden können. Für ein KMU bedeutet das: Die Geschäftsleitung bestimmt die Prozessprioritäten; die IT übersetzt sie in Systeme, Daten, Konten, Netzwerke und externe Abhängigkeiten.
Die Wiederanlauf-Reihenfolge
1. Eindämmung und Entscheidungsfähigkeit
Bevor Systeme wiederhergestellt werden, müssen betroffene Geräte und Netzwerkbereiche isoliert sein. Bewahren Sie relevante Protokolle und Zustandsinformationen, soweit dies die Eindämmung nicht behindert. Klären Sie zudem Verantwortlichkeiten: Wer führt den Vorfall, wer entscheidet über Betriebsunterbrüche, wer kommuniziert mit Mitarbeitenden, Kunden, Versicherer oder Behörden?
Eine Wiederherstellung ohne ausreichende Ursachenanalyse kann bereinigte Systeme erneut gefährden. Umgekehrt darf die Analyse den Betrieb nicht unbegrenzt blockieren. Der Notfallplan sollte deshalb Entscheidungspunkte und zuständige Rollen enthalten, statt im Ereignisfall absolute Gewissheit vorauszusetzen.
2. Vertrauenswürdige Administrationsbasis
Administrative Konten und Arbeitsgeräte verdienen besondere Aufmerksamkeit. Wenn Identitäten kompromittiert sein könnten, genügt das Zurückspielen eines Servers nicht. Passwörter und Schlüssel müssen kontrolliert erneuert, privilegierte Sitzungen nachvollziehbar und Notfallzugänge abgesichert werden.
Bauen Sie für die Recovery eine vertrauenswürdige Administrationsumgebung auf. Dazu gehören vertrauenswürdige Geräte, getrennte Konten und eine dokumentierte Freigabe für wiederhergestellte Systeme. Stellen Sie Systeme zunächst in einem isolierten Recovery-Netz oder -Segment wieder her. Öffnen Sie Verbindungen zur Produktionsumgebung erst, nachdem Identitäten, Konfiguration, Protokollierung und Sicherheitskontrollen geprüft wurden. So verringern Sie das Risiko, dass kompromittierte Zugänge oder unbekannte Altlasten direkt in die bereinigte Umgebung übernommen werden.
3. Kernabhängigkeiten vor Fachanwendungen
Viele Fachsysteme funktionieren erst, wenn grundlegende Dienste vorhanden sind. Dazu können Identitätsdienst, Namensauflösung, Zeitquelle, Netzwerksegmentierung, Zertifikate, Virtualisierungsplattform, Speicher und Protokollierung gehören. Die genaue Reihenfolge ist umgebungsspezifisch.
Eine reine Serverliste bildet diese Abhängigkeiten nicht ab. Ein Wiederanlaufdiagramm sollte deshalb zeigen, welcher Dienst welchen anderen Dienst benötigt. Falls eine Anwendung einen externen Cloud-Dienst, einen Lizenzserver oder einen spezialisierten Lieferanten voraussetzt, gehört auch das in den Plan.
4. Geschäftskritische Dienste in Wellen
Stellen Sie Anwendungen in definierten Wellen wieder her. Nach jeder Welle folgen technische und fachliche Prüfungen: Ist das System sauber gestartet? Stimmen Berechtigungen und Schnittstellen? Können zuständige Personen einen realen Kernprozess durchführen? Erst danach wird die nächste Gruppe freigegeben.
Ein grüner Systemstatus beweist noch nicht, dass ein Auftrag verarbeitet, eine Rechnung erstellt oder eine Maschine korrekt angesteuert werden kann. Fachverantwortliche müssen deshalb Teil der Abnahme sein.
5. Arbeitsplätze und Normalbetrieb
Endgeräte sollten erst auf wiederhergestellte Dienste zugreifen, wenn ihr eigener Zustand geklärt ist. Je nach Vorfall kann Neuinstallation verlässlicher sein als eine punktuelle Bereinigung. Danach werden Zugriffe schrittweise geöffnet und besonders wichtige Protokolle eng überwacht. Temporäre Regeln und Notlösungen müssen später bewusst zurückgebaut werden.
Backups: geeignet, erreichbar und überprüft
Ein Backup ist nicht automatisch ein sicherer Wiederherstellungspunkt. Prüfen Sie mindestens:
- Ist die Sicherung vom kompromittierten Administrationsbereich getrennt oder unveränderlich geschützt?
- Reicht die Aufbewahrung weit genug zurück, falls der Angriff vor der Verschlüsselung begann?
- Wurden Wiederherstellungen tatsächlich getestet?
- Sind Konfigurationen, Schlüssel und Abhängigkeiten ebenfalls gesichert?
- Wer kann auf die Sicherungen zugreifen, wenn die normale Identitätsplattform ausfällt?
CISA empfiehlt in seinem Ransomware-Leitfaden unter anderem offline oder anderweitig geschützte Sicherungen und regelmässige Restore-Tests. Die konkrete Architektur muss zu Ihren Datenmengen, Aufbewahrungsanforderungen und Wiederanlaufzielen passen. Backup und Recovery sollten dabei separat geplant und kalkuliert werden; Speicherplatz allein ist noch kein Wiederanlaufkonzept.
Kontrollierbare Recovery stärkt auch die digitale Souveränität. Dokumentierte Datenformate, exportierbare Konfigurationen und getestete Verfahren erleichtern einen Wiederanlauf, selbst wenn ein einzelner Anbieter oder ein Verwaltungsportal nicht verfügbar ist. Offene Formate und mehrere technisch tragfähige Wiederherstellungswege sind sinnvoll, wo sie zur Anwendung passen. Eine pauschale Multi-Cloud-Vorgabe ersetzt jedoch weder Tests noch klare Verantwortlichkeiten.
Der Test, der den Plan belastbar macht
Führen Sie mindestens Tabellenübungen mit Geschäftsleitung, IT und Fachverantwortlichen durch: Wer entscheidet, welches System zuerst kommt? Welche Kontaktdaten sind offline verfügbar? Danach sollten technische Restore-Tests ausgewählte Dienste aus einer definierten Sicherung wiederherstellen und die benötigten Schritte dokumentieren.
Nach jedem Test und Vorfall wird der Plan angepasst. CORESTREAM unterstützt Sie dabei, Abhängigkeiten sichtbar zu machen, Recovery-Prioritäten festzulegen und den Wiederanlauf nachvollziehbar zu testen. Mehr dazu finden Sie unter Sicherheit & Resilienz.