Versiegeln können wir, öffnen nicht
Notfallpläne liegen meist in genau dem System, das im Ernstfall weg ist. Unser neues Notfallsystem geht deshalb von einer unbequemen Annahme aus: Im Ernstfall ist die Plattform selbst die kompromittierte Seite.
Die meisten Notfallpläne teilen ein Schicksal. Sie sind sorgfältig geschrieben, regelmäßig geprüft, sauber verlinkt, und sie liegen in dem System, das im Ernstfall gerade verschlüsselt wurde.
Für diesen Fall haben wir ein eigenes Modul gebaut. Es erzeugt aus dem vorhandenen Bestand ein verschlüsseltes, signiertes Notfallpaket mit eigenem Offline-Viewer und legt es auf Notfall-Notebooks. Der Krisenstab kommt damit ohne Netz und ohne Server an Wiederanlaufpläne, an die BIA mit RTO und RPO, an Sicherungspläne samt Lagerort, an Asset-, Rack- und Netzinventar, an Erreichbarkeiten und an die freigegebenen Dokumente.
Interessant ist daran weniger, was drin ist. Interessant ist, wovon das Modul ausgeht.
Das Bedrohungsmodell schließt uns ein
Im Datenmodell steht der Satz, der alles Weitere bestimmt: Im Ernstfall ist die Plattform die kompromittierte Seite. Wer mit einem Ransomware-Vorfall rechnet, muss auch damit rechnen, dass das ISMS selbst betroffen ist. Läge im Server ein wiederherstellbares Geheimnis, hätte ein Angreifer mit Datenbankzugriff nicht nur ein Notfallpaket, sondern jedes.
Also gibt es dort keines. Die Plattform kennt nur den öffentlichen Teil des Schlüssels. Der private entsteht genau einmal, in der Antwort auf die erzeugende Anfrage, und wird serverseitig sofort überschrieben. Danach existiert er nur noch auf Papier, im Tresor.
Das Ergebnis ist eine Fähigkeit, die man selten so formuliert sieht: Wir können Pakete versiegeln und keines davon öffnen.
Was bewusst nicht im Paket steht
Zugangsdaten. Keine Passwörter, keine Schlüssel, keine Token. Stattdessen steht dort ihr Fundort, in der Form, in der ihn ein Mensch um drei Uhr nachts gebrauchen kann: welcher Umschlag, welcher Tresor, welcher Raum, welche Person.
Das ist keine technische Lücke, sondern eine Grenze. Ein Notfallpaket, das Zugangsdaten enthält, ist ein Beutestück. Eines, das nur ihren Verwahrort nennt, ist es nicht.
Der Test, der wirklich etwas beweist
Das Modul unterscheidet drei Arten von Nachweis, und der Unterschied ist der Kern.
Die Signaturprüfung zeigt, dass eine Datei existiert, gültig signiert ist und ihre Prüfsumme stimmt. Mehr nicht. Der Öffnungstest zeigt, dass sich das Paket tatsächlich entsiegeln lässt. Und die Übung zeigt, dass Menschen es unter Zeitdruck schaffen.
Nur der zweite findet den Fall, der wirklich wehtut. Nach einem Mainboard-Tausch oder einem zurückgesetzten TPM ist die Datei tadellos, die Signatur gültig, die Prüfsumme korrekt, und der Geräteschlüssel ist weg. Eine reine Dateiprüfung meldet an dieser Stelle grün.
Deshalb führt das Modul die gemessene Öffnungszeit als eigene Kennzahl. Sie ist die einzige Zahl, die etwas über den Ernstfall aussagt, und erfahrungsgemäß die, nach der ein Prüfer fragt.
Grün heißt nicht einsatzbereit
Dieselbe Unterscheidung gilt für die Notfall-Notebooks. Auf designierten Geräten liegt nicht nur der tragbare Auszug, sondern ein vollständiges Instanzabbild, aus dem nach der Krise wieder eine Produktivinstanz werden kann.
Bis vor Kurzem wusste die Plattform davon nur, ob das Paket frisch war. Ob auf dem Gerät überhaupt eine Container-Laufzeit steckt und der Stapel jemals hochgekommen ist, stand nirgends. Ein Knoten konnte monatelang grün aussehen und im Ernstfall nichts weiter sein als ein Notebook mit einer verschlüsselten Datei darauf. Diese Lücke ist inzwischen geschlossen.
Die Ampel misst übrigens das Alter des Datenstands, nicht den letzten Agentenkontakt. Ein Notfall-Notebook im Tresor ist wochenlang offline, und das ist genau der gewollte Zustand.
Mehr auf der Modulseite Notfallsystem.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.