Wisst ihr, was mich gerade wundert? Wir hatten doch gerade diesen Fall der Uniklinik, die über Citrix geownt wurde. Sie sagen, sie hätten die Patches zeitnah eingespielt. Glauben wir ihnen das mal.

Bis zu dem Zeitpunkt, wo du den Patch in der Hand hast, können Angreifer ja schon von der unterliegenden Lücke gehört und sie bei dir ausgenutzt haben. Eigentlich müsste man bei jedem Patch-Ausrollen auch gleich alle Server neu aufsetzen. Macht natürlich niemand.

Aber das ist ja auch eine kulturelle Frage.

Iteration 1 war der Mainframe. Der wurde so gut wie nie gepatcht. Das war die Generation "never touch a running system".

Iteration 2 war der Server, wie wir ihn heute kennen. "Habt ihr schon alle Patches ausgerollt?" Das ist eigentlich die falsche Frage und führt auch für alle offensichtlich in der Praxis immer wieder zu Problemen wie "keine zwei Server in unserem Hause sind auf genau demselben Patchstand" und "wir können gar nicht sagen, ob wir Untermieter auf unseren Servern haben".

Das ist doch eigentlich eine zentrale Frage, wenn man vertrauenswürdige Infrastruktur haben will. "Haben wir eine Hintertür?" Kannst du auf einem typischen System gar nicht einfach beantworten. Klar, es gibt Ansätze. Früher unter Unix gab es die Idee, dass man Prüfsummen von Systemdateien in einer Datenbank hat, und dann läuft man periodisch herum und guckt, ob die Prüfsummen noch stimmen. Das war eine Revolution damals, das erste mir bekannte Tool hieß Tripwire.

Dann gibt es natürlich einen Haufen reaktiver "Lösungen", die eine Liste von bekannten Hintertüren haben und nach denen gucken. Es ist hoffentlich offensichtlich, dass das alles Theater ist.

So und jetzt zu dem Teil, um den es mir eigentlich geht. Die nächste Iteration. Was könnte man denn machen, um das Problem auf einem fundamentalen Niveau zu lösen?

Naja, eine Backdoor ist ja eine Modifikation einer bestehenden Installation. Wenn man alle Modifikationen verbietet und verhindert, dann gibt es auch keine Backdoors mehr. Stimmt inhaltlich nicht, es gibt auch Backdoors, die auf der Platte nichts verändern und sich nur im RAM aufhalten, aber bleibt mal kurz bei mir.

OK, können wir unsere Server so umstellen, dass die read-only sind? Keine Modifikation am Systemimage? Grundsätzlich ginge das, aber man müsste dann jedesmal ein neues Image bauen, wenn es Patches gibt.

Stellt sich raus: Das kann man nicht nur machen, das kann man vollautomatisch machen! Und es ergeben sich dadurch auch andere Vorteile, nämlich dass man weiß, dass keine Benutzerdaten auf der Systemplatte liegen, die man möglicherweise ins Backup packen muss.

Iteration 3 ist also, dass auf allen Servern (kann man auch mit Client-Systemen machen!) ein unveränderliches System-Image gebootet wird, das automatisiert aus einem anderen System herausfällt. Hat auch den Vorteil, dass man kein Patchrisiko mehr hat. Wenn ein Patch nicht geht, bootet man halt wieder das Image von davor.

Kommt das jemandem bekannt vor? Das ist die zentrale Innovation von Cloud Computing. Dass das "in der Cloud" läuft ist irrelevanter Tand. Amazon hat AWS nicht für andere gebaut, sondern für sich selbst. Dass man das auch verkaufen kann ist ihnen erst danach aufgefallen.

Und das ist, was mich gerade wundert. Dass wir nicht mehr über Iteration 3 reden. Stattdessen halten wir uns mit der Frage auf, ob die den Patch schnell eingespielt haben oder nicht. Und wenn die den Patch schnell eingespielt haben, dann ... *schulterzuck* dann konnte man wohl nichts machen. Ja, äh, doch! Konnte man!

Es gibt da jetzt natürlich eine Menge Detailfragen, die das komplizierter machen als ich es jetzt hier ausgeführt habe. Konfigurations-Management und Datenhaltung sind die beiden großen Dinge. Bei Konfigurations-Management haben viele Organisationen heute schon Automatisierung, aber das ist häufig noch Iteration-2-Automatisierung, die an bestehenden Systemen herumfummelt, sowas wie Ansible oder Chef oder Puppet oder Saltstack oder wie sie alle heißen. Dass jemand tatsächlich automatisiert ein Image mit der Konfiguration eingebacken baut und verteilt, das ist immer noch eine Rarität. Warum eigentlich?

Und was ist mit der Datenhaltung? Die einfache Antwort ist: Die Daten liegen in der Datenbank und/oder dem Netzwerkspeicher (der natürlich so angebunden sein muss, dass man keine Programme von dort ausführen kann). Aber auch hier kann man gucken, ob man nicht das Prinzip der Zurückrollbarkeit anwendet, und seine Daten so ablegt, dass man nichts ändern sondern nur Änderungen am Ende anfügen kann. Wenn es dann einen Angriff gibt, kann der nicht die Daten alle verschlüsseln und mich erpressen sondern er kann nur irgendwas am Ende anfügen. Wenn ich das abschneide, hab ich den Zustand von vorher.

Das ist alles so offensichtlich und so attraktiv, dass ich mich echt frage, wieso da niemand drüber redet.

Das löst das Problem der Sicherheitslücken nicht, versteht mich da nicht falsch. Du kannst immer noch aufgehackt werden und der Angreifer kann immer noch deine Daten raustragen und auf dem Schwarzmarkt verhökern. Das ist ein separates Problem. Auch dafür gibt es übrigens gute Lösungsansätze!

Aber dass auf dieser fundamentalen Ebene die Business Continuity so wenig eine Rolle spielt, das wundert mich echt.

Auf der anderen Seite sind Menschen ja schon immer notorisch schlecht mit der Vorbereitung auf Katastrophen. Das hat ja zuletzt der Warntag gut demonstriert. Niemand nimmt an, dass der Blitz bei einem Gewitter ausgerechnet ihn treffen könnte. Vielleicht ist das auch hier die Erklärung.

Und kommen wir noch mal kurz zu der Sache mit der Backdoor rein im RAM. Nun, die ist beim nächsten Boot weg. Weil das Image immutable ist, kann sich da auch keine Backdoor eingenistet haben. Wenn also ein Citrix-Patch reinkommt und du das Bootimage für die Citrix-Server neu baust und auf die Server verteilst und reinbootest, dann sind auch automatisch alle Backdoors weg.