Patch-Management in der OT: Wenn du nicht einfach updaten kannst

Das Dilemma: Patchen oder Laufenlassen?

Jeden zweiten Dienstag im Monat veröffentlicht Microsoft seine Sicherheitsupdates. In der IT-Welt sind sie innerhalb von Tagen auf den meisten Systemen installiert, oft automatisch. In der OT-Welt hingegen kann derselbe Patch Monate warten, manchmal Jahre. Und manchmal wird er nie installiert.

Das ist kein Zeichen von Nachlässigkeit. Es ist die Konsequenz fundamentaler Unterschiede zwischen IT- und OT-Umgebungen, die jeden Patch-Prozess beeinflussen.

Ein Windows-Patch auf einem SCADA-Server kann die SCADA-Software destabilisieren, wenn der Hersteller den Patch nicht explizit freigegeben hat. Ein Firmware-Update auf einer SPS kann das Steuerungsprogramm inkompatibel machen und die gesamte Produktionslinie stoppen. Ein Neustart, der in der IT eine Selbstverständlichkeit ist, kann in der OT einen Produktionsstillstand von mehreren Stunden bedeuten, weil die Anlage nach dem Neustart erst wieder hochgefahren und kalibriert werden muss.

Das Ergebnis: Viele mittelständische Unternehmen patchen ihre OT-Systeme gar nicht. Sie wissen, dass das ein Risiko ist, aber sie sehen keine praktikable Alternative. Dieser Artikel zeigt, dass es eine gibt.

Warum klassisches IT-Patch-Management in der OT scheitert

Bevor du einen OT-Patch-Prozess aufbaust, musst du verstehen, warum der IT-Ansatz nicht funktioniert:

Herstellerfreigaben

In der IT installierst du einen Microsoft-Patch direkt von Microsoft. In der OT gibt es eine Zwischenebene: Der Maschinenhersteller oder SCADA-Anbieter muss den Patch für seine Softwareumgebung freigeben. Diese Freigabe kann Wochen oder Monate dauern, weil der Hersteller den Patch erst mit seiner Software testen muss.

Beispiel: Microsoft veröffentlicht ein kritisches Sicherheitsupdate für Windows Server. Der SCADA-Hersteller testet das Update mit seiner Software und gibt es vier Wochen später frei. In diesen vier Wochen ist dein SCADA-Server verwundbar, und du kannst nichts dagegen tun, außer Compensating Controls einzusetzen.

Keine Staging-Umgebung

In der IT testest du Patches in einer Staging-Umgebung, bevor du sie in der Produktion ausrollst. In der OT gibt es diese Staging-Umgebung meistens nicht. Eine vollständige Nachbildung einer Produktionsanlage mit allen Steuerungen, Sensoren und Aktoren ist unverhältnismäßig teuer. Du musst den Patch also direkt auf dem Produktionssystem installieren, und das Risiko eines Problems ist entsprechend höher.

Reboot-Empfindlichkeit

Viele Patches erfordern einen Neustart. In der IT ist das ein kurzer Vorgang. In der OT kann ein Neustart des SCADA-Servers bedeuten, dass die Bediener für 15 bis 30 Minuten keine Übersicht über den Produktionsprozess haben. Ein Neustart der SPS kann einen kompletten Wiederanfahrprozess auslösen, der Stunden dauern kann.

Veraltete Systeme

Manche OT-Systeme laufen auf Betriebssystemen, für die es keine Patches mehr gibt. Einen Vergleich zum Patch-Management in der IT macht den Unterschied deutlich. Windows XP, Windows 7, Windows Server 2008: All diese Systeme sind in der OT-Welt noch aktiv im Einsatz, weil die darauf laufende Steuerungssoftware nicht auf neueren Betriebssystemen funktioniert. Für diese Systeme ist klassisches Patching schlicht unmöglich.

Protokolle ohne Sicherheitsfunktionen

Industrielle Protokolle wie Modbus oder Profinet bieten keine Authentifizierung oder Verschlüsselung. Es gibt keine „Patches" für diese Protokolle, weil Sicherheit im Protokolldesign nicht vorgesehen war. Schwachstellen auf der Protokollebene können nur durch Compensating Controls adressiert werden.

Der risikobasierte Ansatz

Statt alle Patches so schnell wie möglich zu installieren (wie in der IT üblich), bewertest du in der OT jeden Patch individuell. Das Ziel: Die richtigen Patches zur richtigen Zeit installieren und für alles andere wirksame Alternativmaßnahmen treffen.

Schritt 1: Schwachstelle bewerten

Wenn ein neuer Patch oder eine neue Schwachstelle veröffentlicht wird, bewertest du sie anhand folgender Kriterien:

CVSS-Score: Der Common Vulnerability Scoring System Score gibt eine standardisierte Bewertung der Schwere. Ab CVSS 7.0 (High) solltest du aktiv werden. Ab CVSS 9.0 (Critical) ist das Risiko so hoch, dass du auch kurzfristige Maßnahmen in Betracht ziehen musst.

Ausnutzbarkeit: Gibt es bereits öffentlich verfügbare Exploits? Wird die Schwachstelle aktiv ausgenutzt? Eine theoretische Schwachstelle ohne bekannten Exploit hat eine niedrigere Priorität als eine, für die Metasploit-Module existieren.

Exposition: Ist das betroffene System aus dem Internet erreichbar? Aus dem Büronetzwerk? Oder nur aus dem segmentierten OT-Netzwerk? Je stärker das System isoliert ist, desto geringer ist das effektive Risiko.

Relevanz: Betrifft die Schwachstelle eine Funktion, die auf deinem System tatsächlich aktiv ist? Ein Patch für einen Dienst, den du nicht nutzt und der deaktiviert ist, hat keine Priorität.

Schritt 2: Auswirkung des Patches bewerten

Parallel zur Schwachstelle bewertest du die Auswirkung des Patches:

Reboot erforderlich? Wenn ja, brauchst du ein Wartungsfenster. Wenn nein, kann der Patch möglicherweise im laufenden Betrieb installiert werden (aber selbst dann nur nach Herstellerfreigabe).

Herstellerfreigabe vorhanden? Ohne Freigabe des SCADA- oder SPS-Herstellers solltest du den Patch nicht installieren. Prüfe die Hersteller-Website oder kontaktiere den Support.

Produktionskritikalität des Systems: Ein Patch auf einem unkritischen Monitoring-System ist weniger riskant als ein Patch auf dem zentralen SCADA-Server, der die gesamte Produktion steuert.

Schritt 3: Entscheidung treffen

Basierend auf der Bewertung gibt es vier mögliche Entscheidungen:

Sofort patchen (nächstes Wartungsfenster): Hohe Schwachstellen-Kritikalität, hohe Exposition, Herstellerfreigabe vorhanden. Beispiel: Kritische Remote-Code-Execution auf dem SCADA-Server, der aus dem Büronetzwerk erreichbar ist. Hersteller hat den Patch freigegeben.

Geplant patchen (nächster regulärer Patch-Zyklus): Mittlere Kritikalität oder geringe Exposition. Beispiel: Medium-Schwachstelle auf einem HMI-Panel, das nur aus dem OT-Netzwerk erreichbar ist. Kann beim nächsten geplanten Stillstand gepatcht werden.

Compensating Controls statt Patch: Der Patch ist nicht verfügbar (veraltetes Betriebssystem), nicht freigegeben (Hersteller hat noch nicht getestet) oder das Risiko eines Patches ist höher als das Risiko der Schwachstelle. Stattdessen werden alternative Schutzmaßnahmen implementiert.

Risiko akzeptieren: Die Schwachstelle ist unkritisch, das System ist gut isoliert und die Exposition ist minimal. Das Risiko wird dokumentiert und akzeptiert. Diese Entscheidung muss bewusst getroffen und im Rahmen der Risikobewertung im ISMS dokumentiert werden, nicht einfach vergessen.

Schritt 4: Dokumentieren

Jede Entscheidung wird dokumentiert. Für jeden Patch bzw. jede Schwachstelle:

• Welches System ist betroffen?
• Wie wurde die Schwachstelle bewertet?
• Welche Entscheidung wurde getroffen?
• Wer hat die Entscheidung getroffen?
• Wann wird der Patch installiert (falls geplant)?
• Welche Compensating Controls wurden implementiert (falls Patch nicht möglich)?
• Wann wird die Entscheidung überprüft?

Diese Dokumentation ist nicht nur für das ISMS wichtig, sondern auch für Audits. In ISMS Lite lassen sich Firmware-Versionen, offene Schwachstellen und die zugehörigen Compensating Controls pro OT-Asset erfassen und nachverfolgen. Ein Auditor wird nicht verlangen, dass jedes OT-System immer auf dem neuesten Stand ist. Aber er wird verlangen, dass du einen nachvollziehbaren Prozess hast und jede Entscheidung begründen kannst.

Compensating Controls: Wenn Patchen nicht geht

Compensating Controls sind alternative Sicherheitsmaßnahmen, die das Risiko einer ungepatchten Schwachstelle auf ein akzeptables Maß reduzieren. Sie sind in der OT-Welt nicht die Ausnahme, sondern die Regel.

Netzwerksegmentierung

Die wirksamste Compensating Control ist Netzwerksegmentierung: Wenn ein System nicht gepatcht werden kann, isoliere es so weit wie möglich. Ein SCADA-Server mit Windows 7, der in einem segmentierten OT-Netzwerk steht und nur über einen Jump-Server erreichbar ist, hat ein deutlich geringeres Risiko als derselbe Server im Büronetzwerk.

Konkrete Maßnahmen: Firewall-Regeln verschärfen, nur die minimal nötigen Verbindungen zulassen, direkten Zugriff aus dem Büronetzwerk blockieren, den Server in ein eigenes VLAN mit dedizierten Firewall-Regeln stellen.

Application Whitelisting

Wenn du keine Patches installieren kannst, stelle sicher, dass nur autorisierte Software auf dem System läuft. AppLocker (Windows) oder vergleichbare Tools erlauben nur die Ausführung von Programmen, die auf einer Whitelist stehen. Selbst wenn ein Angreifer eine Schwachstelle ausnutzt, kann er keinen eigenen Code ausführen, weil die Whitelist das verhindert.

Erhöhtes Monitoring

Richte gezieltes Monitoring für ungepatchte Systeme ein. Überwache den Netzwerkverkehr von und zu diesen Systemen besonders aufmerksam. Konfiguriere Alerts für ungewöhnliche Kommunikationsmuster: neue Verbindungen, unbekannte Protokolle, Zugriffe außerhalb der normalen Arbeitszeiten.

Zugriffsbeschränkung

Beschränke den Zugriff auf ungepatchte Systeme auf das absolute Minimum. Entferne alle Benutzerkonten, die nicht benötigt werden. Deaktiviere alle Netzwerkdienste, die nicht benötigt werden. Wenn ein System eine verwundbare Komponente hat, die nicht genutzt wird, deaktiviere sie.

Physische Isolation

Für extrem kritische oder extrem verwundbare Systeme: Trenne sie physisch vom Netzwerk. Eine SPS, die auf einer Firmware aus dem Jahr 2010 läuft und sicherheitsrelevante Funktionen steuert, hat möglicherweise nichts im Netzwerk zu suchen. Sie kann über eine direkte serielle Verbindung zur Engineering-Workstation programmiert werden, ohne dass ein Netzwerkzugang nötig ist.

Wartungsfenster effektiv nutzen

Geplante Produktionsstillstände (Betriebsferien, Wochenend-Wartung, Schichtwechsel) sind die Gelegenheit, Patches zu installieren. Damit das reibungslos funktioniert, brauchst du einen klaren Prozess:

Vorbereitung (2-4 Wochen vorher)

• Patch-Backlog prüfen: Welche Patches stehen an?
• Herstellerfreigaben einholen
• Reihenfolge festlegen: Welches System wird zuerst gepatcht?
• Rollback-Plan erstellen: Was passierst, wenn der Patch ein Problem verursacht? Wie stellst du den vorherigen Zustand wieder her?
• Backups aller betroffenen Systeme erstellen und verifizieren
• Personal einplanen: Wer patcht, wer überwacht, wer ist für den Rollback zuständig?
• Zeitplan erstellen: Wann wird gestartet, wann muss fertig sein?

Durchführung

• Backup unmittelbar vor dem Patching nochmals prüfen
• Patch installieren
• Funktionstest durchführen: Läuft die SCADA-Software noch korrekt? Kommuniziert der Server mit den SPS? Sind alle Alarme aktiv?
• System freigeben oder Rollback durchführen

Nachbereitung

• Dokumentation aktualisieren: Firmware-Version, Patch-Datum, durchführende Person
• Monitoring in den Tagen nach dem Patching verstärken
• Auffälligkeiten melden und bewerten

Der regulatorische Rahmen für OT-Patch-Management

NIS2

NIS2 fordert in Artikel 21 ein Risikomanagement, das explizit „Schwachstellenmanagement und Schwachstellenoffenlegung" umfasst. Das bedeutet: Du musst einen nachweisbaren Prozess haben, mit dem du Schwachstellen in deinen Systemen identifizierst, bewertest und behandelst. Ob du einen Patch installierst oder Compensating Controls einsetzt, ist zweitrangig. Entscheidend ist, dass du eine bewusste, dokumentierte Entscheidung triffst.

EU-Maschinenverordnung 2023/1230

Die Maschinenverordnung fordert ab 2027, dass Maschinen mit digitalen Elementen während ihres gesamten Lebenszyklus sicher sein müssen. Für Maschinenhersteller bedeutet das: Sie müssen Sicherheitsupdates bereitstellen. Für Maschinenbetreiber bedeutet das: Sie müssen diese Updates einspielen oder begründen, warum sie es nicht tun.

Die Verordnung ergänzt damit den Cyber Resilience Act, der ebenfalls Sicherheitsupdates über den gesamten Produktlebenszyklus fordert. Für den Mittelstand entsteht daraus eine klare Erwartungshaltung: OT-Systeme müssen gepflegt werden, und „wir patchen nicht, weil das immer so war" ist keine akzeptable Position mehr.

IEC 62443

Der IEC-62443-Standard liefert detaillierte Anforderungen an das Patch-Management in OT-Umgebungen. Insbesondere IEC 62443-2-3 (Patch-Management in der IACS-Umgebung) beschreibt einen strukturierten Prozess, der als Orientierung dienen kann.

Ein realistischer OT-Patch-Prozess

Hier ein Prozess, der für mittelständische Unternehmen praktikabel ist:

Monatlich: Schwachstellen-Review. Prüfe die Veröffentlichungen der relevanten Hersteller (Siemens ProductCERT, Rockwell Security Advisories, Schneider Electric Security Notifications etc.) und die ICS-CERT-Advisories. Bewerte jede relevante Schwachstelle nach dem oben beschriebenen Schema.

Quartalsweise: Patch-Zyklus. Installiere die freigegebenen und bewerteten Patches während des nächsten geplanten Wartungsfensters. Aktualisiere die Compensating Controls für nicht patchbare Systeme.

Jährlich: Strategische Überprüfung. Welche Systeme sind am Ende des Lebenszyklus? Wo laufen veraltete Betriebssysteme, die nicht mehr gepatcht werden? Gibt es Investitionsbedarf für Modernisierung?

Sofort (bei kritischen Schwachstellen): Wenn eine kritisch bewertete Schwachstelle mit aktiver Ausnutzung veröffentlicht wird, die deine Systeme betrifft: Sofortige Bewertung, sofortige Compensating Controls (auch wenn der Patch erst im nächsten Wartungsfenster installiert werden kann), gegebenenfalls außerplanmäßiges Wartungsfenster.

Informationsquellen für OT-Schwachstellen

Ein OT-Patch-Prozess funktioniert nur, wenn du über neue Schwachstellen informiert bist. In der IT-Welt gibt es dafür etablierte Kanäle (Microsoft Patch Tuesday, CVE-Datenbanken, Vulnerability-Scanner). In der OT-Welt sind die Informationsquellen verstreuter, aber sie existieren:

Hersteller-spezifische Advisories

Die großen OT-Hersteller veröffentlichen eigene Security Advisories:

Abonniere die Advisories aller Hersteller, deren Produkte du im Einsatz hast. Die meisten bieten E-Mail-Benachrichtigungen oder RSS-Feeds an.

ICS-CERT und CISA

Die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) veröffentlicht regelmäßig ICS Advisories für Schwachstellen in industriellen Steuerungssystemen. Diese Advisories sind herstellerübergreifend und oft die schnellste Quelle für neue OT-Schwachstellen. In Europa veröffentlicht ENISA ergänzende Informationen, und das BSI gibt eigene Warnmeldungen für kritische OT-Schwachstellen heraus.

CVE-Datenbanken und Schwachstellen-Scanner

Spezialisierte OT-Schwachstellen-Datenbanken wie die Dragos WorldView Threat Intelligence oder die Claroty xDome Vulnerability Database bieten detaillierte Informationen über OT-spezifische Schwachstellen, einschließlich Bewertung der Ausnutzbarkeit und verfügbarer Patches oder Workarounds.

Passives OT-Monitoring (wie in einem früheren Abschnitt beschrieben) kann zudem automatisch bekannte CVEs den in deinem Netzwerk identifizierten Geräten und Firmware-Versionen zuordnen. Das ersetzt die manuelle Prüfung zwar nicht vollständig, reduziert den Aufwand aber erheblich.

End-of-Life-Systeme: Die größte Herausforderung

Besonders schwierig wird es bei Systemen, die das Ende ihres Lebenszyklus erreicht haben. Wenn der Hersteller keine Sicherheitsupdates mehr bereitstellt, gibt es genau drei Optionen:

Option 1: Ablösung. Das System wird durch ein aktuelles System ersetzt. Das ist die technisch sauberste Lösung, aber oft die teuerste. Die Ablösung einer Maschinensteuerung kann mehrere hunderttausend Euro kosten und erfordert wochen- oder monatelange Planung und Inbetriebnahme.

Option 2: Virtual Patching. Statt das System selbst zu patchen, wird der Schutz auf die Netzwerkebene verlagert. Eine Firewall oder ein IPS vor dem System filtert den Netzwerkverkehr und blockiert bekannte Angriffsmuster. Das funktioniert gut für netzwerkbasierte Angriffe, schützt aber nicht gegen lokale Angriffe (USB, physischer Zugang).

Option 3: Maximale Isolation. Das System wird so weit wie möglich vom Netzwerk isoliert. Nur die absolut notwendigen Verbindungen bleiben bestehen, und diese werden über eine dedizierte Firewall mit minimalen Regeln geführt. Ergänzend: Application Whitelisting auf dem System, physische Zugangskontrollen und erhöhtes Monitoring.

Für jedes End-of-Life-System sollte in deinem ISMS eine dokumentierte Entscheidung vorliegen, welche Option gewählt wurde und warum. Diese Entscheidung muss regelmäßig (mindestens jährlich) überprüft werden: Hat sich die Bedrohungslage verändert? Gibt es neue Angriffsvektoren? Ist eine Ablösung inzwischen wirtschaftlich sinnvoll geworden?

Typische Fehler vermeiden

Alles oder nichts. Der häufigste Fehler: Weil Patchen in der OT so komplex ist, wird es gar nicht gemacht. Ein imperfekter Prozess ist besser als kein Prozess. Auch wenn du nur die kritischsten Patches auf den exponiertesten Systemen installierst, ist das ein enormer Fortschritt gegenüber dem Status quo.

Keine Dokumentation. Du installierst Patches, aber dokumentierst nicht, was du getan hast. Beim nächsten Audit oder beim nächsten Vorfall fehlen die Informationen. Dokumentiere jeden Patch-Vorgang und jede Entscheidung, einen Patch nicht zu installieren.

Compensating Controls vergessen. Du entscheidest, einen Patch nicht zu installieren, setzt aber keine Compensating Controls um. Die Schwachstelle bleibt offen und ungeschützt. Jede Entscheidung gegen einen Patch muss mit mindestens einer Compensating Control verbunden sein.

Herstellerabstimmung vernachlässigen. Du installierst einen Patch ohne Herstellerfreigabe, und die SCADA-Software stürzt ab. Oder du wartest auf eine Freigabe, die nie kommt, weil du nie gefragt hast. Etabliere einen regelmäßigen Kommunikationskanal mit deinen wichtigsten OT-Herstellern.

Keine Rollback-Planung. Du installierst einen Patch, und das System verhält sich danach anders als erwartet. Ohne Rollback-Plan stehst du vor der Wahl: Mit dem Problem leben oder den Patch manuell rückgängig machen (mit dem Risiko, die Situation zu verschlimmern). Ein aktuelles Backup und ein dokumentierter Rollback-Prozess sind Pflicht.

Weiterführende Artikel

• OT-Sicherheit im Mittelstand: Warum die Produktionssteuerung ins ISMS gehört
• SCADA und SPS absichern: Praxismaßnahmen ohne Produktionsstopp
• Purdue-Modell erklärt: Netzwerkzonen in der Produktion
• Risikobewertung für OT-Systeme: Andere Prioritäten als in der IT
• EU-Maschinenverordnung 2023/1230: Cybersecurity-Anforderungen ab 2027