Kompromittiert: Wer entscheidet über Neuaufbau und Wiederanlauf?

Der Angriffsweg ist bekannt und technisch geschlossen. Trotzdem bleibt eine unangenehme Frage: Ist das System wieder vertrauenswürdig?

Genau vor dieser Entscheidung stand Kommunix nach einem Sicherheitsvorfall bei TEVIS-Online, einem Dienst für die Reservierung von Behördenterminen. Erste nachträglich erkannte Aktivitäten reichten bis zum 26. August 2026 zurück. Am 31. August wurde der Vorfall entdeckt und der betroffene Server vollständig abgeschaltet. Kommunix entschied sich ausdrücklich gegen eine blosse Bereinigung. Die Dienste wurden auf einer neuen Infrastruktur aufgebaut.

Das ist mehr als ein technisches Detail. Es ist eine Entscheidung über Risiko, Betriebsunterbruch und die Grenze dessen, was sich nach einem Einbruch noch zuverlässig beweisen lässt.

Ein geschlossener Angriffsweg stellt Vertrauen nicht automatisch wieder her

Eine Schwachstelle zu beheben beantwortet, wie der Angreifer eingedrungen ist. Sie beantwortet nicht abschliessend, was er während seiner Anwesenheit verändert hat. Wenn ein Angreifer auf Betriebssystemebene handeln konnte, können Konten, Konfigurationen, Protokollierung oder weitere Zugänge betroffen sein. Je länger die unerkannte Aktivität dauerte und je unvollständiger die Spuren sind, desto schwerer wird der Nachweis, dass eine Bereinigung wirklich vollständig war.

Kommunix behandelte den Server deshalb auf Betriebssystemebene als kompromittiert. Diese Einordnung führte zum Neuaufbau, zu neuen instanzbezogenen Zugangsdaten und zu einer kontrollierten, schrittweisen Wiederinbetriebnahme. Das Bundesamt für Sicherheit in der Informationstechnik nennt den Neuaufbau beziehungsweise die Neuinstallation ausdrücklich als eine Methode zur vollständigen Bereinigung nach der Analyse eines Cyberangriffs. Auch das National Institute of Standards and Technology beschreibt «Compromise Recovery» als Wiederherstellung eines sicheren oder vertrauenswürdigen Zustands, einschliesslich des Austauschs kompromittierter Schlüssel und der Verifikation des wiederhergestellten Systems. Neuaufbau ist damit kein Reflex für jeden Vorfall. Er wird notwendig, wenn der alte Zustand nicht mehr mit vertretbarer Sicherheit als vertrauenswürdig nachgewiesen werden kann.

Der CISO bewertet Vertrauen, der CIO verantwortet die Betriebswirkung

Der Chief Information Security Officer, kurz CISO, muss begründen, welche Teile der Umgebung als kompromittiert gelten, welche Unsicherheiten bleiben und welche Sicherheitsbedingungen vor einer Freigabe erfüllt sein müssen. Diese Bewertung darf nicht bei der gefundenen Schwachstelle enden. Sie umfasst auch Identitäten, Abhängigkeiten, mögliche Persistenz und die Verlässlichkeit der verfügbaren forensischen Daten.

Der Chief Information Officer, kurz CIO, trägt eine andere Verantwortung. Ein Neuaufbau verlängert möglicherweise den Ausfall, bindet Spezialisten und macht Abhängigkeiten sichtbar, die im Normalbetrieb kaum auffallen. Gleichzeitig verantwortet der CIO, dass kein vermeintlich schneller Wiederanlauf neue Unsicherheit in den Betrieb trägt. Er muss deshalb wissen, welche Dienste zuerst benötigt werden, welche Übergangslösungen tragbar sind und wo Kunden oder externe Betreiber aktiv mitwirken müssen.

Der Wiederanlauf braucht beide Urteile. Der CISO kann einen vertrauenswürdigen Zustand verlangen, aber nicht allein über sämtliche betrieblichen Folgen entscheiden. Der CIO kann die Wiederherstellung priorisieren, aber das verbleibende Sicherheitsrisiko nicht durch Termindruck aufheben.

Die Architektur entscheidet mit

Beim TEVIS-Fall begrenzte die Architektur nach Angaben von Kommunix die potenziell zugängliche Datenmenge. Reservierungsdaten lagen auf der öffentlich erreichbaren Infrastruktur nur vorübergehend. Die dauerhafte Verarbeitung erfolgte in den Backends der jeweiligen Behörden oder Rechenzentren. Später teilte Kommunix mit, dass kein Abfluss personenbezogener Daten festgestellt worden sei.

Dieselbe Trennung, die den möglichen Schaden begrenzte, machte die Wiederherstellung aufwendiger. Neue Zugangsdaten mussten pro Instanz ausgegeben und auf Kundenseite manuell hinterlegt werden. Am 2. September waren laut Kommunix nahezu 50 Prozent der betroffenen Instanzen wieder erreichbar. Sicherheit und Wiederanlauf waren damit über Hersteller, Kunden und Rechenzentren verteilt. Für CIO und CISO liegt darin eine wichtige Erkenntnis: Die Sicherheitsarchitektur bestimmt nicht nur, wie weit ein Angriff reicht. Sie bestimmt auch, wer im Ernstfall für Analyse, Zugangsdaten und Wiederinbetriebnahme gebraucht wird. Ein Recovery-Plan, der nur die eigene IT betrachtet, bleibt bei einem verteilten Dienst unvollständig.

Was vor dem nächsten Vorfall entschieden sein muss

Die Organisation sollte den Entscheid über Bereinigung oder Neuaufbau nicht erst unter Ausfalldruck erfinden. Vorab muss geklärt sein, wer einen vollständigen Neuaufbau anordnen darf und welche fachlichen Kriterien diesen Entscheid tragen. Ebenso wichtig ist der Gegenentscheid: Wer bestätigt den wiederhergestellten vertrauenswürdigen Zustand und auf welche Nachweise stützt sich diese Freigabe?

Dazu gehören ein abgegrenzter Umfang des Vorfalls, ein geschlossener Angriffsweg, neu aufgebaute oder verlässlich geprüfte Systemkomponenten, erneuerte betroffene Identitäten und eine funktionierende Überwachung beim Wiederanlauf. Wo der Nachweis Lücken enthält, braucht es eine bewusste Risikoentscheidung der zuständigen Führung. Ein grüner Systemstatus allein genügt nicht. Der TEVIS-Fall zeigt keinen universellen Königsweg. Er zeigt etwas Nützlicheres: Ein kompromittiertes System darf erst dann zurückkehren, wenn CIO und CISO dieselbe Frage belastbar beantworten können. Warum vertrauen wir diesem Zustand wieder?

Quellen

• Kommunix: Informationssicherheitsvorfall bei TEVIS-Online
• Kommune21: Informationssicherheitsvorfall bei TEVIS-Online
• BSI: Leitfaden zur Reaktion auf IT-Sicherheitsvorfälle
• NIST: Compromise recovery