Immer wieder trifft man in letzter Zeit auf den Begriff “Virtuelles Patchen”. Doch was steckt eigentlich dahinter, welche Vor- und Nachteile hat diese Art des Patchens gegenüber dem herkömmlichen Patchprozess und wann macht es überhaupt Sinn, Schwachstellen nach diesem Prinzip einzudämmen? In folgendem Beitrag liefern wir Ihnen Antworten auf diese und viele weitere Fragen.
Virtuelles Patchen wird definiert als: „Eine Schicht zur Durchsetzung von Sicherheitsrichtlinien, die die Ausnutzung einer bekannten Verwundbarkeit verhindert“ [1]. Wobei ein virtueller Patch eine Richtlinie für eben diese Schicht ist, welche die Ausnutzung einer gewissen Schwachstelle in der Zielanwendung verhindern soll [2]. Kurz gesagt: Mit einem virtuellen Patch wird nicht die eigentlich fehlerhafte Anwendung repariert, sondern ein – teils vorgelagerter, zusätzlicher – Sicherheitsmechanismus etabliert, welcher die Ausnutzung einer Schwachstelle verhindern soll.
Eine Umsetzung eines solchen Mechanismus kann dabei über verschiedene Wege geschehen [1]:
Eine beispielhafte Anwendung von virtuellen Patches findet sich auch hier: Virtual Patching Cheat Sheet [5]
Ein „klassischer“ Patch hingegen wird als Behebung eines Problems innerhalb einer Softwarekomponente definiert [3]. Im Vergleich zum virtuellen Patch wird hier also die Ursache des Problems behoben und nicht dessen Auswirkung bekämpft bzw. abgemildert.
Bei einem Patch werden zwar typischerweise Fehler beseitigt, diese gehen aber zum Teil auch mit Änderungen bzw. Aktualisierungen einher und somit wird teilweise auch der Begriff „Update“ synonym verwendet [4]. Das wiederum kann sowohl gut als auch schlecht sein, vor allem in industriellen Umgebungen. Es könnte beispielsweise bereits bekannte Fehler in der eigentlichen Geschäftslogik der Software geben, welche durch das Update (respektive den Patch) direkt mit behoben werden. Diese Chance geht jedoch mit dem Risiko einher, dass der bisherige Ablauf des Programms so verändert wurde, dass es zu neuen Zuständen kommt, welche wiederum zu Fehlern im Produktionsablauf führen können, wenn deren Auswirkungen nicht bekannt sind und mit diesen nicht entsprechend umgegangen werden kann bzw. wird.
Bevor jedoch zum eigentlichen Patchen übergegangen werden kann gibt es notwendige Vorarbeiten, welche erledigt werden sollten. Zuallererst sollte über das Asset Management bekannt sein, welche Geräte in der jeweiligen Infrastruktur vorhanden sind, welche Hardware dort verbaut ist und welche Software sowie deren Version dort aktuell zum Einsatz kommt. Ohne diese Informationen lässt sich im weiteren Verlauf weder über virtuelle Patches noch über klassische Patches ein verlässlicher Schutz realisieren. Bereits ein einzelnes, nicht inventarisiertes, System könnte ansonsten von versierten Angreifern dafür verwendet werden die übrigen Systeme im jeweiligen (Sub-)Netzbereich (Stichwort: laterale Ausbreitung) erneut zu infizieren.
Nachdem diese Asset Informationen – bestenfalls automatisiert, sodass eine regelmäßige Aktualisierung einfach und ohne großen Aufwand möglich ist – akkumuliert wurden, geht es an den Abgleich mit bekannten CVEs (Common Vulnerabilities and Exposures). Dort wird seit geraumer Zeit das CVE-Format verwendet, um eben solche Informationen auszutauschen. Siehe hierzu auch unsere Beiträge zum Thema CVE.
Die jeweiligen Informationen können dann aus diversen öffentlichen Quellen von verschiedenen Computer Emergency Response Teams (CERTs) bezogen werden. Dabei gibt es sowohl allgemein gehaltene Quellen, spezifische für den Industriebereich aber – vor allem bei größeren Firmen – teils auch unternehmenseigene CERTs.
Bevor jetzt zum eigentlichen Patchen übergegangen werden kann, stellt sich in der Praxis des Öfteren auch die Frage nach der jeweiligen Zuständigkeit für die Installation von Patches. Dazu kann die IEC 62443 Norm zu Rate gezogen werden. In dieser ist definiert, dass es die Rollen des „Product Supplier“ (Hersteller), des „System Integrator“ (Integrator) und des „Asset Owner“ (Betreiber) gibt. Diesen ist jeweils auch eine spezifische Zuständigkeit für die Sicherheit der Systeme zugeschrieben.
Der Hersteller ist sowohl für die Entwicklung des Produkts wie auch für dessen Pflege verantwortlich. Solange sich ein Produkt also innerhalb der Wartung durch den Hersteller befindet, ist der Hersteller ebenfalls dazu angehalten (vor allem sicherheitskritische) Software Aktualisieren für die Systeme bereitzustellen. Spannend wird es, sobald ein System aus eben dieser Wartung entfällt und eine Aktualisierung – z.B. der Hardware – auf Betreiberseite beispielsweise aus Kostengründen nicht wirtschaftlich erscheint.
Der Integrator ist für das Gesamtdesign der Anlage sowie deren Installation verantwortlich und muss dabei auch die Verbindung zu Drittsystemen mitberücksichtigen, um einen sicheren Betrieb zu ermöglichen. Dabei ist eine enge Abstimmung mit dem Hersteller bezüglich der Fähigkeiten der jeweiligen Systeme, sowie mit dem Betreiber bezüglich des Einsatzszenarios und der geplanten Umgebung notwendig.
Der Betreiber wiederum ist dann sowohl für den eigentlichen Betrieb der Maschinen und Anlagen wie auch für deren Wartung und auch deren Außerbetriebnahme während der „End of Life“ (EOL) Phase zuständig. Während des Betriebs besziehungsweise der Wartung müssen neben mechanisch notwendigen Arbeiten auch softwareseitige Instandhaltungsaufgaben bearbeitet und gelöst werden. Eine davon beinhaltet auch die Aktualisierung der jeweiligen Softwaresysteme mithilfe der vom Hersteller bereitgestellten Ressourcen.
Wie die Grafik verdeutlicht wird in der Norm ein wechselseitiger Informationsaustausch gefordert, sodass auch der Hersteller beispielsweise Informationen über die Verträglichkeit der Patches im Feld erhält und diese somit in seinen Qualitätsprozess mit einfließen lassen kann. Der hier orange markierte Pfeil stellt beispielsweise die Bereitstellung einer nach IEC 62443-2-3 kompatiblen Patchliste dar, welche z.B. Betriebssytempatches auf deren Verträglichkeit mit den eingesetzten Produkten des Herstellers kennzeichnet. Verfügt der Betreiber nun über ein gut integriertes Asset Management mit integriertem Patch Management, welches es erlaubt diese Listen automatisiert zu verarbeiten, ist deren regelmäßige Aktualisierung und anschließende Anwendung auf die Produktionssysteme ein Leichtes.
Anhand des beispielhaften Anwendungsfalls „WannaCry“ auf Windows (XP) Systemen in der Produktion.
Virtuelles Patchen: +
Klassisches Patchen: +
Bei beiden Arten „lohnt“ sich der Aufwand, der investiert wird im Hinblick auf das geminderte Risiko für die betroffenen Systeme. Vor allem wenn es sich dabei um produktionskritische Systeme handelt und ein Ausfall dieser einen Komplett- oder Teilausfall des jeweiligen Produktionsbereichs nach sich ziehen würde.
Im beispielhaft betrachteten Anwendungsfall wurde seitens des Betriebssystemherstellers ein kostenfreier (klassischer) Patch bereitgestellt, welcher lediglich auf den Systemen installiert werden musste. Im Falle des virtuellen Patchens konnten die SMBv1 Verbindungen eingeschränkt werden, was ebenfalls einfach möglich ist und zumindest eine weitere Ausbreitung eindämmt.
Virtuelles Patchen: ++
Klassisches Patchen: –
Da virtuelle Patches z.B. über ein vorgelagertes Gerät gesteuert werden kann und somit unabhängig vom betroffenen Gerät sind, lässt sich hier schnell und einfach eine Anpassung vornehmen. Beim klassischen Patchen hingegen muss zuerst abgeklärt werden, ob ein Softwareupdate bereits verfügbar und für die eigenen Systeme (z.B. hardwaretechnisch bzgl. Anforderungen) passend und unterstützt ist – hier zahlt sich ein solides Asset Management im Vorfeld natürlich voll aus. Außerdem müssen die Patchdateien – sofern verfügbar – erst bezogen und dann auf alle Endgeräte bereitgestellt und dort installiert werden – hier zahlt sich die Automatisierung der IT-Geräteverwaltung, wie es beispielsweise in der Softwarelösung ondeso SR angeboten wird, voll aus. Je nachdem wie viel manueller Aufwand hier noch betrieben werden muss, oder wie gut es bereits automatisiert wurde, könnte die erreichbare Geschwindigkeit ebenfalls nochmal variieren und somit den Vorsprung des virtuellen Patchens hier noch etwas schmälern.
Bezogen auf den angenommenen Anwendungsfall lässt sich hier jedoch sagen, dass die Bereitstellung des klassischen Patches seitens des Betriebssystemherstellers und die anschließende Prüfung des Maschinenherstellers wohl mehr Zeit in Anspruch genommen hat als die Anpassung der eigenen Systeme mittels eines virtuellen Patches. Zusätzlich bleibt jedoch anzumerken, dass die von Sicherheitsforschern entdeckten Lücken meist im sogenannten „Responsible Disclosure“ Verfahren an den Hersteller herangetragen werden, sodass dadurch ein gewisser zeitlicher Vorsprung für die Entwicklung eines Patches besteht, bevor die Information der breiten Öffentlichkeit kommuniziert wird.
Automatisieren Sie die Suche und Installation von Updates und testen Sie unsere All-in-One-Software ondeso SR 30 Tage lang kostenlos.
Virtuelles Patchen: —
Klassisches Patchen:
In diesem Punkt hat das klassische Patchen klar „die Nase vorn“, da es die eigentliche Ursache des Problems behebt, anstatt dessen Auswirkungen einzudämmen. Wie eingangs bereits erwähnt strebt ein virtueller Patch nicht danach die Lücke zu beseitigen, sondern dient nur dazu deren Ausnutzung zu unterbinden. Somit kann es eher als Übergangsmaßnahme betrachtet werden, bis ein normaler Patch für das Problem bereitsteht.
Das unterstreicht auch der Anwendungsfall „WannaCry“ nochmals. Wenn beispielsweise ein virtueller Patch an den Netzwerkübergängen verschiedener Bereiche implementiert wird, verhindert dies aber nicht die Ausbreitung innerhalb eines dieser Bereiche, wohingegen der klassische Patch die Verwundbarkeit auf den betroffenen Systemen beseitigt und somit einen nachhaltigen Schutz bietet.
Virtuelles Patchen: –
Klassisches Patchen: 0
Hier sollte es das Ziel von beiden Varianten sein, möglichst keine Auswirkungen auf die Geschäftslogik zu haben beziehungsweise keine Einschränkungen im Funktionsumfang nach sich zu ziehen. Das kann sich aber pro betrachteter Lücke stark unterscheiden. Ein virtueller Patch muss gegebenenfalls den Zugriff auf gewisse Funktionen / Endpunkte sperren, in denen es bekanntermaßen zu Problemen kommt, wohingegen ein Patch die Lücke schließen und gleichzeitig die Funktion vollständig wiederherstellen kann.
Im konkreten Anwendungsfall bedeutet das für den klassischen Patchen, dass Zeit für die Installation benötigt wird, anschließend SMB aber wieder wie zuvor genutzt werden kann. Beim virtuellen Patchen hingegen kann die Maßnahme sofort ergriffen werden, schränkt jedoch die Kommunikation via SMB ein und hat somit gegebenenfalls negative Auswirkungen auf den Geschäfts- bzw. Produktionsprozess.
Virtuelles Patchen: 0
Klassisches Patchen: +
Im Hinblick auf die Verfügbarkeit der jeweiligen Patchtypen ist es wohl geläufiger „normale“ Updates, sei es das Betriebssystem oder spezifische Anwendersoftware auf den Maschinen, mithilfe der Ressourcen des jeweiligen Herstellers durchzuführen. Dies entspricht wohl auch der Erwartungshaltung der meisten Kunden von solchen Systemen, da diese typischerweise sowohl ein funktionierendes wie auch ein sicheres System gekauft haben und weiterhin betreiben möchten. Dabei sollte bereits beim Einkauf darauf geachtet werden, entsprechend langfristig angelegte Unterstützung der Systeme von Seiten des Herstellers zu berücksichtigen. Nichtsdestotrotz kann es aufgrund der sehr langen Betriebszeiten für Maschinen und Anlagen durchaus vorkommen, dass gewisse Systeme nicht mehr produziert beziehungsweise unterstützt werden, oder schlimmstenfalls die betreffende Herstellerfirma nicht mehr existent ist und somit auch keine Aktualisierungen mehr anbieten kann. Im Fall von virtuellen Patches liegt es wohl eher am Betreiber des Systems diese kurzfristig selbst zu entwerfen und zu implementieren, nicht zuletzt aufgrund der zeitlichen Dringlichkeit.
Wieder bezogen auf den Anwendungsfall lässts sich hier sagen, dass hier ein Patch von Herstellerseite bereitgestellt wurde, es also Unterstützung gab. Im Fall des virtuellen Patchens gibt es vermutlich allgemeine Lösungen für die Sperrung von SMBv1 Verbindungen, jedoch weniger konkrete Gegenmaßnahmen für das spezifische Problem.
Virtuelles Patchen: +
Klassisches Patchen: –
In Hinblick auf die Anwendung der Techniken im Industrieumfeld spielt auch das Thema „Wartungsfenster“ eine große Rolle. Hier ist unserer Meinung nach der virtuelle Patch wieder etwas im Vorteil, da dieser gegebenenfalls unabhängig vom betroffenen System eingespielt werden kann und somit kein Wartungsfenster benötigt. Andererseits ist es ebenfalls möglich eine Patchinstallation für die betroffenen Systeme vorauszuplanen, welche dann vom Bedienpersonal angestoßen werden kann, sobald sich – auch spontan – die Möglichkeit dazu ergibt.
Im Falle von WannaCry ist für die Installation des entsprechendes klassischen Patches wohl ein Wartungsfenster notwendig, da höchstwahrscheinlich ein Neustart des betreffenden Systems durchgeführt werden muss. Hier schlägt also das virtuelle Patchen, welches dieses Wartungsfenster nicht zwangsläufig benötigt, solange es durch die Einschränkung der Verbindungsmöglichkeit zu keinen Auswirkungen auf die Funktionalität der Systeme kommt.
Wie auch in der Tabelle gut zu erkennen ist, sollten die beiden Maßnahmen des virtuellen und des klassischen Patchens nicht so verstanden werden, dass sie sich gegenseitig ablösen, sondern dass sie sich gegenseitig gut ergänzen können. Muss beispielsweise möglichst zügig auf das Bekanntwerden einer Sicherheitslücke reagiert werden, um das einhergehende Risiko zu mindern, bietet sich der Einsatz von virtuellen Patches an. Anschließend sollte jedoch in jedem Fall geprüft werden, ob es bereits eine aktualisierte Softwareversion gibt, die eingesetzt werden könnte, um die betreffende Verwundbarkeit nachhaltig zu beseitigen und den virtuellen Patch somit obsolet zu machen. Unterstützen kann Sie dabei unsere Softwarelösung ondeso SR. Auch ein Austausch zwischen Hersteller, Betreiber und Systemintegrator wird – unter anderem auch in der IEC 62443 Norm – gefordert, sodass gemeinsam eine gute und verträgliche Lösung für das Problem gefunden werden kann.
Zusammengefasst lässt sich also sagen: Virtuelles Patchen ist eher Segen als Fluch, kann sich aber zu einem solchen entwickeln, wenn es als Ersatz für die eigentliche Behebung der Lücken über „klassische“ Patches und als eine Art Dauerlösung angesehen wird.
Klingt interessant?
Hier können Sie sich die wichtigsten Facts zum Thema virtuelles Patchen kostenlos herunterladen:
Passend dazu empfehlen wir Ihnen auch unser YouTube-Video “Virtuelles Patchen”:
Mit dem Laden des Videos akzeptieren Sie die Datenverarbeitung von YouTube.
Mehr erfahren
Möchten Sie mehr erfahren? Zögern Sie nicht uns zu kontaktieren, wir helfen Ihnen gerne weiter.
Hier erfahren Sie mehr über unser Unternehmen und unsere Expertise als Pionier und Marktführer.
