Es ist schon faszinierend, was eine kritische Sicherheitslücke mit manchen Unternehmen macht. Da kommt PHP2Shell um die Ecke, eine kritische Schwachstelle in PHP, und plötzlich scheint die halbe IT-Welt vergessen zu haben, wie man eigentlich IT betreibt. Webseiten werden abgeschaltet, Krisenmeetings einberufen, Excel-Listen erstellt und Verantwortlichkeiten geklärt. Irgendwo sitzt ein CISO und muss erst einmal herausfinden lassen, wo dieses PHP überhaupt überall läuft. Und wenn die betroffenen Systeme endlich identifiziert sind, beginnt die nächste große Herausforderung: Wer traut sich eigentlich, die Dinger wieder einzuschalten?

Versteht mich nicht falsch: Eine kritische Sicherheitslücke ist kein Spaß. Wenn Angreifer im schlimmsten Fall ohne Authentifizierung eigenen Code auf einem System ausführen können, dann ist eine Abschaltung durchaus eine legitime Maßnahme. Lieber eine Webseite vorübergehend offline nehmen, als anschließend erklären zu müssen, warum jemand den Server übernommen hat. Aber zwischen einer vernünftigen Sicherheitsentscheidung und organisierter Handlungsunfähigkeit liegt ein verdammt großer Unterschied. Und genau den sollten wir vielleicht einmal diskutieren. Der Patch ist seit mehr als 8 STUNDEN draußen und viele Services sind nach wie vor offline… Ich nenne das: Peinlichkeit hoch 10…

Was mich dabei besonders irritiert, ist nicht die Abschaltung selbst. Es ist das, was danach passiert. Der Patch ist verfügbar, die Systeme sind aktualisiert, die notwendigen Prüfungen können durchgeführt werden. Und trotzdem bleiben Webseiten offline. Nicht unbedingt, weil es noch konkrete technische Bedenken gibt, sondern weil sich niemand so richtig traut, die Verantwortung für die Freigabe zu übernehmen. Man könnte ja etwas übersehen haben. Vielleicht kommt morgen noch eine neue Meldung. Vielleicht fragt irgendwann jemand, wer denn bitte die Entscheidung getroffen hat, den Dienst wieder online zu nehmen. Also bleibt die Webseite lieber aus. Sicher ist sicher. Nur für wen eigentlich? Für den Kunden, der den Dienst nicht nutzen kann? Für das Unternehmen, das möglicherweise Umsatz verliert? Oder für den Manager, der sich jetzt zumindest nicht vorwerfen lassen muss, eine falsche Entscheidung getroffen zu haben?

Ich hatte meine Webservices um 16:05 Uhr wieder online. Der Patch kam um 16:00 Uhr. Fünf Minuten später lief die Geschichte wieder. Und bevor jetzt jemand glaubt, ich würde mir hier selbst auf die Schulter klopfen: Nein. Ich bin nicht schlauer als andere, ich habe keine magischen Fähigkeiten und meine Infrastruktur ist auch nicht mit der eines internationalen Konzerns vergleichbar. Ich bin schlicht zu faul, bei jedem Problem wieder von vorne anzufangen. Ich möchte wissen, was ich betreibe, wo ich ansetzen muss und wie ich meine Systeme wieder sauber in Betrieb bekomme. Und wenn sich etwas wiederholt, automatisiere ich es. Faulheit ist schließlich die Mutter der Automatisierung.

Natürlich kann man einen privaten Webserver nicht mit einer komplexen Unternehmensumgebung vergleichen. In großen Umgebungen gibt es Abhängigkeiten, Freigabeprozesse, regulatorische Anforderungen und Anwendungen, bei denen ein Update eben nicht einfach mit einem Paketmanager erledigt ist. Das ist mir durchaus bewusst. Aber genau deshalb haben Unternehmen ganze Abteilungen, spezialisierte Dienstleister und Budgets, von denen andere nur träumen können. Da sollte man doch erwarten dürfen, dass zumindest bekannt ist, welche Systeme betroffen sind, wer für sie verantwortlich ist und wie man sie nach einer Sicherheitsmaßnahme wieder kontrolliert in Betrieb nimmt. Und ein Update von php8 auf php8 ist auch kein “breaking change” – das ist “Pillepalle”… Niemand erwartet, dass ein Großkonzern seine komplette Infrastruktur innerhalb von fünf Minuten patcht. Aber wenn er erst stundenlang oder sogar tagelang Excel-Listen herumreichen muss, um herauszufinden, welche Systeme überhaupt PHP verwenden, dann haben wir möglicherweise ein ganz anderes Problem als PHP2Shell.

Und damit sind wir bei einer Frage, die mich tatsächlich interessiert: Wie handlungsfähig sind manche Unternehmen im Jahr 2026 eigentlich noch? Wir sprechen über künstliche Intelligenz, autonome Infrastruktur, Infrastructure as Code und vollautomatisierte Deployment-Pipelines. Wir verkaufen Kunden digitale Transformation und erklären ihnen, wie wichtig Agilität und Resilienz sind. Aber wenn eine kritische Sicherheitslücke auftaucht, besteht die erste Reaktion mitunter darin, eine Excel-Datei anzulegen und einen Termin für den Krisenstab zu suchen. Das ist ungefähr so, als würde ich mir ein autonomes Fahrzeug kaufen und bei jeder roten Ampel erst einmal eine Vorstandssitzung einberufen, um zu klären, wer jetzt auf die Bremse treten darf.

Vielleicht liegt das Problem auch darin, dass wir Sicherheit zu häufig mit dem Vermeiden von Entscheidungen verwechseln. Wenn niemand weiß, welche Systeme betroffen sind, ist das ein Problem des Asset Managements. Wenn Patches nicht kontrolliert ausgerollt werden können, ist das ein Problem der Betriebsprozesse. Und wenn eine technisch begründete Freigabe nicht erfolgt, weil niemand die Verantwortung übernehmen möchte, dann sollte man vielleicht einmal die eigene Führungskultur hinterfragen. Das sind keine Vorwürfe an einzelne Mitarbeiter, die unter schwierigen Bedingungen ihren Job machen. Es sind Fragen an die Organisationen, die diese Bedingungen geschaffen haben.

Ich will auch gar nicht behaupten, dass meine fünf Minuten irgendein allgemeingültiger Maßstab wären. Wenn ein System kompromittiert sein könnte, reicht ein Patch allein natürlich nicht aus. Dann muss untersucht werden, ob bereits jemand drin war. Abhängig von der Umgebung können weitere Prüfungen, Wiederherstellungsmaßnahmen und Freigaben erforderlich sein. Sicherheit bedeutet eben nicht, möglichst schnell wieder online zu sein, sondern vertretbar sicher online zu sein. Aber genau dafür braucht man Prozesse, die vorher definiert und getestet wurden. Wer erst im Ernstfall darüber nachdenkt, wie er mit dem Ernstfall umgehen soll, hat seine Hausaufgaben schlicht nicht gemacht. Und keiner kann mir in 2026 erzählen, dass man mehr als 60min braucht um seine Systeme auf Breaches zu prüfen – Leute – das können wir doch besser…

Und vielleicht sollten wir genau darüber mehr sprechen, anstatt nach jeder Sicherheitslücke hektisch neue Tools zu kaufen. Ein Dashboard, das mir zeigt, dass ein Server verwundbar ist, ist nett. Ein vollständiges Inventar, eine automatisierte Bewertung betroffener Systeme und ein funktionierender Prozess zur kontrollierten Aktualisierung sind deutlich wertvoller. Die eigentliche Leistung besteht nicht darin, eine Sicherheitslücke zu erkennen. Das schaffen inzwischen ziemlich viele Produkte. Die Leistung besteht darin, aus dieser Erkenntnis eine konkrete Handlung zu machen, ohne dass dafür erst die halbe Organisation aus ihrem Dornröschenschlaf geweckt werden muss. Und wenn ich das als Einzelperson für meine durchaus beachtliche Infrastruktur hinbekomme, sollte ein Unternehmen mit einem IT-Budget im Millionenbereich zumindest in der Lage sein, einen vernünftigen Prozess dafür aufzubauen. Vielleicht nicht in fünf Minuten. Aber bitte auch nicht erst dann, wenn die Excel-Liste zum dritten Mal korrigiert wurde und der nächste Jour fixe ansteht.

Denn wenn wir 2026 immer noch nicht wissen, was wir betreiben, wer dafür verantwortlich ist und wie wir es nach einer Sicherheitsmaßnahme wieder sicher in Betrieb nehmen, dann ist PHP2Shell vielleicht nicht unser größtes Problem. Es ist nur das Problem, das uns gerade dabei erwischt, wie schlecht wir organisiert sind.

Euer Netzwerkonkel.