Zero Trust in der Industrie 4.0: Schutz, der mit deiner Angriffsfläche wächst

Das Ausgangsproblem: OT wurde nicht für Vernetzung gebaut

Operational Technology in der Energieversorgung, in Wasserwerken, in der Verkehrsinfrastruktur oder im Gesundheitswesen hat einen grundlegenden Konstruktionsfehler aus heutiger Perspektive: Sie wurde für Verfügbarkeit und Prozessstabilität entwickelt, nicht für Sicherheit gegen Cyberangriffe. Steuerungssysteme auf Basis proprietärer Protokolle wie Modbus, Profibus oder DNP3 liefen jahrzehntelang in physisch isolierten Umgebungen. Der sogenannte Air Gap, die physische Trennung vom Internet, war das primäre Sicherheitskonzept.

Diese Isolation existiert in der Form nicht mehr. Die zunehmende IT/OT-Konvergenz, ausgelöst durch Fernwartungsanforderungen, Effizienzprogramme und die Integration von Smart Grid, SCADA und industriellen IoT-Komponenten, hat die Grenzen aufgelöst. Was früher eine Produktionsinsel war, ist heute über ZTNA-Gateways, Cloud-Backends und Wartungs-VPNs mit der Außenwelt verbunden. Und damit angreifbar.

Das Purdue Enterprise Reference Architecture Model (PERA), lange Zeit der konzeptuelle Rahmen für OT-Sicherheit, beschreibt eine klare Zonierung in Ebenen: von der Feldgeräteebene über die Steuerungsebene bis hin zur Unternehmens-IT. Theorie und Praxis klaffen hier weit auseinander. In der Praxis überspringen Wartungszugänge, Remote-Dienste und Datenintegrationspfade diese Zonen. Angreifer:innen auch.

Was Zero Trust bedeutet und wo der Begriff herkommt

Den Begriff „Zero Trust“ prägte John Kindervag 2010 während seiner Zeit als Analyst bei Forrester Research. Die Kernthese: Kein Gerät, kein Nutzer, keine Verbindung darf allein aufgrund seiner Netzwerklokation als vertrauenswürdig gelten. Weder innerhalb noch außerhalb des Perimeters. Vertrauen muss explizit und kontinuierlich hergestellt werden, nicht implizit vorausgesetzt.

Das National Institute of Standards and Technology (NIST) hat diesen Rahmen 2020 mit der SP 800-207 formalisiert. Drei Kernprinzipien stehen im Zentrum: „Verify explicitly“ bedeutet, dass jede Zugriffsanfrage anhand von Identität, Gerätekontext und Verhalten geprüft wird. „Use least privilege access“ begrenzt Berechtigungen strikt auf das, was für eine Aufgabe erforderlich ist. „Assume breach“ geht davon aus, dass eine Kompromittierung bereits stattgefunden haben kann, und entwirft Architekturen, die laterale Bewegungen innerhalb des Netzwerks verhindern.

Die CISA (Cybersecurity and Infrastructure Security Agency) hat darauf aufbauend ein Zero Trust Maturity Model entwickelt, das fünf Säulen definiert: Identity, Devices, Networks, Applications and Workloads sowie Data. Diese Säulen beschreiben, wo Zero Trust-Kontrollen ansetzt und in welcher Reihenfolge eine Reifegradentwicklung sinnvoll ist.

Warum KRITIS ein besonderes Problem hat

KRITIS-Betreiber stehen vor Einschränkungen, die in der klassischen IT-Welt so nicht vorkommen.

Zero Trust in der OT-Praxis: Was funktioniert und was nicht

Die direkte Übertragung von IT-seitigen Zero Trust-Architekturen auf OT-Umgebungen scheitert in der Regel. Ein Industrieregler kann kein Software-Agenten ausführen. Eine SPS unterstützt keine MFA. Ein SCADA-System toleriert keine Latenzen durch kontinuierliche Authentifizierungsprüfungen, wenn Echtzeitsteuerung erforderlich ist.

Das bedeutet aber nicht, dass Zero Trust-Prinzipien in OT-Umgebungen nicht umsetzbar sind. Es bedeutet, dass die Implementierung angepasst werden muss.

Wie der Einstieg gelingt: risikoorientiert, nicht maximal

Zero Trust ist kein Schalter, den man umlegt. Es ist ein Reifegradprozess. Der häufigste Fehler ist der Versuch, das gesamte Architekturkonzept auf einmal umzusetzen. Das scheitert an Ressourcen, an Legacy-Systemen und an der Komplexität der Abhängigkeiten.

Der richtige Ansatz ist risikobasiert: Welche Assets sind kritisch? Welche Zugänge sind am stärksten exponiert? Welche lateralen Bewegungspfade im Netz wären für Angreifer:innen am lukrativsten? Diese Fragen beantwortet eine strukturierte Risikoanalyse nach BSI IT-Grundschutz oder ISO 27001. Auf Basis dieser Antworten lässt sich eine Zero Trust-Roadmap entwickeln, die mit den wirkungsvollsten Maßnahmen beginnt und sukzessive ausbaut.

Das CISA Zero Trust Maturity Model beschreibt fünf Entwicklungsstufen je Säule: Traditional, Initial, Advanced, Optimal. Kein KRITIS-Betreiber muss auf Anhieb „Optimal“ erreichen. Ein klar definierter Ausgangszustand und ein realistischer Zielpfad sind wertvoller als eine ambitionierte Architektur, die in der Umsetzung steckenbleibt.

Fazit

Zero Trust für KRITIS ist kein Projekt, das du abschließt. Es ist eine Haltung gegenüber Sicherheit, die du in Architekturentscheidungen, Betriebsprozesse und Beschaffungsstrategien einbettest. Wer heute damit beginnt, gewinnt drei Dinge gleichzeitig: eine deutlich reduzierte Angriffsfläche durch Mikrosegmentierung und granulare Zugriffskontrollen, eine nachweisbare Erfüllung der NIS2-Anforderungen mit auditfähiger Evidenz, und die operative Sicherheit, dass ein erfolgreicher Einbruch in eine Teilinfrastruktur nicht zur vollständigen Kompromittierung der Gesamtanlage führt.

Sicherheit entsteht nicht durch den perfekten Perimeter. Sie entsteht durch die Annahme, dass der Perimeter bereits gefallen ist, und durch Architekturen, die genau darauf ausgelegt sind.