Patch Deployment in KRITIS-Systemen

© Feodora

Patch Deployment KRITIS: Warum Standardprozesse nicht reichen

Patch Deployment in KRITIS-Umgebungen folgt anderen Regeln als in gewöhnlichen IT-Landschaften. Systeme, die Strom, Wasser oder Gesundheitsversorgung steuern, dürfen nicht einfach für ein Update heruntergefahren werden. Laut heise online sind die gemeldeten Cybersicherheitsvorfälle bei KRITIS-Betreibern um 43 Prozent gestiegen. Gleichzeitig haben 250 Betreiber noch kein Angriffserkennungssystem implementiert. Die Grundlage für jeden strukturierten Patching-Prozess bildet die Übersicht zum Patch Management mit ihrem Fünf-Schritte-Modell. Im KRITIS-Kontext muss dieses Modell allerdings um spezifische Anforderungen erweitert werden: Verfügbarkeitsanforderungen, OT-Besonderheiten und regulatorische Nachweispflichten. Der Leitfaden zum IT-Service-Management ordnet das Patch Deployment in den übergreifenden ITSM-Rahmen ein.

Wie unterscheidet sich OT Patch Management von klassischem IT-Patch-Management?

OT Patch Management unterscheidet sich vom klassischen IT-Patching in fast jeder Hinsicht. In der IT gelten kurze Patch-Zyklen, automatisierte Rollouts und schnelle Neustarts als Standard. In OT-Umgebungen — also bei Steuerungsanlagen, SCADA-Systemen und industriellen Leitsystemen — sieht die Realität anders aus. Die wesentlichen Unterschiede:

• IT-Systeme lassen sich in der Regel kurzfristig neu starten — OT-Systeme laufen oft jahrelang ohne Unterbrechung
• IT-Patches kommen direkt vom Hersteller — OT-Patches erfordern zusätzliche Freigaben durch Anlagenbauer
• IT nutzt standardisierte Betriebssysteme — OT basiert häufig auf proprietären oder veralteten Plattformen
• IT-Tests laufen in Staging-Umgebungen — OT-Tests erfordern physische oder digital gespiegelte Anlagenmodelle
• IT priorisiert nach CVSS-Score — OT muss zusätzlich die Auswirkung auf den physischen Prozess bewerten

Die Patch-Management-Strategie liefert den methodischen Rahmen für die Priorisierung. Wie sich Sicherheitspatches speziell in heterogenen Umgebungen einspielen lassen, beschreibt der vertiefende Leitfaden.

Patch-Prozess und KRITIS: Von der Risikobewertung bis zum Rollout

Der Patch-Prozess in KRITIS folgt dem Grundmuster Erkennen, Bewerten, Testen, Ausrollen und Verifizieren. In kritischen Infrastrukturen gewinnt jedoch jede Phase an Gewicht. BSI-Grundschutz-Baustein OPS.1.1.3 verlangt dokumentierte Bewertung, definierte Zeitfenster und revisionssichere Protokollierung aller Schritte. Das Enterprise Patch Management beschreibt, wie dieser Prozess in Konzernstrukturen skaliert. Für KRITIS-Betreiber kommen OT-spezifische Anforderungen hinzu, die den Patch-Prozess KRITIS von allgemeinen ITSM-Abläufen unterscheiden.

OT Patch Management: Patch-Test und Freigabe

Bevor ein Patch auf ein produktionskritisches System ausgerollt wird, muss die Testphase drei Fragen beantworten: Beeinflusst der Patch die Verfügbarkeit? Verändert er das Verhalten der Steuerung? Ist er mit der vorhandenen OT-Firmware kompatibel? Ein strukturierter Patch-Test in OT-Umgebungen umfasst:

• Funktionstest in einer isolierten Spiegelumgebung
• Kompatibilitätsprüfung mit allen angeschlossenen Sensoren und Aktoren
• Regressionstests für vorhandene Steuerungslogik
• Lasttest unter produktionsnahen Bedingungen
• Dokumentation der Testergebnisse für den Audit-Nachweis

Ein klar definierter Wartungsvertrag regelt, wer die Testumgebung betreibt und wer die Freigabe erteilt. In der Praxis zeigt sich, dass OT Patch Management für KRITIS-Betreiber ohne dedizierte Testinfrastruktur kaum revisionssicher abbildbar ist.

Risikobewertung nach CVSS und Geschäftskritikalität

Die Risikobewertung im KRITIS-Umfeld geht über den reinen CVSS-Score hinaus. Ein Patch mit Score 7.5 kann in einem öffentlich erreichbaren Webserver dringend sein — und bei einer Steuerungsanlage ohne Internetverbindung nachrangig. Entscheidend ist die Kombination aus technischer Schwere und Auswirkung auf den physischen Prozess. Für KRITIS-Betreiber empfiehlt das BSI eine Bewertung nach drei Dimensionen: Schweregrad der Schwachstelle, Erreichbarkeit des betroffenen Systems und potenzielle Auswirkung auf die Versorgungssicherheit. Ein Supportvertrag mit KRITIS-erfahrenen Fachkräften kann diese Risikobewertung deutlich beschleunigen.

Wie lässt sich ein Patch-Rollout ohne Betriebsunterbrechung in kritischen Infrastrukturen umsetzen?

Ein Patch-Rollout ohne Betriebsunterbrechung in KRITIS erfordert redundante Architekturen und sorgfältige Planung der Wartungsfenster. Viele KRITIS-Betreiber setzen auf gestaffelte Rollouts: Erst werden unkritische Subsysteme gepatcht, dann die Kernkomponenten — idealerweise während geplanter Wartungsintervalle. Parallele Systeme im Hot-Standby ermöglichen den Wechsel ohne Unterbrechung der Versorgung. Ein durchdachtes Service-Level-Agreement definiert dabei die Zeitfenster und Eskalationswege. Die konkrete Umsetzung hängt vom Sektor ab: In der Energieversorgung gelten andere Rhythmen als im Gesundheitswesen. Für Sicherheitsupdates für OT-Systeme in der Industrie bieten sich produktionsfreie Zeiträume wie Revisionsintervalle an.

Welche kompensierenden Maßnahmen gelten für KRITIS-Systeme, die nicht gepatcht werden können?

Kompensierende Maßnahmen für nicht patchbare KRITIS-Systeme sind kein Notbehelf, sondern fester Bestandteil jeder KRITIS-Sicherheitsstrategie. Legacy-Steuerungssysteme, Embedded Devices oder SCADA-Komponenten ohne Herstellersupport lassen sich oft schlicht nicht aktualisieren. In diesen Fällen fordert das BSI dokumentierte Ersatzmaßnahmen, die das Restrisiko auf ein akzeptables Niveau senken. Dazu gehört die konsequente Einhaltung von IT-Compliance-Vorgaben. Bewährte Ansätze:

• Strikte Netzwerksegmentierung zwischen gepatchten und ungepatchten Systemen
• Erhöhtes Monitoring mit Anomalie-Erkennung auf dem betroffenen Netzsegment
• Zugangssteuerung auf Basis des Least-Privilege-Prinzips
• Regelmäßige Prüfung, ob ein Patch oder Systemwechsel inzwischen möglich ist
• Dokumentation und Genehmigung jeder kompensierenden Maßnahme durch die Sicherheitsverantwortlichen

Die Nachweisführung über kompensierende Maßnahmen für nicht patchbare KRITIS-Systeme ist bei jedem BSI-Audit Pflicht.

Netzwerksegmentierung als Schutzschicht

Netzwerksegmentierung ist die wichtigste kompensierende Maßnahme für Systeme ohne Patch-Option. Sie trennt OT-Systeme physisch oder logisch vom restlichen Netzwerk und verhindert, dass ein kompromittiertes IT-System zum Sprungbrett in die Steuerungsebene wird. In einem Patch Deployment in kritischen Produktionsumgebungen sorgt die Segmentierung zusätzlich dafür, dass fehlgeschlagene Patches keine Kettenreaktion in angrenzenden Anlagenbereichen auslösen. Die Zonierung sollte sich am Purdue-Modell orientieren und die Übergänge zwischen den Zonen mit Firewalls und Monitoring absichern. Auch Systeme, die regelmäßig gepatcht werden, profitieren von einer klaren Zonentrennung.

Patch Deployment für KRITIS und BSI-Compliance

KRITIS-Betreiber unterliegen strengen Nachweispflichten. § 8a BSIG verpflichtet zur Umsetzung angemessener technischer und organisatorischer Maßnahmen — das Patch Deployment gehört dazu. Seit dem NIS-2-Umsetzungsgesetz gelten verschärfte Dokumentations- und Meldepflichten, die den gesamten Patching-Prozess für KRITIS betreffen. Das BSI prüft im Rahmen von Audits nicht nur, ob gepatcht wurde, sondern ob der Patch-Prozess KRITIS-Anforderungen strukturell erfüllt. Ein fehlender Nachweis wiegt im Audit genauso schwer wie ein fehlender Patch. BSI-konforme Patch-Dokumentation für Audits ist daher kein optionaler Zusatz, sondern Grundvoraussetzung für den Weiterbetrieb.

BSI-konforme Patch-Dokumentation für Audits

Auditoren des BSI erwarten eine lückenlose Dokumentation des gesamten Patch-Lebenszyklus. Jeder einzelne Schritt — von der Erkennung einer Schwachstelle bis zur Verifikation des eingespielten Patches — muss nachvollziehbar protokolliert sein. Ein revisionssicheres Patch-Reporting umfasst:

• Zeitstempel für Erkennung, Bewertung, Test und Rollout jedes Patches
• Begründung bei Abweichungen von den definierten Fristen
• Testergebnisse mit Freigabevermerk der verantwortlichen Stelle
• Dokumentation kompensierender Maßnahmen bei nicht patchbaren OT-Systemen
• Nachweis der Wirksamkeitsprüfung nach erfolgtem Rollout

Diese Daten müssen jederzeit abrufbar sein. Patch-Management-Software mit integriertem Compliance-Modul automatisiert die Erhebung und macht manuelle Nacharbeit überflüssig.

KRITIS-Patch-Bereitstellung als fortlaufender Prozess

Patch Deployment in KRITIS ist kein einmaliges Projekt. Die Bedrohungslage ändert sich laufend, neue Schwachstellen betreffen OT-Systeme ebenso wie IT-Komponenten. Ein wirksames OT Patch Management für KRITIS-Betreiber lebt davon, dass Rollen, Abläufe und Werkzeuge regelmäßig überprüft und angepasst werden. Quartalsweise Reviews der Patch-Richtlinie, Aktualisierungen des Asset-Inventars und Übungen für den Notfall-Patch-Prozess gehören zum Pflichtprogramm.

Der BSI-Grundschutz empfiehlt zudem, den gesamten Patching-Prozess für KRITIS mindestens einmal jährlich durch unabhängige Dritte prüfen zu lassen. Wer Patch Deployment für KRITIS-Systeme als fortlaufenden Verbesserungsprozess versteht, bleibt handlungsfähig — auch wenn die nächste kritische Schwachstelle kommt.