Die 5 gefährlichsten Sätze in Industrieunternehmen

Wie unspektakulär Angriffe auf industrielle Systeme, beziehungsweise kritische Infrastruktur, beginnen können, zeigte sich in den letzten Jahren immer wieder. Zuletzt in den USA, als mehrere Wasserversorgungssysteme in Minnesota koordiniert angegriffen wurden.

Auch wenn Minnesota weit weg ist, unterstreicht dieser Vorfall ein grenzübergreifendes Grundproblem der vernetzten Industrie: Zwischen Norm und Produktionsanlage liegt eine Übersetzungsaufgabe, die oft unbearbeitet bleibt.

Entsprechend sollten auch europäische und deutsche Industrieunternehmen – und speziell KRITIS-Betreiber – ihre Lehren aus diesem Vorfall ziehen. Schließlich fallen auch dort bestimmte, potenziell besorgniserregende Sätze erstaunlich häufig. Zum Beispiel:

• „Eigentlich gibt es eine DMZ.“
• „Eigentlich dürfen externe Techniker nur nach Freigabe zugreifen.“
• „Eigentlich werden alle kritischen Systeme gepatcht.“
• „Eigentlich weiß der Krisenstab, was im Ernstfall zu tun ist.“

Das Problem: Geht es um industrielle Cybersicherheit, ist „eigentlich“ kein Füllwort, sondern ein Warnsignal. Es markiert die Lücke zwischen dem dokumentierten Sicherheitskonzept und dem, was in der Werkshalle tatsächlich abläuft.

5 Sätze, die potenzielle OT-Security-Mängel signalisieren

Insofern sollten (Security-)Führungskräfte im industriellen Umfeld mindestens hellhörig werden, wenn sie eine der folgenden Aussagen vernehmen.

1. „Unsere OT ist vom Internet getrennt“

Die Vorstellung vom abgeschotteten Produktionsnetz hält sich hartnäckig. In der Realität ist der klassische Air Gap in vielen Werken längst Geschichte.

Produktionsanlagen liefern Daten an MES-Systeme, Datenbanken und Cloud-Dashboards. Engineering-Laptops wechseln zwischen Netzen. Hersteller benötigen Fernzugriff. IIoT-Sensoren senden Zustandsdaten an Analyseplattformen. Software wird aus zentralen Systemen in die Produktion übertragen.

Keine dieser Verbindungen muss für sich genommen unsicher sein. Gefährlich wird es jedoch, wenn die Organisation nichts von deren Existenz weiß – oder wenn aus einer temporären Projektlösung ein dauerhafter Zugang wird.

Typische Beispiele sind Mobilfunkrouter an abgelegenen Stationen, herstellereigene VPN-Tunnel, zusätzliche Netzwerkkarten in Engineering-Rechnern oder auch Remote-Desktop-Software, die während der Inbetriebnahme installiert und danach nie wieder entfernt wurde. Unter solchen Bedingungen ist das Produktionsnetz nicht wirklich isoliert. Es weist lediglich Verbindungen auf, die im offiziellen Architekturdiagramm fehlen.

Gleichzeitig sind industrielle Anlagen häufig für Laufzeiten von 15 bis 25 Jahren ausgelegt. Viele Komponenten stammen entsprechend aus einer Zeit, in der weder Cloud-Anbindungen noch industrielle Ransomware Teil des Bedrohungsmodells waren. Die OT ist deshalb nicht unsicher – sie wurde lediglich für andere Anforderungen konzipiert.

Ein belastbares Zonenkonzept sollte daher nicht nur zeigen, welche Netze existieren. Es muss jede einzelne Verbindung erklären. Also, wer diese zu welchem Zweck nutzen darf, welches Gateway und welche Authentifizierungsmaßnahmen dabei zum Einsatz kommen und was im Fall einer Kompromittierung geschehen soll.   

Eine DMZ sollte nicht nur ein farbiges Rechteck in einer PowerPoint-Folie sein, sondern eine Grenze, die technisch durchgesetzt wird.

2. „Wir sind doch ISO-27001-zertifiziert“

Ein Zertifikat sagt zunächst nur aus, dass ein definierter Geltungsbereich geprüft wurde. Die entscheidende Frage lautet deshalb, was in diesen Geltungsbereich fällt – und was nicht.

Ein ISMS kann formal hervorragend funktionieren und gleichzeitig die Produktionsanlagen weitgehend ausklammern. Die Office-IT ist inventarisiert, Risiken sind bewertet, Richtlinien freigegeben und interne Audits durchgeführt.

Doch die Engineering-Workstations, Steuerungsinstanzen, Fernwartungsrouter und Maschinennetzwerke werden häufig als OT- oder auch als Herstelleraufgabe angesehen. Angreifer interessieren sich allerdings nicht für diese organisatorische Grenzziehung.

Insofern wirkt die Scope-Diskussion oft abstrakt, entscheidet aber darüber, ob ein Unternehmen die richtigen Risiken managt. Es geht nicht darum, wie viele Systeme sich möglichst bequem in den Geltungsbereich aufnehmen lassen.

Eher um die Frage: Welche Systeme können die Wertschöpfung, die Compliance oder die Sicherheit von Mensch und Umwelt wesentlich beeinflussen? Das kann eine SPS sein. Es kann aber auch ein schlecht segmentiertes WLAN, ein Etikettendrucker oder ein Dienstleister-Laptop sein, über den ein Zugriffsweg auf kritische Produktionssysteme entsteht.

Ein Scope, der nur das Rechenzentrum umfasst und die Werkshalle ausblendet, mag zunächst komfortabel sein. Aber eben nur so lange, bis der erste Incident beweist, dass eine Cyberattacke nicht an der Brandschutztür zur Produktion endet.

ISO 27001 enthält alle wesentlichen Bausteine. Das Problem besteht also in den meisten Fällen nicht darin, dass eine Kontrollinstanz fehlt. Sondern darin, dass diese nicht in die industrielle Realität übersetzt wurde.

Genau an dieser Stelle trennt sich Papier-Compliance von wirksamer Sicherheit. Die Norm beschreibt, was erreicht werden soll. Die Organisation muss definieren, welches Dokument die Umsetzung steuert und wie die Maßnahme in einer realen OT-Umgebung funktioniert.

Dieser Dreiklang aus Norm, Dokumentenvorgabe und OT-Praxis-Transfer verhindert, dass ein ISMS nur im Rahmen eines Audits überzeugt.

3. „Wir müssen einfach schneller patchen“

Diese Forderung erfolgt vor allem nach Security-Vorfällen reflexartig. Geht es um Office-IT, ist ein zügiger Patch-Prozess auch sinnvoll. Im Hinblick auf Operational Technology ist das anders, denn ein ungetestetes Update kann selbst zum Risiko für Produktion und Security werden. Zum Beispiel, wenn:

• ein Patch für eine Engineering-Workstation die Kommunikation mit einer Steuerungseinheit beeinflusst.
• eine neue Firmware Einfluss auf Zertifizierungen oder Herstellerfreigaben nimmt.
• in einer kontinuierlich laufenden Anlage ein aufwendiger Leerfahrprozess nötig wird, um ein Update zu installieren.

Das bedeutet im Umkehrschluss nicht, dass OT-Systeme ungepatcht bleiben sollten. Lediglich, dass verfügbare Patches nicht automatisch sofort installiert werden sollten.

Um in diesem Zusammenhang richtig zu priorisieren, ist der Kontext zu berücksichtigen: Ist das System vom Internet aus oder über das Office-Netz erreichbar? Ist eine Authentifizierung erforderlich? Wird die betreffende Schwachstelle bereits aktiv ausgenutzt? Sind geschäftskritische Assets dadurch in Gefahr? Existieren zusätzliche Schutzschichten? Gibt es eine getestete Fallback-Option?

Eine kritische Schwachstelle auf einem isolierten System hinter mehreren Barrieren kann weniger dringlich sein als eine mit niedrigem Severity-Score auf einem öffentlich erreichbaren Fernwartungs-Gateway. Der CVSS-Wert alleine liefert schließlich keinen Anhaltspunkt über die jeweils zugrundeliegende Architektur oder die konkreten Folgen eines Stillstands in der Produktion.

Bei einer akuten Angriffswelle besteht die erste Maßnahme deshalb nicht zwangsläufig darin, zu patchen. Zunächst müssen direkte Exponierungen beseitigt, unbekannte Fernzugänge identifiziert, kompromittierbare Zugangsdaten geändert und kontrollierte Übergänge eingerichtet werden.

Wo ein Update nicht kurzfristig möglich ist, braucht es dokumentierte Kompensationsmaßnahmen – etwa Segmentierung, Zugriffsbeschränkungen, Application Whitelisting, passives Monitoring oder eine vorgelagerte Sicherheitskomponente.

Oder anders formuliert: OT-Patchmanagement ist keine verlangsamte Variante des IT-Patchmanagements, sondern stellt eine eigene Risikodisziplin dar.

4. „Der Hersteller braucht diesen VPN-Zugang“

Maschinenhersteller und spezialisierte Dienstleister benötigen Zugriff auf manche Anlagen. Es gibt wohl kein Industrieunternehmen, das in der Lage ist, sämtliche Störungen und Vorfälle vollständig ohne externe Unterstützung zu beheben.

Aus dieser betrieblichen Notwendigkeit entsteht jedoch häufig eine permanente Ausnahme: Der Hersteller erhält einen dauerhaften VPN-Tunnel, ein gemeinsam genutztes Konto oder eine eigene Remote-Desktop-Lösung.

Was als schneller Workaround im Rahmen der Inbetriebnahme beginnt, bleibt anschließend dann nicht selten jahrelang aktiv. Externe Zugänge dieser Art mögen zwar bequem sein, sind aber kaum steuerbar.

Schließlich wissen Unternehmen nicht genau, wer diesen Zugang beim Dienstleister konkret nutzt, von welchem Gerät dabei zugegriffen wird, ob Subauftragnehmer beteiligt sind oder welche Systeme tatsächlich darüber erreichbar sind.

Wird das Netz des Dienstleisters dann kompromittiert, haben die Angreifer auch einen direkten Weg in die Produktionsumgebung.

Die Alternative ist nicht das Ende der Fernwartung, sondern Just-in-Time-Zugriff: Ein externer Techniker erhält eine individuelle Identität, authentifiziert sich über einen zweiten Faktor und beantragt den Zugriff für einen konkreten Auftrag.

Eine verantwortliche Person im Werk genehmigt anschließend den Zugriff auf das Zielsystem, definiert, wie das protokolliert wird und legt ein Zeitfenster für den Task fest. Die Verbindung läuft über einen zentralen Session-Broker und einen Jump-Host in der OT-DMZ. Nach Ablauf des gesetzten Zeitrahmens wird diese automatisch beendet.

Das gewährleistet auch, dass das Zielsystem niemals direkt über das Internet erreichbar ist. Ein herstellereigenes VPN darf den kontrollierten Zugangsweg ebenso wenig umgehen, wie ein dauerhaft offener RDP- oder SSH-Zugang. Zu empfehlen ist deshalb ein Modell, das MFA, Genehmigungs-Workflows, zentrale Vermittlung, Scope-Begrenzung und Session Recording miteinander verbindet.

Ein solcher Prozess erzeugt zunächst Aufwand, beseitigt aber einen der größten Risikofaktoren in OT-Umgebungen: Stehende Zugriffsrechte, die niemand mehr aktiv benötigt und deren Missbrauch sehr wahrscheinlich auch niemand bemerken würde.

5. „Im Ernstfall trennt das SOC das System vom Netz“

In der IT ist die schnelle Isolation eines kompromittierten Endgeräts häufig die richtige Reaktion. In der OT kann dieselbe Maßnahme eine Anlage stoppen, die Überwachung eines Prozesses unterbrechen oder einen sicheren Betriebszustand gefährden.

So entsteht das „Containment-Paradox“: Die Maßnahme, die den Cyberangriff eindämmen soll, kann größere physische Folgen auslösen als der Angriff selbst. Dennoch enthalten viele Incident-Response-Pläne keine klare Antwort auf eine zentrale Frage: Wer darf entscheiden, dass eine Steuerung isoliert, eine Produktionslinie gestoppt oder ein Schutzsystem vom Netz getrennt wird?

Bleibt dieser Punkt ungeregelt, landet diese Entscheidung im Ernstfall beim diensthabenden SOC-Analysten. Dieser ist zwar möglicherweise mit dem Angriff selbst vertraut, aber nicht mit der Anlage. Diejenigen die die Anlage betreiben, kennen dagegen den Prozess, verfügen jedoch meist nicht über das vollständige Cyberlagebild.

Diese Lücke sollte vor potenziellen Incidents geschlossen werden. Dabei kann etwa ein „No-Touch“-Register helfen. Dieses identifiziert Systeme, an denen auch seitens des SOC keine unilateralen Containment-Maßnahmen durchgeführt werden dürfen. Für jedes dieser Systeme werden Asset Owner, zulässige Maßnahmen, Eskalationszeit, sicherer Rückfallzustand sowie Entscheidungsbefugnis festgelegt.

In einem möglichen RACI-Modell führt das SOC die technische Maßnahme aus, während der Asset Owner aus der Produktion oder dem Anlagenbetrieb die abschließende Verantwortung trägt. Der CISO wird konsultiert, die Geschäftsleitung informiert.

Das ist kein Veto gegen schnelle Reaktion. Es ist die Voraussetzung dafür, Geschwindigkeit nicht mit Blindflug zu verwechseln. Eine gute Incident Response beginnt nicht mit einem Playbook im Krisenordner. Sondern mit Entscheidungen, die getroffen wurden, lange bevor der kritische Alert um drei Uhr nachts aufschlägt.

Wie der Audit die Werkshalle erreicht

Ob ein ISMS tatsächlich funktioniert, lässt sich nicht alleine anhand von Richtlinien und Risikoregistern feststellen. Ein OT-Audit sollte deshalb mehrere Ebenen verbinden und folgende Komponenten beinhalten:

• Dokumentenprüfung,
• Begehung und Interviews,
• passive technische Stichproben,
• Tabletop-Übungen, sowie
• ein Reporting mit konkreten Verantwortlichkeiten und Fristen.

Gerade die Begehung zeigt häufig, was kein Policy-Portal abbildet – etwa offene Schaltschränke, nicht gesperrte Engineering-Stationen, USB-Sticks an HMIs, unbekannte Mobilfunkrouter oder externe Techniker ohne Begleitung.

Technische Prüfungen sollten in der laufenden Produktion grundsätzlich nach dem Prinzip „passiv vor aktiv“ erfolgen. Unabgestimmte Scans oder Penetrationstests auf den unteren Steuerungsebenen sind kein Beweis besonderer Prüftiefe, sondern unter Umständen ein zusätzliches Risiko für Anlagen.

Die aufschlussreichste Prüfung ist häufig eine 90-minütige Tabletop-Übung. Innerhalb kurzer Zeit wird damit sichtbar, ob der Krisenstab zusammenfindet, wer über einen Anlagenstillstand entscheidet, welche Kommunikationswege funktionieren und ob regulatorische Meldevorlagen tatsächlich griffbereit sind. Ein Audit, das nur überprüft, ob ein Verfahren existiert, misst Dokumentation. Ein Audit, das überprüft, ob Menschen unter realistischen Bedingungen danach handeln können, misst Sicherheit.

Ein wirksames industrielles ISMS muss auch dann Antworten liefern, wenn ein System nicht kurzfristig gepatcht werden kann. Es ist deshalb mehr als nur eine Sammlung freigegebener Dokumente. Es ist ein Entscheidungssystem, das dabei unterstützt, wichtige Fragen zu beantworten. Zum Beispiel:

• Wer schützt was?
• Wer darf worauf zugreifen?
• Wer genehmigt Änderungen?
• Wer hat Restrisiken akzeptiert?
• Wer entscheidet im Fall eines Incidents?
• Welche Nachweise bleiben erhalten?

Die Qualität eines ISMS zeigt sich nicht daran, wie ordentlich seine Richtlinien aussehen. Sie zeigt sich in dem Moment, in dem die Produktion unter Druck gerät. Denn der Angreifer hält sich weder an den Audit-Scope noch an die Brandschutztür. Deshalb darf es das ISMS auch nicht. (fm)

Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!