Warum Wiederherstellung allein im Ernstfall nicht reicht
„Wir haben eine funktionierende Backup-Strategie.“ Dieser Satz klingt beruhigend, bis der Ernstfall eintritt. Dann zeigt sich meist sehr schnell: Ein Backup ist unerlässlich, ersetzt aber keinen Incident-Response-Plan.
In einem Ransomware-Fall bei einem Industrieunternehmen mit rund 2.000 Mitarbeitenden wurde genau diese Annahme zum Problem. Das Unternehmen war durch NIS-2 und DSGVO-Anforderungen reguliert, die internen Abläufe waren stark von IT-gestützten Produktions-, Logistik- und Verwaltungsprozessen abhängig. Der Security-Reifegrad schien zum Vorfallszeitpunkt in einem Punkt belastbar: Es gab dokumentierte Backup-Prozesse, definierte Wiederherstellungspunkte und die Erwartung, im Notfall auf gesicherte Datenstände zurückgreifen zu können.
Doch während des Vorfalls zeigte sich: Die Angreifer hatten sich bereits Wochen vor der eigentlichen Verschlüsselung Zugriff auf die Backup-Infrastruktur verschafft. Sie deaktivierten Jobs, löschten Wiederherstellungspunkte und manipulierten Sicherungen. Das System, das im Krisenfall Sicherheit geben sollte, war selbst Teil des Angriffs.
Bei einem Ransomware-Angriff geht es nicht nur darum, Daten wiederherzustellen. Es geht darum, in einer hoch dynamischen Krisensituation handlungsfähig zu bleiben. Systeme fallen aus, Mitarbeitende können nicht arbeiten, Kunden fordern Auskunft. Die Geschäftsführung benötigt Entscheidungsgrundlagen, während die IT nach der Ursache sucht. Datenschutz, Rechtsabteilung und Versicherung verlangen belastbare Informationen. Gleichzeitig ist unklar, ob sich die Angreifer noch im Netzwerk befinden. Ein Backup kann Daten zurückbringen, aber es führt kein Unternehmen durch eine Cyberkrise.
Was im Ernstfall wirklich passiert
Ein Cybervorfall beginnt selten geordnet. In einem Industrieumfeld kann das erste sichtbare Zeichen eine verschlüsselte Datei sein, ein nicht erreichbarer Server, ein abgebrochener Auftrag im ERP-System oder eine Produktionsplanung, die sich nicht mehr öffnen lässt. Kurz darauf erscheinen Erpressernachrichten auf mehreren Systemen. Die Fachbereiche rufen bei der IT an: Produktion, Vertrieb, Buchhaltung oder Logistik fragen, ob der Betrieb fortgesetzt werden kann.
Parallel versucht das IT-Team, die Lage einzuordnen:
• Welche Systeme sind betroffen?
• Muss das Netzwerk segmentiert oder getrennt werden?
• Sind die Backups noch vertrauenswürdig?
• Sind Daten abgeflossen?
• Welche Konten sind kompromittiert?
• Wer trifft welche Stilllegungs- oder Freigabeentscheidungen?
• Wer informiert Mitarbeitende, Kunden, Behörden und Versicherer?
In dieser Phase entsteht massiver operativer Druck. Jede Entscheidung hat unmittelbare Konsequenzen. Zu langes Zögern kann die Ausbreitung des Angriffs verschärfen. Übereiltes Wiederherstellen kann dazu führen, dass die Angreifer erneut Zugriff erhalten. Genau deshalb reicht ein Backup allein nicht aus: Es beantwortet keine dieser Fragen.
Der gefährliche Reflex: „Einfach zurückspielen“
Viele Unternehmen wollen im Notfall vor allem eines: so schnell wie möglich wieder arbeitsfähig werden. Das ist nachvollziehbar – und gleichzeitig riskant. Wer Systeme wiederherstellt, bevor klar ist, wie der Angriff ablief, lässt im Zweifel genau die Tür offen, durch die der Angreifer eingedrungen ist. Vielleicht wurden Admin-Zugangsdaten gestohlen. Vielleicht existiert eine Hintertür. Vielleicht wurde ein VPN-Zugang kompromittiert. Vielleicht ist das Backup selbst betroffen. Dann ist Recovery keine Lösung, sondern der Start des nächsten Vorfalls.
Professionelle Incident Response bedeutet deshalb nicht: sofort alles zurückspielen. Sie bedeutet: verstehen, eindämmen, sichern, priorisieren, wiederherstellen und überwachen. Erst wenn klar ist, welche Systeme betroffen sind, welche Konten gesperrt werden müssen und ob der Angreifer entfernt wurde, kann der Betrieb kontrolliert wieder hochgefahren werden.
Das Backup war vorhanden – aber nicht nutzbar
Im beschriebenen Fall war die Ausgangslage zunächst scheinbar komfortabel: Das Industrieunternehmen verfügte über dokumentierte Backup-Prozesse, definierte Wiederherstellungspunkte, das gute Gefühl, im Ernstfall abgesichert zu sein.
Erst während der Wiederherstellung stellte sich heraus, dass die Angreifer bereits Wochen zuvor Zugriff auf die Backup-Infrastruktur erlangt hatten. Backup-Jobs waren deaktiviert, Wiederherstellungspunkte gelöscht und Teile der Sicherungen manipuliert worden. Die vermeintliche Sicherheitsreserve existierte faktisch nicht mehr.
Ein Beteiligter brachte es später sinngemäß auf den Punkt:
„Das Sicherste, was wir hatten, gehörte drei Wochen vor uns schon dem Angreifer.“
Ab diesem Moment war der Vorfall keine IT-Störung mehr, sondern eine Managementkrise. Die Geschäftsführung musste unter hohem Zeitdruck entscheiden: Wird über Lösegeld überhaupt gesprochen? Welche Systeme werden komplett neu aufgebaut? Welche Prozesse laufen manuell weiter, damit Produktion, Logistik, Einkauf, Kundenservice und Rechnungsstellung nicht vollständig zum Erliegen kommen? Welche Kunden, Partner, Behörden und Versicherer müssen wann informiert werden? Und welche Entscheidungen sind vor dem Hintergrund von NIS2, DSGVO und möglicher Haftung belastbar dokumentiert?
Für das Unternehmen bedeutete das: Der geplante Wiederanlauf funktionierte nicht. Systeme konnten nicht wie vorgesehen zurückgesetzt werden. Die IT musste parallel herausfinden, welche Sicherungen überhaupt noch vertrauenswürdig waren. In den betroffenen Bereichen entstand ein Stillstand über mehrere Tage. Einzelne Datenstände waren nicht mehr vollständig rekonstruierbar und der wirtschaftliche Schaden ging weit über die reinen IT-Kosten hinaus: Produktionsunterbrechung, externe Incident-Response, Neuaufbau, Nacharbeit, Kommunikationsaufwand und verzögerte Lieferfähigkeit belasteten das Unternehmen zusätzlich.
Die Lehre ist eindeutig: Backups schützen nur dann, wenn sie vom Produktivnetz getrennt, unveränderbar gespeichert und regelmäßig getestet werden. Besonders bewährt haben sich Offline-Backups oder logisch getrennte Cloud-Backups mit Immutable-Storage-beziehungsweise Write-Once-Read-Many-Funktionalität. Entscheidend ist aber nicht nur die Technologie, sondern der Nachweis, dass die Wiederherstellung im Ernstfall wirklich funktioniert. Ein Backup, das nie getestet wurde, ist keine Sicherheit. Es ist eine Hoffnung.
Forensik: Erst verstehen, dann wieder hochfahren
Im Incident braucht das Unternehmen schnell ein belastbares Lagebild. Gerade bei einem Unternehmen mit industriellen Abläufen reicht es nicht, einzelne Systeme isoliert zu betrachten. Es muss klar sein, welche IT-, Produktions- und Geschäftsprozesse voneinander abhängen und wo ein Wiederanlauf neue Risiken erzeugen würde.
Die Forensik klärt unter anderem:
• wie die Angreifer eingedrungen sind
• welche Systeme betroffen sind
• ob Daten abgeflossen sind
• welche Konten kompromittiert wurden
• ob Backups manipuliert wurden
• ob sich der Angreifer noch im Netzwerkbewegt
• welche Systeme sicher wieder gestartet werden können
Ohne diese Analyse bleibt vieles Spekulation. Und Spekulation ist im Cybernotfall gefährlich.
Denn falsche Annahmen führen zu falschen Entscheidungen: Systeme werden zu früh aktiviert, Beweise gehen verloren, Meldepflichten werden falsch bewertet oder kompromittierte Zugänge bleiben bestehen. In einem NIS2- und DSGVO-relevanten Umfeld kann das nicht nur operative Folgen haben, sondern auch Governance-, Melde- und Haftungsfragen verschärfen.
Kommunikation: Der zweite Krisenherd
Während die IT analysiert, wächst an anderer Stelle der Druck. Mitarbeitende wollen wissen, ob sie ihre Systeme nutzen dürfen. Kunden fragen, ob Liefertermine, Services oder Datenbetroffen sind. Partner wollen wissen, ob Schnittstellen sicher sind. Die Geschäftsführung braucht entscheidungsfähige Informationen. Datenschutz, Rechtsabteilung und Versicherung benötigen belastbare Fakten. Wenn es dafür keinen vorbereiteten Kommunikationsplan gibt, entsteht Chaos – zusätzlich zum technischen Notfall.
Hinzu kommt der regulatorische Takt. Wer unter NIS2 fällt, muss einen erheblichen Sicherheitsvorfall innerhalb von 24 Stunden als Frühwarnung, nach 72 Stunden als Meldung und nach einem Monat als Abschlussbericht an das BSI übermitteln. Die DSGVO verlangt bei meldepflichtigen Datenschutzverletzungen eine Meldung binnen 72 Stunden. Diese Fristen laufen, während die IT noch mitten im Krisenmodus steckt. Wer erst dann beginnt, Zuständigkeiten und Meldewege zu klären, verliert wertvolle Zeit – und Handlungsspielraum.
Ein Incident-Response-Plan legt deshalb fest:
• wer intern informiert
• wer externe Aussagen freigibt
• wer mit Kunden, Behörden und Versicherern spricht
• welche Kommunikationswege genutzt werden, wenn E-Mail ausfällt
• welche Informationen zu welchem Zeitpunkt kommuniziert werden dürfen
Gute Kommunikation löst den Angriff nicht, aber sie verhindert, dass aus einem technischen Vorfall zusätzlich eine Vertrauenskrise wird. Genau hier zeigt sich der Unterschied zwischen Backup-Strategie und Incident-Response-Fähigkeit: Das eine betrifft Daten. Das andere betrifft Führungsfähigkeit.
Betrieb: Was muss zuerst wieder laufen?
Im Ernstfall ist nicht jedes System gleich wichtig. Die operative Frage lautet nicht: Was können wir zuerst wiederherstellen? Sondern: Was braucht das Unternehmen zuerst, um handlungsfähig zu bleiben?
In der Industrie kann das die Produktionsplanung sein, die Auftragsabwicklung, die Warenwirtschaft, die Logistik, der Kundenservice oder ein zentrales Identitäts- und Berechtigungssystem. Wenn Backups nicht nutzbar sind, verschiebt sich die Frage zusätzlich: Welche Prozesse können manuell fortgeführt werden, welche müssen bewusst gestoppt werden und welche Systeme werden neu aufgebaut statt riskant wiederhergestellt?
Ein Incident-Response-Plan definiert aus diesem Grund vorab auch:
• kritische Geschäftsprozesse
• priorisierte Systeme
• maximale Ausfallzeiten
• manuelle Notprozesse
• Freigaben für den Wiederanlauf
• Verantwortlichkeiten im Krisenstab
Denn Wiederherstellung ist keine rein technische Aufgabe. Sie ist eine operative Managemententscheidung.
Backup ist Pflicht. Incident Response ist Überlebensfähigkeit.
Backups sind unverzichtbar. Aber sie sind nur ein Baustein. Im echten Cybernotfall braucht ein Unternehmen mehr: klare Rollen, schnelle Entscheidungen, forensische Analyse, Krisenkommunikation, rechtliche Bewertung, getestete Wiederherstellungsprozesse und einen kontrollierten Wiederanlauf.
Der Fall zeigt besonders deutlich: Die Frage lautet nicht nur, ob ein Backup vorhanden ist. Die Fragelautet, ob das Unternehmen weiß, was zu tun ist, wenn genau dieses Backup nicht mehr vertrauenswürdig ist. Wer entscheidet über Lösegeld, Neuaufbau und manuelle Notprozesse? Wer bewertet Datenverlust und Meldepflichten? Wer dokumentiert Entscheidungen für Geschäftsführung, Aufsicht, Datenschutz, Versicherung und Kunden?
Wenn diese Antworten nicht belastbar sind, reicht kein Backup-Konzept. Dann braucht es einen echten Incident-Response-Plan.
Verlassen Sie sich noch auf Ihr Backup – oder ist Ihr Unternehmen wirklich vorbereitet?
Mit dem Argos Cyber Resilience Check prüfen wir Ihre Incident-Response-Bereitschaft praxisnah: Wo liegen die größten Schwachstellen? Welche Maßnahmen bringen den größten Sicherheitsgewinn? Welche Notfallprozesse funktionieren auch dann, wenn die vermeintliche Sicherheitsreserve wegfällt?
Jetzt Cyber Resilience Check mit Argos Security anfragen.
