Rückrufaktion in der Verwaltungs-IT
Wie Behörden bei der nächsten kritischen Sicherheitslücke in kürzester Zeit reagieren können
Unter dem Namen PHP2Shell wurden zwei Lücken im Kern von PHP bekannt. PHP bildet die Grundlage eines Großteils aller Websites. Dazu gehören Content-Management-Systeme wie TYPO3 und WordPress – und damit auch viele Portale öffentlicher Stellen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gab eine Warnung der Stufe 3 [Orange] heraus und riet, Webserver notfalls vorübergehend vom Internet zu trennen, wenn sich die Updates nicht kurzfristig einspielen lassen. Mehrere Länder, Kommunen und Behörden folgten dieser Empfehlung.
Solange ein Update fehlte oder noch nicht eingespielt war, war das Abschalten konsequent. Bevor ein Portal oder eine Website wieder online gehen kann, müssen die Verantwortlichen eine Reihe von Fragen beantworten. Wo läuft PHP überall? In welcher Version? Welche Systeme sind betroffen? Wo besteht tatsächlich ein Risiko? Wer betreibt den Server, und wann darf er neu gestartet werden?
Wo diese Antworten nicht griffbereit sind, beginnt eine Suche per Rundmail, Tabelle und Telefon. Denn bevor ein Patch installiert werden kann, muss feststehen, wo er gebraucht wird.
Im Ernstfall fehlt nicht die Warnung, sondern der Überblick
PHP2Shell ist kein Einzelfall. Im Dezember 2021 rief das BSI wegen Log4Shell, einer Lücke in einer verbreiteten Java-Bibliothek, sogar die höchste Warnstufe Rot aus. Die Software war eine andere, die Fragen waren dieselben.
Zwar identifizieren Sicherheitsscanner diese Schwachstellen. Tausend Schwachstellen zu finden, schafft aber noch keine Sicherheit für Verwaltung und IT-Dienstleister im öffentlichen Sektor. Den Unterschied macht es, die tatsächlich kritischen Fälle herauszufiltern und gezielt zu beheben.
Relevante Informationsquellen müssen dazu kombiniert werden: Details zu Servern, Relevanz der Verfahren für den Dienstbetrieb oder Infos zu Wartungsfenstern. In der Verwaltung kommt hinzu, dass Verantwortung und Betrieb häufig in verschiedenen Händen liegen: Die Behörde verantwortet ihr Fachverfahren, betrieben wird es von einem Landes- oder kommunalen IT-Dienstleister. Zusammengeführt wird dieses Wissen oft erst, wenn eine Sicherheitswarnung schon da ist. Genau dort geht die Zeit verloren.
Was eine gute Werkstatt anders macht
Ein Vergleich aus dem Alltag veranschaulicht die Situation. Ein Autohersteller meldet eine fehlerhafte Bremse in einer bestimmten Baureihe und ruft die Fahrzeuge zurück. Eine Werkstatt ohne Überblick wartet, bis sich die Kunden melden, oder bestellt alle auf einmal ein. Eine gute Werkstatt schaut in ihre Kundenkartei. Schnell weiß sie, welche Autos betroffen sind, welche davon täglich auf der Autobahn unterwegs sind und welche den Winter über in der Garage stehen. Die Autobahnfahrer werden priorisiert. Die Werkstatt bestellt die Ersatzteile, plant die Hebebühnen ein und meldet dem Hersteller am Ende, welches Fahrzeug wann repariert wurde.
Übertragen auf die Verwaltungs-IT ergeben sich drei Fähigkeiten, die sich vor dem Ernstfall aufbauen lassen.
Drei Fähigkeiten für den Ernstfall
- Wissen, was man betreibt: Die Kundenkartei der IT entspricht einem aktuellen Lagebild aller Anwendungen: welche Softwarebausteine sie enthalten, auf welchen Systemen sie laufen, wie sie voneinander abhängen und wie wichtig sie für den Dienstbetrieb sind. Dafür braucht es keine weitere Liste, die von Hand gepflegt wird. Vorhandene Quellen wie Scanner, Inventar und Entwicklungswerkzeuge werden automatisch zusammengeführt. Für die Verwaltung ist ein Punkt besonders wichtig: Das Lagebild kombiniert die Perspektive von Behörde und IT-Dienstleister. Dann lässt sich bei einer Warnung ohne Rundmail beantworten, ob und wo eine betroffene Komponente läuft.
- Nach Risiko sortieren: Mit dem CVSS-Wert werden Sicherheitslücken bewertet. Im Beispiel beschreibt der Wert, wie gefährlich die Bremse einzuschätzen ist. Über die Nutzung des Autos sagt er nichts. Ein Bürgerportal, das aus dem Internet erreichbar ist, ist der Autobahnfahrer. Ein internes Auswertungssystem ohne externen Zugang steht eher in der Garage. Beide müssen repariert werden, denn intern heißt nicht automatisch sicher. Die Reihenfolge entscheidet aber darüber, wie lange eine mögliche Schwachstelle von einem Angreifer ausgenutzt werden könnte. Mit der richtigen Priorisierung werden die knappen Kräfte dort eingesetzt, wo es wirklich drängt.
- Kontrolliert reparieren und nachweisen: Patches müssen vorbereitet, abgestimmt, installiert und dokumentiert werden. Updates werden über die vorhandenen Werkzeuge im Betrieb eingespielt, unter Beachtung von Abhängigkeiten und Wartungsfenstern. Welche Systeme wann aktualisiert werden, gibt weiterhin ein Mensch frei; das Ausrollen selbst läuft automatisiert. Jeder Schritt wird dokumentiert. Für die Verwaltung ist dieser Nachweis mehr als eine Formsache. Sie muss belegen können, wann welche Lücke geschlossen wurde.
Automatisierter Ablauf als Reaktion auf immer mehr IT-Schwachstellen
Wie solch eine Werkstatt arbeitet, lässt sich bei der Deutschen Telekom ansehen. Sie setzt für ihr Patch-Management IBM Concert ein. Schon im Pilotbetrieb sank die sogenannte Median-Time-to-Patch, also die typische Zeit bis zum Schließen einer kritischen Sicherheitslücke, von 80 auf 8 Stunden. Aus Tagen wurden Stunden. Die Telekom ist keine Behörde. Ihre Ausgangslage ist aber vergleichbar: eine große, gewachsene IT-Landschaft, viele beteiligte Teams und hohe Anforderungen an Sicherheit und Governance.
IBM hat für diese Aufgabe IBM Concert Protect entwickelt. Die Lösung verknüpft Schwachstelleninformationen mit dem Kontext von Code, Anwendung, Infrastruktur und Laufzeit. Sie prüft, ob eine Schwachstelle ausnutzbar ist, priorisiert danach und unterstützt die Behebung bis hin zum orchestrierten Einspielen der Patches in hybriden Umgebungen. So wird aus der Kundenkartei ein Werkzeug, das im Ernstfall eine Übersicht der betroffenen Systeme in der richtigen Reihenfolge liefert.
Wie sähe die Situation nach der Veröffentlichung der nächsten gravierenden Schwachstelle in einer vorbereiteten Verwaltung aus? Die Meldung kommt herein. Kurz darauf liegt eine Liste vor mit betroffenen Systemen. Die aus dem Internet erreichbaren Bürgerportale werden zuerst aktualisiert, die übrigen im nächsten Wartungsfenster. Der IT-Dienstleister arbeitet mit derselben Liste. Die Leitung gibt frei, am Abend ist jede Maßnahme dokumentiert. Das Bürgerportal war gar nicht oder nur kurz offline.
Für Behörden, Kommunen und öffentliche IT-Dienstleister lohnt sich deshalb eine einfache Frage, solange neue Schwachstellen auf sich warten lassen: Wie lange würden Sie heute brauchen, um diese Liste mit den Auswirkungen eines CVEs zu erstellen?
