Konzept-Demo. Die Domain maschinenbau.digital wird vergeben. Anfragen: info@johannesfaupel.com
Alle dargestellten Inhalte sind Demo-Inhalte zur Visualisierung.
OT-Security · Patches

OT-Patch-Management: Sicherheit und Verfügbarkeit in Balance

Patches in OT-Systemen zu spielen ist komplexer als in der IT: Herstellerfreigaben, Gewährleistungsklauseln, geplante Wartungsfenster und die Risikoabwägung zwischen Patch-Risiko und Exploit-Risiko bestimmen jeden Update-Entscheid.

Patch ManagementOT-SecurityIEC 62443-2-3Wartungsfenster

Das Dilemma des OT-Patch-Managements: Ungepatchte Systeme sind angreifbar, aber das Einspielen von Patches in laufende Produktionssysteme birgt Risiken – fehlgeschlagene Updates, Inkompatibilitäten mit Steuerungssoftware und unerwartete Verhaltensänderungen können den Produktionsbetrieb stören. Dennoch ist „niemals patchen" keine akzeptable Strategie.

Warum OT-Patching schwierig ist

Vier strukturelle Probleme unterscheiden OT-Patching von IT-Patching:

  1. Lange Systemlaufzeiten: SPS-Systeme und SCADA-Server laufen häufig 10–20 Jahre ohne Neustart. Windows-Server im OT-Netz sind oft auf alten Versionen (Windows XP, Windows Server 2008) eingefroren.
  2. Herstellerfreigaben: SCADA-Softwarelieferanten müssen OS-Patches testen und freigeben, bevor sie offiziell installiert werden können. Dieses Verfahren dauert oft 2–6 Monate nach dem Microsoft Patch Tuesday.
  3. Gewährleistungsklauseln: Einige Maschinenhersteller heben die Gewährleistung auf, wenn ungenehmigte Software (einschließlich OS-Patches) auf der Maschinensteuerung installiert wird.
  4. Begrenzte Wartungsfenster: Maschinen mit 24/7-Betrieb haben selten mehr als 4–6 Stunden Wartungsfenster pro Jahr.

Priorisierungsrahmen für OT-Patches

Nicht jeder Patch muss sofort eingespielt werden. Ein risikobasierter Ansatz priorisiert nach CVSS-Score und Netzwerkposition:

PrioritätKriterienZielfrist
KritischCVSS ≥ 9.0 UND System internet-exponiert oder DMZ-seitigNächstes verfügbares Wartungsfenster (<7 Tage)
HochCVSS 7.0–8.9 ODER aktiv exploitiert (CISA KEV)Nächste geplante Wartung (<30 Tage)
MittelCVSS 4.0–6.9, kein bekannter ExploitNächste Quartartswartung (<90 Tage)
NiedrigCVSS < 4.0 oder kein NetzwerkvektorJährliche Revision

Kompensierende Maßnahmen bei nicht-patchbaren Systemen

Wenn ein System aus technischen oder vertraglichen Gründen nicht zeitnah gepatcht werden kann, sind kompensierende Maßnahmen (Compensating Controls) einzuführen:

  • Netzwerkisolierung: Das ungepatchte System in ein eigenes VLAN mit stark eingeschränkten Kommunikationsbeziehungen verschieben
  • Application Whitelisting: Auf dem ungepatchten Windows nur vorab genehmigter Code darf ausgeführt werden (AppLocker, Carbon Black)
  • Monitoring intensivieren: Das System erhält erhöhte IDS-Aufmerksamkeit und Logging
  • Virtuelle Patches: Netzwerk-Firewall oder IPS blockt bekannte Exploit-Payloads auf Netzwerkebene

Patch-Testumgebung im OT-Kontext

Kritische Patches sollten vor dem Produktions-Deployment in einer Testumgebung validiert werden. Für SCADA-Systeme bedeutet das: eine gespiegelte Testinstanz des SCADA-Servers mit simulierten oder aufgezeichneten Datenpunkten. Wer einen Digitalen Zwilling (→ VIBN) für seine Anlage besitzt, kann Patches in der virtuellen Umgebung testen, bevor sie auf der Echtanlage eingespielt werden.