Zentrales Patch-Management in Automationsumgebungen am Beispiel von WSUS

Inhaltsverzeichnis

    Das Einspielen von Patches und Software-Updates ist in der IT und OT gleichermaßen ein Thema. Patches sorgen dafür, dass Sicherheitslücken in Betriebssystemen und Anwendungen geschlossen oder Schwachstellen repariert werden und mitunter auch die Stabilität von Anwendungen verbessert wird. Sie können aber auch die Verfügbarkeit eines Netzwerks oder einzelner Dienste beeinträchtigen, vor allem dann, wenn ungeprüfte Patches installiert werden, die sich als inkompatibel mit den vorhandenen Komponenten herausstellen.

    Was sich zwischen IT und OT stark unterscheidet, sind die eingesetzten Systeme und die Anforderungen an deren Verfügbarkeit. Deswegen unterscheidet sich auch, wie in beiden Bereichen Nutzen und Risiko gegeneinander abgewogen werden und welche Patch-Strategie zielführend und praktikabel ist.

    Wir beleuchten die Kernaspekte eines erfolgreichen Patch-Managements im Anlagenumfeld und zeigen, was Sie bei der praktischen Umsetzung beachten sollten.

    Kernaspekte des Patch-Prozesses

    Der Umgang mit Patches unterscheidet sich stark in Abhängigkeit davon, ob man sich in der IT im Unternehmensnetzwerk befindet oder in der OT im Anlagennetzwerk.

    In der IT werden möglichst alle Systeme regelmäßig aktualisiert. Ist eine neue Sicherheitslücke bekannt, ist es wichtig, sie durch den entsprechenden Patch so schnell wie möglich zu schließen. Durch die Vielzahl und Häufigkeit von Aktualisierungen ist es gängige Praxis, dass Updates automatisch ausgerollt werden.

    In der OT sind Aktualisierungen insbesondere für unterstützende IT-Systeme, wie SCADA-Server, Engineering Workstations und Historians, sinnvoll und wichtig. Aber es sind bei weitem nicht alle Systeme patchbar. Außerdem können automatische Aktualisierungen in der Regel nicht angewendet werden, da das Anlagenumfeld besondere Anforderungen an die Verfügbarkeit der Systeme stellt.

    Anlagennetze gelten zurecht als besonders sensibel. Es sind nicht selten veraltete Betriebssysteme im Einsatz, auf denen ebenso veraltete Software betrieben wird, die oftmals speziell auf die Betriebssystemversion angepasst wurde. Ein nicht geprüftes Update sämtlicher Systeme führt schnell zu fehlerhaften Zuständen, dem Verlust von Herstellergarantien und im schlimmsten Fall zu einem Anlagenstillstand. Damit es nicht zu Ausfällen durch das Einspielen inkompatibler Patches kommt, bedarf jeder Patch-Vorgang zusätzlicher, manueller Schritte, die sicherstellen, dass er keine negativen Auswirkungen hat.

    In der OT sind daher weniger, dafür aber besser geplante und getestete Aktualisierungen wichtig. Das Ziel ist eine Strategie, die den Umgang mit Patches erleichtert und gleichzeitig das Risiko für die Anlage reduziert.

    Der Hauptaufwand liegt hier in der Organisation, denn der Prozess von der Überprüfung und Freigabe bis zum Ausrollen und Validieren von Updates muss klar geregelt sein.

    Der typische Patch-Prozess umfasst in der Regel fünf Schritte:

    Inventarisierung

    Welche Systeme können und müssen gepatcht werden? Wie regelmäßig kann das passieren und müssen Änderungen manuell durchgeführt werden?

    Identifizierung neuer Patches

    Welche Sicherheitslücken gibt es aktuell? Wie kritisch sind sie und welche Systeme sind davon betroffen?

    Evaluierung und Planung

    Patches sollten in einer Testumgebung ausreichend auf Kompatibilität getestet werden. Hier empfiehlt sich der Aufbau einer kleinen Schattenanlage, in der neue Patches testweise eingespielt und ihre Auswirkungen überprüft werden können. Da freigegebene Updates häufig nur dann installiert werden können, wenn die Systeme nicht im Betrieb sind, muss die Installation zeitlich geplant und mit anderen Anforderungen synchronisiert werden.

    Installation

    Die freigegebenen Patches werden auf den betroffenen Systemen installiert.

    Validierung und Dokumentation

    Nach der Installation von Patches sollte mit den verantwortlichen Personen sehr genau überprüft werden, ob alle Systeme so funktionieren wie erwartet. Tun sie das nicht oder treten beim Ausrollen der Updates Probleme auf, ist es wichtig, einen Recovery-Plan bereit zu haben. Außerdem sollten installierte Updates sowie der Zustand der Systeme vor und nach der Installation dokumentiert werden, damit Probleme oder Unverträglichkeiten, die erst später auftreten, zurückverfolgt werden können.

    Dabei machen im Anlagenumfeld die Schritte 3 und 5 einen Großteil des Aufwandes aus, zumal sie über den Erfolg eines Rollouts entscheiden. Ein zentrales Patch-Management ist dabei eine wichtige Unterstützung.

    Zentrales Patch-Management

    Bei der Vielzahl von Systemen, die in einem Unternehmen heutzutage im Einsatz sind, ist eine separate Aktualisierung jedes einzelnen Systems nicht praktikabel. In der IT haben sich daher längst Patch-Management-Dienste etabliert, die Updates zentral laden und dann auf alle Systeme verteilen.

    Ein Beispiel dafür ist WSUS (Windows Server Update Services), ein Netzwerkdienst für ein zentralisiertes Update- und Patch-Management von Windowssystemen, der kostenfrei von Microsoft zur Verfügung gestellt wird. WSUS läuft auf einem Windowsserver, wo es sich in regelmäßigen Abständen Updates und Patches von der Microsoft-Webseite zieht und dann an alle Rechner im Netzwerk verteilt. Das schont zum einen Bandbreite, vor allem in Netzwerken mit tausenden Clients. Zum anderen erlaubt es Kontrolle über die Art und Weise, wie Updates durchgeführt werden:

    • Wann werden Updates durchgeführt?
    • Welche Systeme betrifft das?
    • Darf ein Update automatisch erfolgen oder muss es manuell ausgelöst werden?

    WSUS ist damit vor allem ein zentrales Administrationswerkzeug, mit dem über Richtlinien, Gruppen und Regeln die notwendigen Updates für Komponenten im Netzwerk koordiniert werden können. Der Administrator muss Aktualisierungen nicht auf jeden einzelnen Client aufspielen, sondern kann sie zentral vom Server aus zuweisen. Über gruppenbasierte Richtlinien kann gesteuert werden, wie das passieren soll. Das ist besonders dann sinnvoll, wenn durch Updates Kompatibilitätsprobleme mit anderen Anwendungen zu erwarten sind. Ein Update wird erst dann ausgeliefert, wenn es ausreichend getestet und eine Inkompatibilität ausgeschlossen wurde.

    WSUS und ähnliche Tools lassen sich in der OT genauso gut einsetzen wie in der IT. Gerade die Übersicht und die Kontrolle, die ein zentrales Update- und Patch-Management bietet, macht es im Anlagenumfeld sinnvoll und wichtig. So lässt sich zum Beispiel zentral ein Inventar verwalten, das festlegt, in welche Kategorie ein System fällt:

    • Systeme, die automatisch mit Updates versorgt werden können
    • Systeme, die nur manuell mit Updates versorgt werden dürfen
    • Systeme, die nur im Notfall Updates erhalten sollen
    • Systeme, die niemals Updates erhalten dürfen

    In der IT fallen die meisten Systeme in die erste Kategorie. In der OT ist die erste Kategorie oft leer und der Hauptteil der Systeme kann nur manuell, wenn überhaupt, gepatcht werden.

    Eine solche Inventarisierung bietet vor allem im Kontext eines Vulnerability-Managements einen echten Mehrwert. Stellen Sie sich vor, ein Automationshersteller informiert über eine wichtige Sicherheitslücke oder Schwachstelle, bietet einen entsprechenden Patch an und Sie können per Knopfdruck eine Übersicht all der Systeme bekommen, die betroffen sind und aktualisiert werden müssen.

    Über eine Inventarisierung hinaus behalten Sie den Überblick, welche Systeme welche Patches bereits erhalten (oder eben nicht erhalten) haben. Gerade wenn Notfall-Patches nötig sind, spart das Zeit und vermeidet, dass Systeme vergessen oder mehrfach gepatcht werden.

    IT und OT können WSUS gleichermaßen für das Patch-Management verwenden, sie unterscheiden sich bei der praktischen Durchführung von Aktualisierungen aber mitunter maßgeblich. Daher ist es für die Verfügbarkeit und die Sicherheit von Systemen besonders wichtig, die Platzierung und das Zusammenspiel der eingesetzten Dienste im Netzwerk sorgfältig zu planen.

    Architektur 

    Bei der Planung eines Patch-Managements im Anlagenumfeld gilt es eine grundsätzliche Architekturentscheidung zu treffen, was die Platzierung des Update-Dienstes im Netzwerk betrifft.

    Aus dem Blickwinkel der IT liegt es nahe, das OT-Patch-Management in die schon bestehenden Dienste zu integrieren. Im Fall von WSUS bedeutet das, dass es einen zentralen WSUS-Server in der IT gibt, der für das komplette Management aller Updates im ganzen Netzwerk verantwortlich ist. Diese Vorgehensweise ist aber in der Regel nicht mit einer sauberen Netzwerkarchitektur vereinbar, birgt eine Reihe von Risiken und erfordert, falls sie doch umgesetzt wird, viel Vorsicht.

    Eine sicherere und meist auch viel praktikablere Alternative ist, dass IT und OT eigene WSUS-Server betreiben, die Updates unabhängig voneinander jeweils im Unternehmensnetzwerk und im Anlagennetzwerk verteilen. In der Umsetzung bedeutet das eine Hierarchie von WSUS-Servern, in der untergeordnete Server Updates von einem übergeordneten Server bekommen und dann jeweils in ihre Teilnetze kommunizieren.

    Im Folgenden gehen wir näher auf diese beiden Optionen und die damit verbundenen Konsequenzen ein.

    Ein zentraler WSUS-Server für IT und OT

    Sie nutzen einen zentralen WSUS-Server, der für das komplette Management aller Updates zuständig ist. Um Updates von Microsoft ziehen zu können, benötigt der Server Zugriff auf das Internet und sollte daher in einer DMZ stehen. Die Konfiguration des Servers ermöglicht eine Gruppierung der Rechner und Maschinen im Netzwerk und Updates können individuell für einzelne Gruppen freigegeben werden. Über sinnvolle Gruppierungen und Richtlinien kann also das Update-Verhalten in Teilnetzen gesteuert werden, so dass Aktualisierungen im Unternehmensnetz anders ausgesteuert werden als Aktualisierungen im Anlagennetz.

    Ein offensichtlicher Vorteil eines zentralen Servers scheint, dass der Administrationsaufwand an einer einzigen Stelle gebündelt ist. Das bedeutet aber auch, dass bei der Konfiguration besondere Vorsicht geboten ist. Da das Ausrollen von Updates im Anlagennetz grundlegend anders organisiert ist als im Unternehmensnetz, muss eine klare Trennung von Gruppen und Richtlinien vorgenommen werden. Die Administration sollte von jemandem durchgeführt werden, der die unterschiedlichen Ausgangspunkte und Anforderungen beider Welten kennt. Darüber hinaus ist ein hohes Maß an Kommunikation zwischen IT und OT nötig, um zu organisieren, wer wann Updates einspielen darf. Realistisch wird es so sein, dass sowohl IT als auch OT volle Kontrolle über ihre Teile des Netzwerks und der damit verbundenen Aktualisierungen ausüben wollen.

    Ob ein zentraler WSUS-Server überhaupt eine Option ist, hängt außerdem stark von Ihrer Netzwerkarchitektur ab. Wird ein schon von der IT verwalteter WSUS-Server genutzt, steht dieser im Unternehmensnetzwerk. Im Fall einer sauberen Netztrennung ist eine direkte Kommunikation zwischen dem Unternehmensnetzwerk und den darunterliegenden Anlagennetzwerken aber gar nicht möglich. Der WSUS-Server der IT kann Updates also gar nicht ohne Weiteres in den Anlagen verteilen.

    Daher ist es sauberer, sicherer und in den meisten Fällen auch praktisch einfacher, getrennte WSUS-Server zu betreiben.

    Getrennte WSUS-Server für IT und OT

    WSUS-Server lassen sich in einer Hierarchie anordnen. Dabei hat ein übergeordneter WSUS-Server Zugriff auf das Internet und lädt regelmäßig Updates. Zusätzlich steht in jedem Teilnetzwerk ein eigener WSUS-Server, der Updates vom übergeordneten Server erhält und dann innerhalb seines Teilnetzes verteilt.

    Konkret bedeutet das in der Regel, dass es einen übergeordneten WSUS-Server in der IT gibt, der Updates aus dem Internet zieht und im Unternehmensnetz verteilt, und einen zusätzlichen WSUS-Server in der OT, der Updates vom WSUS-Server der IT erhält, diese selber überprüfen kann und dann nach seinen eigenen Regeln im Anlagennetz ausrollt.

    Der WSUS-Server der OT steht in der Regel in einer DMZ, in der er vom Unternehmensnetzwerk aus erreichbar ist und außerdem mit den Anlagennetzwerken kommunizieren kann. Beide bleiben dabei sauber getrennt.

    Den WSUS-Server der OT dem der IT unterzuordnen, hat den Vorteil, dass man von den Prozessen in der IT profitieren kann. Zum Beispiel erhält der WSUS-Server der OT automatisch nur die Updates, die von der IT-Abteilung bereits freigegeben wurden. Das erspart Mehrfachaufwand, denn Updates, die für die IT nicht freigegeben werden, sind höchstwahrscheinlich auch nicht in der OT geeignet und können so unternehmensweit ausgesetzt werden. Für freigegebene Updates kann die OT schließlich noch zusätzliche, für die Automationsumgebung spezifische Tests ausführen, bevor sie sie für die Teilnetzwerke freigibt. Zusätzlich führt die IT ein Monitoring und Reporting durch, das auch für die OT genutzt werden kann.

    Die Anzahl der WSUS-Server in der Hierarchie kann je nach Größe des Netzwerks variieren. So kann es zum Beispiel bei verteilten Standorten sinnvoll sein, dass es pro Standort oder auch pro Werk einen eigenen WSUS-Server gibt. Das reduziert die Bandbreite beim Ausrollen der Updates und erfordert weniger offene Firewall-Verbindungen, da sich die WSUS-Server nah an ihren Clients befinden. Auf die verschiedenen Optionen spezifischer WSUS-Architekturen wollen wir hier aber nicht näher eingehen.

    Praktische Maßnahmen

    Die folgenden konkreten Maßnahmen sind bei der Umsetzung eines zentralen Patch-Managements ratsam.

    Updates abwarten und Hersteller konsultieren

    Es empfiehlt sich, einige Tage nach der Veröffentlichung von Patches zu warten, bevor man diese in der Anlage ausrollt. Nutzt man seinen WSUS-Server als Subserver des WSUS der IT-Abteilung, profitiert man davon, dass die IT-Abteilung Updates generell erst bei einer ausbleibenden Rückrufaktion freigibt.

    Unabhängig davon lohnt es sich, bei dem jeweiligen Anlagenhersteller Aussagen zur Verträglichkeit der Patches mit anderen Anwendungen in Erfahrung zu bringen. Prüfen Sie doppelt und dreifach, ob die von Ihnen freigegeben Updates auch wirklich für die vorgesehenen Systeme freigegeben wurden. Idealerweise verlassen Sie sich nie ganz darauf, sondern testen selbst.

    Keinen Schritt auslassen

    Der Hauptaufwand liegt in der Organisation der Prozesse, in Testumgebungen und Recovery-Plänen, im Validieren und Dokumentieren von Patches. Aber hier zahlen sich Investitionen auch am meisten aus, denn diese Schritte entscheiden über den Erfolg eines Rollouts und damit über die Verfügbarkeit und Sicherheit Ihrer Anlage.

    Gruppen mit passgenauen Richtlinien einrichten

    Es lohnt sich, mehrere Gruppen zu erstellen, denen jeweils ein Server und ein Teil der Clients zugeordnet sind. Gruppenrichtlinien sollten so organisiert werden, dass sie berücksichtigen, ob ein System aktualisiert wird und wenn ja, wie regelmäßig und auf welche Weise. Dadurch lassen sich auch Systeme schützen, die nicht patchbar sind.

    Gruppen können zusätzlich in redundante Untergruppen aufgeteilt werden, um Patches erst in einem Teil der Anlage auszurollen. Treten keine Fehler auf, kann das Update später auch im Rest der Anlage eingespielt werden. Das verringert das Risiko von Ausfällen aufgrund von inkompatiblen Patches.

    Bei der Konfiguration von Gruppen und Richtlinien kommt in der Regel ein Active Directory ins Spiel. Zum einen bietet es sich an, Gruppen, die im Active Directory schon angelegt sind, so auch im WSUS zu verwenden. Zum anderen macht ein Active Directory das Einrichten und Verwalten von Konfigurationen und Update-Richtlinien eines WSUS-Servers sehr viel einfacher.

    Fazit

    Während das regelmäßige und automatische Aktualisieren von Systemen in einer gut organisierten IT-Abteilung eine Routineaufgabe ist, stehen Automationsumgebungen vor allem bei der Organisation des Patch-Prozesses vor einer Herausforderung. Ein zentrales Patch-Management, zum Beispiel mit WSUS, kann diesen Prozess unterstützen. Dabei ist der Betrieb eines WSUS im Automationsumfeld genauso gut durchführbar wie in der IT. Aber die grundlegend anderen Anforderungen führen dazu, dass das Patch-Management der OT nicht ohne Weiteres in bestehende IT-Dienste integriert werden kann, sondern eigene Prozesse und Dienste braucht.

    Der Industrial Security Guide zum schnellen Einstieg

    Max Weidele
    CEO & Founder

    Industrie 4.0, Digitalisierung u. steigende Vernetzung. Die OT- und OT-Security Welt wächst stetig weiter, da ist ein schneller Einstieg manchmal sehr schwer.

    Aus diesem Grund haben haben wir einen Einstiegsguide zur Industrial Security geschrieben, der ihnen kurz und knapp die wichtigsten Themen nahelegt.

    Hier gehts zum Download!

    Ihre Daten sind bei uns sicher. Datenschutzerklärung
    Veröffentlicht am
    Zuletzt aktualisiert am

    Schreiben Sie einen Kommentar

    Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

    Checkliste herunterladen

    Industrie 4.0, Digitalisierung u. steigende Vernetzung. Die OT- und OT-Security Welt wächst stetig weiter, da ist ein schneller Einstieg manchmal sehr schwer.


    Aus diesem Grund haben haben wir einen Einstiegsguide zur Industrial Security geschrieben, der ihnen kurz und knapp die wichtigsten Themen nahelegt.

    Ihre Daten sind bei uns sicher. Datenschutzerklärung