PHP2Shell: Wer seine Angriffsfläche nicht kennt, verliert Zeit. Und Geld.

Wer mich kennt, weiß, dass ich nun wirklich nicht aufdringlich bin. Das bedeutet aber nicht, dass ich meine Ansichten, Meinungen und klare Empfehlungen nicht äußere. Wenn ich Verbesserungspotenzial sehe, spreche ich das an – klar und wenn erforderlich auch sehr deutlich. Reite ich anschließend darauf rum? Nein.

Die aktuelle Lage – und da nehme ich in diesem Beitrag PHP2Shell als Beispiel – veranlasst mich aber dazu, klar Stellung zu beziehen. Stellung zu einem Thema, welches uns und besonders mich schon länger beschäftigt und noch lange beschäftigen wird. PHP2Shell zeigt mal wieder, wie dynamisch, schnell und herausfordernd unsere Zeit ist. Und PHP2Shell ist lediglich das aktuell prominenteste Beispiel einer kritischen Sicherheitslücke. Zeitgleich wurden auch andere teils hoch kritische Schwachstellen bekannt. Aber wie gehen wir eigentlich damit um?

• Kenne ich meine Angriffsflächen?
• Habe ich Systemverantwortliche definiert?

Das ist kein Wasser auf alte Mühlen oder Angstmache. Das ist Realität. Realität, der wir uns stellen müssen.

Ich bin mir sicher: Wir müssen uns darauf einstellen, dass Schwachstellen und Bedrohungen zunehmen werden. Sie werden mittlerweile durch KI immer schneller erkannt und eine Ausnutzbarkeit publiziert.

Sind wir als „Verteidiger“ durch KI mittlerweile auch schneller? In der Regel leider nicht. Umso wichtiger ist es, vorbereitet zu sein.

Doch nun zurück zur PHP2Shell:

„Sind wir eigentlich betroffen?“

Diese Frage dürfte in den vergangenen Tagen in vielen Organisationen gestellt worden sein. Provider, Dienstleister, Kunden. Allesamt haben sich hoffentlich diese Frage gestellt. Anlass sind die beiden kritischen PHP-Sicherheitslücken, bekannt unter dem Namen PHP2Shell.

Und genau hier beginnt aus meiner Sicht ein großes Problem.

Denn während einige Unternehmen bereits wissen, welche Systeme betroffen sind und welche Maßnahmen erforderlich sind, beginnt bei anderen erst einmal die Suche.

• Wo setzen wir eigentlich PHP ein?
• Welche Versionen laufen?
• Welche Systeme sind aus dem Internet erreichbar?
• Und wer ist überhaupt dafür verantwortlich?

Fragen, auf die es eigentlich jederzeit eine Antwort geben sollte. Nicht erst dann, wenn eine kritische Sicherheitslücke bekannt wird.

Was ich nicht kenne, kann ich auch nicht schützen

Die IT-Infrastrukturen vieler Unternehmen sind über Jahre gewachsen. Neue Systeme kommen hinzu, Cloud-Dienste werden eingeführt, Anwendungen von externen Dienstleistern betrieben und alte Systeme geraten irgendwann in Vergessenheit.

Das Ergebnis? Häufig fehlt ein vollständiger und aktueller Überblick über die eigene Infrastruktur.

Besonders kritisch sehe ich dabei die extern erreichbaren Assets. Webanwendungen, VPN-Zugänge, Managementschnittstellen, Portale oder längst vergessene Testsysteme. Alles potenzielle Angriffsflächen, die möglicherweise auch Angreifer entdecken können.

Und genau deshalb halte ich ein professionelles Attack Surface Management (ASM) heute für unverzichtbar.

Es geht darum, die eigene Angriffsfläche kontinuierlich zu erkennen, zu bewerten und möglichst zu reduzieren. Nicht einmal im Jahr durch einen Scan, sondern dauerhaft.

Schwachstellenmanagement darf nicht erst bei einer Sicherheitswarnung beginnen

Attack Surface Management und Schwachstellenmanagement gehören für mich untrennbar zusammen.

Denn zu wissen, welche Systeme existieren, ist nur der erste Schritt. Ich muss auch wissen, welche Schwachstellen vorhanden sind, wie kritisch diese sind und welche Auswirkungen eine mögliche Ausnutzung hätte.

Dabei sollten extern erreichbare Systeme aufgrund ihrer Exposition besonders im Fokus stehen. Aber auch interne Systeme dürfen wir nicht vergessen. Schließlich können Schwachstellen innerhalb eines Netzwerks die weitere Ausbreitung eines Angreifers ermöglichen.

Ohne Transparenz fehlt die Grundlage für jede sinnvolle Priorisierung

Wer im Ernstfall erst mühsam Systeme identifizieren, Verantwortlichkeiten klären und Softwareversionen recherchieren muss, verliert wertvolle Zeit. Zeit, die eigentlich für die Bewertung, Absicherung und Behebung von Schwachstellen gebraucht wird.

Natürlich braucht es dafür geeignete Technologien. Aber mindestens genauso wichtig sind klare Zuständigkeiten, definierte Prozesse und eine kontinuierliche Bewertung der Ergebnisse.

Ein Tool oder Technologie allein löst das Problem nicht. Aber sie ist unweigerlich Bestandteil und muss auch sinnvoll eingesetzt und betrieben werden.

Wenn fehlende Transparenz zum Kostenfaktor wird

Was bei der aktuellen PHP2Shell-Sicherheitslücke ebenfalls sehr deutlich wird, ist die Herausforderung für IT-Dienstleister und Partner wie uns.

Und das möchte ich ausdrücklich aus unserer Perspektive ansprechen.

Wenn innerhalb kürzester Zeit zahlreiche Kunden wissen möchten, ob ihre Systeme betroffen sind, beginnt eine enorme organisatorische und technische Herausforderung. Sicherheitsmeldungen müssen bewertet, betroffene Produkte identifiziert, Herstellerinformationen geprüft und konkrete Maßnahmen abgestimmt werden. Und im Beispiel von PHP sprechen wir nicht von einem konkreten Produkt, welches betroffen ist. PHP ist in unzähligen Applikationen und Systemen in Verwendung.

Besonders aufwendig wird es dann, wenn Kunden weder über eine vollständige Inventarisierung noch über geeignete Lösungen für Attack Surface Management und Schwachstellenmanagement verfügen. Dann wird aus einer gezielten Sicherheitsprüfung schnell eine zeitintensive Suche nach unbekannten Systemen und potenziellen Schwachstellen.

Und das nicht nur bei einem Kunden, sondern möglicherweise bei vielen gleichzeitig. Hinzu kommt, dass die erforderlichen Prüfungen häufig manuell durchgeführt werden müssen, weil schlichtweg die technischen Grundlagen für eine automatisierte und effektive Bewertung fehlen. Das bindet enorme personelle Ressourcen. Beim IT-Dienstleister genauso wie beim Kunden. Und natürlich verursacht dieser Aufwand Kosten.

An dieser Stelle würde ich mir wünschen, dass Unternehmen einmal eine andere Rechnung aufmachen.

Was kostet uns eigentlich die nächste kritische Sicherheitslücke, wenn wir wieder bei null anfangen müssen?

Wie viele Stunden investieren interne IT-Abteilungen und externe Dienstleister in Bestandsaufnahmen, manuelle Prüfungen, Abstimmungen und Bewertungen? Und wie oft wiederholt sich dieser Aufwand im Laufe eines Jahres?

Stellt man diese wiederkehrenden Aufwände den Investitionen in geeignete Technologien und etablierte Prozesse gegenüber, könnte die wirtschaftliche Betrachtung plötzlich ganz anders aussehen.

Natürlich verursachen auch professionelle Security-Lösungen Kosten. Für Lizenzen, Einführung, Pflege und Betrieb. Und nicht für jede Organisation ist dieselbe Lösung sinnvoll.

Aber genau deshalb sollte man diese Investitionen nicht ausschließlich als zusätzliche IT-Ausgaben betrachten, sondern auch den möglichen Nutzen durch schnellere Reaktionszeiten, weniger manuelle Arbeit und bessere Risikotransparenz berücksichtigen.

Vielleicht ist es langfristig teurer, keine geeignete Lösung zu haben, als in eine solche zu investieren.

Mein Fazit: Transparenz ist keine Kür, sondern eine Voraussetzung für IT-Sicherheit

PHP2Shell ist für mich ein weiteres Beispiel dafür, wie wichtig es ist, die eigene IT-Infrastruktur wirklich zu kennen.

Als IT-Security-Spezialisten beschäftigen wir uns täglich mit solchen Herausforderungen. Wir kennen die Technologien, die Anforderungen und auch die Schwierigkeiten, die in gewachsenen IT-Infrastrukturen entstehen.

Wir wissen aber auch, dass nicht jedes Unternehmen dieselben Voraussetzungen mitbringt und dass nicht jede Herausforderung mit einem weiteren Tool gelöst werden kann.

Unser Anspruch ist es deshalb nicht, einfach eine Software zu verkaufen. Wir möchten beraten, Transparenz schaffen und gemeinsam die Lösung finden, die wirklich zur jeweiligen Organisation passt. Ob eine erste Bestandsaufnahme, die kontinuierliche Überwachung externer Angriffsflächen oder der Aufbau eines professionellen Schwachstellenmanagements: Wir können helfen. Und wir möchten helfen.

Denn aus unserer Sicht sollte IT-Sicherheit nicht erst dann zum Thema werden, wenn die nächste kritische Sicherheitslücke veröffentlicht wird.

Wie gut kennen Sie Ihre eigene Angriffsfläche? Und wissen Sie, wie schnell Sie auf die nächste kritische Sicherheitslücke reagieren könnten?

Lassen Sie uns darüber sprechen.