Schwachstelle erkannt: Der Betrieb geht weiter

Man stelle sich ein kommunales Onlineportal vor, das mit mehreren Fachanwendungen denselben Identitätsdienst nutzt. Eine kritische Schwachstelle wird bekannt. Der Patch ist verfügbar, doch seine Installation verlangt umfangreiche Kompatibilitätstests: Ein Ausfall würde zahlreiche Verwaltungsabläufe treffen. Der Eingriff wird verschoben. Die Software bleibt verwundbar, der Dienst läuft weiter.

Die Frage „Wann können wir patchen?“ greift nun zu kurz. Ebenso wichtig ist: Über welche Wege könnte ein Angreifer die Lücke ausnutzen? Die Antwort hängt von Schnittstellen, Benutzerrechten, Fernzugängen und Verbindungen zu anderen Systemen ab.

Das gilt für Banken, Krankenhäuser, Energie- und Wasserversorger, Bahnbetreiber sowie Industrieunternehmen. Auch während eines Aufschubs muss der Schutz kritischer Dienste greifen.

Die Lücke zwischen Inventar und Realität

Viele Organisationen wissen, welche Anwendungen sie betreiben. Deutlich schwieriger ist die Frage, wie sie tatsächlich erreichbar sind. Ein vermeintlich internes System kann über einen Dienstleisterzugang, eine gemeinsam genutzte Administrationsplattform oder eine Schnittstelle zum Internet mit weniger geschützten Bereichen verbunden sein. Auch erlaubte Kommunikation kann zum Einfallstor werden, wenn Angreifer bereits gültige Zugangsdaten besitzen.

Eine Schwachstellenliste bildet solche Beziehungen nicht ab. Das „Common Vulnerability Scoring System“ (CVSS) bewertet standardisiert die technische Schwere einer Sicherheitslücke. Der Known-Exploited-Vulnerabilities-Katalog (KEV) der US-Cybersicherheitsbehörde CISA erfasst Schwachstellen, deren Ausnutzung bei realen Angriffen nachgewiesen wurde. Beide helfen bei der Priorisierung, zeigen aber nicht, ob und wie ein betroffenes System in der konkreten Infrastruktur erreichbar ist. Erst zusammen mit Kommunikationsbeziehungen und möglichen Folgen einer Kompromittierung entsteht ein belastbares Risikobild. Ein verwundbarer Identitätsdienst, von dem zahlreiche Anwendungen abhängen, birgt Risiken, die eine isolierte Schwachstellenliste kaum erkennen lässt.

Auch ein Fernwartungszugang zu einem Wasserwerk oder eine Verbindung zwischen Büro- und Steuerungsnetz kann sicherheitsrelevanter sein als die Zahl ungepatchter Komponenten. Der Blick muss vom einzelnen Gerät auf Angriffspfade und abhängige Dienste wechseln.

Schutzwirkung und Angriffspfad

Ist eine sofortige Aktualisierung ausgeschlossen, kommt es auf gezielte Eingriffe in die Sicherheitsarchitektur an. Die Netzwerksegmentierung beschränkt, welche Systeme miteinander kommunizieren dürfen. Strenge Zugriffsrechte und kontrollierte Fernwartung reduzieren die Möglichkeiten, verwundbare Komponenten überhaupt zu erreichen. Intrusion-Prevention-Systeme (IPS) können darüber hinaus Angriffsversuche im Datenverkehr erkennen und blockieren – sofern die jeweiligen Protokolle unterstützt werden und eine Analyse des Verkehrs möglich ist.

Hier zeigt sich der Vorteil einer kontextbezogenen Protokollanalyse gegenüber einer rein signaturbasierten Angriffserkennung. Moderne Stateful-DPI-IPS-Systeme prüfen nicht nur bekannte Angriffsmuster, sondern auch, ob Kommunikationsabläufe den jeweiligen Protokollstandards, etwa den RFC-Spezifikationen, entsprechen. Dadurch können sie selbst bislang unbekannte Angriffsversuche erkennen und blockieren, sofern letztere von den zulässigen Abläufen abweichen. Entscheidend ist, dass die Schutzmechanismen die genutzten Dienste und Kommunikationswege erfassen.

Wenn ein Patch verschoben werden muss, darf man sich nicht ausschließlich auf die Annahme verlassen, dass das System bereits durch eine Firewall geschützt ist.

Philipp Sauerwein, Stormshield

„Wenn ein Patch verschoben werden muss, darf man sich nicht ausschließlich auf die Annahme verlassen, dass das System bereits durch eine Firewall geschützt ist“, erklärt Philipp Sauerwein, Presales-Engineer DACH bei Stormshield. „Man muss exakt nachvollziehen, welche Angriffswege zu der verwundbaren Anwendung führen und an welcher Stelle im Netzwerk ein Angriff wirksam unterbunden werden kann. Eine Schutzmaßnahme ist erst dann erfolgreich, wenn sie einen realistischen Angriffsversuch stoppt – und das, ohne den Geschäftsdienst zu beeinträchtigen.“

Wo passende Schutzregeln Angriffe gegen eine bekannte Schwachstelle auf Netzwerkebene blockieren, wird häufig von „Virtual Patching“ gesprochen. Es kann wertvolle Zeit verschaffen, verändert aber nicht die fehlerhafte Software. Zudem bleibt die Wirksamkeit auf die erfassten Verkehrswege und erkennbaren Angriffsmuster begrenzt. Deshalb sind nachvollziehbare Tests und regelmäßige Kontrollen unverzichtbar.

Wenn die Abhängigkeit größer ist als das System

Für kritische Dienste kommt eine zweite Dimension hinzu: Was geschieht, wenn eine Schutzmaßnahme oder ein Update den Betrieb beeinträchtigt? Bei einer Bank kann eine Unterbrechung die Transaktionsverarbeitung treffen, in einem Krankenhaus klinische Abläufe, bei einem Energieversorger die Steuerung technischer Prozesse. Zugleich können selbst kurze Ausfälle eines gemeinsam genutzten Identitäts- oder Kommunikationsdienstes zahlreiche nachgelagerte Anwendungen erfassen.

Solche Abhängigkeiten verändern die Entscheidung über den Zeitpunkt eines Updates. IT-Sicherheits- und Betriebsverantwortliche legen im Idealfall gemeinsam fest, welche Verbindungen zwingend benötigt werden, welche zeitweise eingeschränkt werden können und welche Änderungen vorab getestet werden müssen. Dazu gehören Wiederherstellungswege ebenso wie die Frage, ob ein Eingriff bei unerwarteten Auswirkungen sicher zurückgenommen werden kann. Eine Schutzregel, die einen unverzichtbaren Dienst lahmlegt, verfehlt ihren Zweck.

Wann eine vertretbare Ausnahme unvertretbar wird

Eine Übergangslösung ist nur so gut wie die Annahmen, auf denen sie beruht. Ein neuer öffentlich verfügbarer Exploit, ein zusätzlicher Fernzugang, eine geänderte Cloud-Anbindung oder Hinweise auf aktive Angriffe können die Lage innerhalb kurzer Zeit verändern. Dann reicht es nicht, auf den ursprünglich genehmigten Wartungstermin zu verweisen.

Für aufgeschobene Updates braucht es daher mehr als eine dokumentierte Ausnahme: Verantwortliche müssen festhalten, welche Angriffspfade aktuell begrenzt sind, wie dies überprüft wurde, welche Ereignisse eine Neubewertung auslösen und wann die endgültige Behebung erfolgt. Fehlt dauerhaft die Herstellerunterstützung, muss auch die Ablösung geprüft werden.

Gutes Schwachstellenmanagement bemisst sich nicht allein daran, wie schnell Patches installiert werden. Entscheidend ist auch, ob eine Organisation begründen kann, warum ihre kritischen Dienste trotz offener Schwachstellen vertretbar geschützt sind. Die Lücke mag offen bleiben. Die Wege dorthin dürfen jedoch kein blinder Fleck sein.