Viele OT-Sicherheitsprogramme sind auf eine umfassende Abdeckung ausgelegt, doch es dauert oft Monate, bis Beschaffungsprozesse, Wartungsfenster und produktionstechnische Einschränkungen geklärt sind. Durch eine gezieltere Vorgehensweise lassen sich nützliche Erkenntnisse früher gewinnen, ohne die Sicherheitsarchitektur langfristig zu beeinträchtigen.
Warum kommen OT-Sicherheitsprojekte ins Stocken? Erfahren Sie, wie ein zu ehrgeiziger Projektumfang, produktionstechnische Einschränkungen und das Streben nach vollständiger Abdeckung sinnvolle Verbesserungen verzögern.
Das Problem ist selten ein Mangel an Ehrgeiz. Es ist vielmehr die Annahme, dass eine aussagekräftige Visibilität erst dann möglich ist, wenn der gesamte Sicherheitsapparat fertiggestellt ist.
Nur wenige OT-Sicherheitsprogramme fangen bescheiden an.
Der anfängliche Umfang umfasst häufig eine verbesserte Erfassung von Assets, Netzwerksegmentierung, einen sichereren Fernzugriff, zusätzliche Firewalls, neue Überwachungsfunktionen sowie die Integration in das Security Operations Center. Bei einem Hersteller mit mehreren Standorten oder einem Betreiber kritischer Infrastrukturen kann sich das Vorhaben auf Dutzende von Werken, Umspannwerke oder Aufbereitungsanlagen erstrecken.
Dieses Ziel ist keineswegs unrealistisch. Die meisten der vorgeschlagenen Kontrollmassnahmen sind in einem gewissen Bereich der Umwelt notwendig.
Die Schwierigkeit liegt in der Reihenfolge.
Um die gesamte Sicherheitsarchitektur bereitzustellen, müssen die Teams zunächst die Technologien auswählen, Netzwerkstandorte festlegen, Hardware beschaffen, sich auf Datenflüsse einigen, sich mit den Geräteherstellern abstimmen und Genehmigungen für Änderungen einholen. Die Installation erfordert unter Umständen physischen Zugang zu entfernten Standorten oder Wartungsfenster, die sich nur wenige Male im Jahr öffnen. Produktionsteams benötigen Gewissheit, dass die Überwachungssysteme die Betriebsbereitschaft der Produktionsanlage nicht beeinträchtigen. Auch Betriebsräte, Datenschutzteams und Infrastrukturverantwortliche müssen unter Umständen einbezogen werden.
Bis die ersten aussagekräftigen Informationen das Sicherheitsteam erreichen, kann es sein, dass die Vorbereitung des Programms bereits Monate gedauert hat.
Das Projekt ist nicht gescheitert. Möglicherweise tun alle Beteiligten genau das, was die Betriebsumgebung erfordert. Dennoch bestehen die blinden Flecken, die die Investition gerechtfertigt haben, während der gesamten Planungsphase fort.
Ein vernünftiger Plan erreicht die Mindestanforderungen
Nehmen wir einen Produktionsbetrieb, der plant, die OT-Überwachung an 18 Produktionsstandorten zu verbessern.
Das zentrale Sicherheitsteam entwickelt eine umfassende Sicherheitsarchitektur. An den relevanten Zonengrenzen werden Netzwerksensoren installiert, zusätzliche Firewalls sollen die Segmentierung verstärken
und Warnmeldungen werden in das bestehende SOC eingespeist. Das Programm zielt auf eine lückenlose Abdeckung und ein einheitliches Betriebsmodell an allen Standorten ab.
Dann beginnt die Standortbegutachtung. Ein Werk verfügt über eine moderne Übermittlungsinfrastruktur und ein gut dokumentiertes Netzwerk. Ein anderes betreibt Anlagen, die über zwei Jahrzehnte hinweg schrittweise erweitert wurden.
Ein drittes Werk ist bei Netzwerkänderungen auf einen externen Integrator angewiesen. In einem Werk liegt das nächste geeignete Stilllegungsfenster erst in vier Monaten. An einem anderen Standort bereitet sich das lokale Team auf die Inbetriebnahme einer neuen Verpackungslinie vor und kann keine zusätzlichen Änderungen akzeptieren, bis sich die Produktion stabilisiert hat.
Die geplante Sicherheitsarchitektur ist nach wie vor sinnvoll, kann jedoch nicht als ein einziges, einheitliches Projekt umgesetzt werden.
Dies gilt für Betriebe mit einem hohen OT-Anteil am Netzwerk. Standardisierung mag ein legitimes Ziel sein, doch der Weg dorthin unterscheidet sich je nach Einrichtung.
Behandelt man jeden Standort so, als sei er technisch und betrieblich gleichwertig, führt dies in der Regel zu mehr Planungsaufwand, mehr Ausnahmen und mehr Koordinationsaufwand.
Unterdessen kann das zentrale Team einige seiner ursprünglichen Fragen nach wie vor nicht beantworten. Es weiss nicht, welche nicht dokumentierten Systeme miteinander kommunizieren,
wo Fernwartungswege bestehen oder ob die angenommenen Netzwerkgrenzen den aktuellen Datenverkehr widerspiegeln.
Das Bedürfnis nach Transparenz ist zu einem Bestandteil der Abhängigkeitskette für die Bereitstellung von Transparenz geworden.
Warum „vollständig“ ein teurer Ausgangspunkt ist
In IT-Umgebungen lässt sich die Einbindung von Sicherheitstelemetrie häufig durch die Bereitstellung von Software oder durch Konfigurationsänderungen bewerkstelligen.
Im OT-Bereich gelten andere Rahmenbedingungen.
Ein Agent wird möglicherweise auf einer technischen Arbeitsstation, auf der eine herstellerspezifische Konfiguration läuft, nicht unterstützt.
Aktives Scannen ist für empfindliche Geräte möglicherweise ungeeignet. Das Hinzufügen eines Sensors kann Änderungen an der Switching-Infrastruktur, der physischen Installation und der Validierung erfordern
, um sicherzustellen, dass die Netzwerkleistung nicht beeinträchtigt wird. Selbst eine technisch unkomplizierte Änderung muss sich mit Produktionsplänen und lokalen technischen Prioritäten vereinbaren lassen.
Das sind keine Anzeichen für Widerstand gegen Sicherheitsmassnahmen. Es handelt sich vielmehr um die normalen Folgen des Schutzes von Umgebungen, in denen Verfügbarkeit, Sicherheit und Prozessintegrität an erster Stelle stehen.
Probleme entstehen, wenn der Erfolg eines Programms in erster Linie anhand der Vollständigkeit der geplanten Installation definiert wird. Ein Team verbringt möglicherweise Monate damit, eine nahezu vollständige Abdeckung zu planen
, bevor es über genügend aktuelle Informationen verfügt, um zu erkennen, wo diese Abdeckung am wichtigsten ist.
Das Streben nach Vollständigkeit kann zudem eine grundlegendere Frage verschleiern: Welche Teile des Netzwerks lassen sich bereits anhand der heute verfügbaren Daten beobachten?
Firewalls, Switches, Router, Fernzugriffssysteme und bestehende OT-Sicherheitsplattformen liefern möglicherweise bereits nützliche Informationen über Ressourcen und Kommunikationsflüsse. Diese liefern zwar möglicherweise nicht alle Protokolldetails und decken nicht jedes einzelne Segment ab, bieten jedoch einen Ausgangspunkt, ohne dass man auf die endgültige Architektur warten muss.
Teilweise Visibilität ist nicht dasselbe wie teilweises Engagement. Richtig eingesetzt, ist sie eine Möglichkeit, die Entscheidungen zu verbessern, die dem gesamten Programm zugrunde liegen.
Das Problem ist selten ein Mangel an Ehrgeiz. Es ist vielmehr die Annahme, dass eine sinnvolle Visibilität erst dann möglich ist, wenn die vollständige Einführung abgeschlossen ist.
Die Kosten bestehen nicht nur in Verzögerungen
Der offensichtlichste Aufwand einer langen Planungsphase ist Zeit. Der weniger offensichtliche Aufwand besteht darin, dass sich das Umfeld während der Ausarbeitung des Plans ständig weiter verändert.
Ein Lieferant erhält während der Inbetriebnahme vorübergehend Zugriff. Eine neue MES-Schnittstelle stellt die Kommunikation zwischen der Produktion und einem Anwendungsserver her. Während der Wartungsarbeiten wird eine Ausnahme in der Firewall hinzugefügt. Ein Laptop des Engineering-Teams wird zwischen verschiedenen Produktionslinien hin- und herbewegt. Keine dieser Änderungen wartet auf die Sicherheits-Roadmap.
Im Laufe des Programms besteht die Gefahr, dass die Teams Kontrollmassnahmen auf der Grundlage eines zunehmend veralteten Bildes der Umgebung umsetzen.
Zudem besteht ein Investitionsrisiko. Ohne Erkenntnisse über die aktuellen Kommunikationsmuster lässt sich nur schwer feststellen, wo zusätzliche Sensoren, Segmentierungsmaßnahmen oder Verbesserungen beim Fernzugriff das Risiko am stärksten verringern würden. Das Programm könnte die Technologie gleichmässig verteilen, obwohl das operative Risiko nicht gleichmässig verteilt ist.
Eine kleine Abwasseranlage mit begrenztem lokalem IT-Support kann andere Herausforderungen hinsichtlich der Visibilität mit sich bringen als ein hochautomatisiertes Pharmawerk. Ein Umspannwerk mit vorhersehbaren Kommunikationsmustern erfordert einen anderen Überwachungsansatz als ein Produktionsstandort, an dem sich OEMs regelmässig während Wartungsfenstern einloggen.
Eine einheitliche Zielarchitektur kann diese Unterschiede berücksichtigen. Eine einheitliche Bereitstellungsreihenfolge ist dazu in der Regel nicht in der Lage.
Beginnen Sie mit den Fragen, die Entscheidungen beeinflussen
Ein praktischerer Ansatzpunkt ist nicht die Frage „Wie setzen wir die gesamte Sicherheitsarchitektur um?“, sondern „Was müssen wir lernen, bevor wir sie fertigstellen?“
Für viele Programme sollte eine aussagekräftige Ausgangsbasis Antworten auf Fragen wie die folgenden liefern:
- Welche Assets kommunizieren derzeit?
- In welchen Netzwerkzonen und an welchen Standortgrenzen wird der relevanteste Datenverkehr übertragen?
- Wo gibt es Zusammenhänge, die in der Dokumentation nicht berücksichtigt sind?
- Über welche Fernzugriffswege erfolgt der Zugriff auf kritische Produktionssysteme?
- Wo kann die vorhandene Infrastruktur ausreichende Telemetriedaten liefern?
- Welche blinde Flecken erfordern tatsächlich zusätzliche Sensoren oder andere Kontrollvorrichtungen?
Diese Fragen grenzen den Bereich ein, in dem grössere Investitionen getätigt werden müssen.
Wenn die vorhandenen Netzwerk-Metadaten bereits ein aussagekräftiges Bild für einen Grossteil des Standorts liefern, können spezialisierte Sensoren für Bereiche reserviert werden, in denen Kontext auf Protokollebene oder zusätzliche Details zu den Systemen erforderlich sind. Wenn die beobachtete Kommunikation zeigt, dass über eine vermeintliche Grenze nur wenig Datenverkehr fliesst, kann die Segmentierung einfacher ausfallen als erwartet. Wenn ein undokumentierter OEM-Pfad mehrere kritische Systeme erreicht, könnte der Fernzugriff eine höhere Priorität erhalten als ursprünglich geplant.
Das daraus resultierende Programm ist nach wie vor umfassend. Es berücksichtigt lediglich die Rahmenbedingungen, bevor die einschneidendsten und kostspieligsten Entscheidungen getroffen werden.
Fortschritt ohne Produktionsrisiken
Früher anzufangen bedeutet nicht, unüberlegt zu handeln.
OT-Teams sind zu Recht vorsichtig bei allem, was die Produktion beeinträchtigen könnte. Eine „Visibility-First“-Phase muss daher dieselben betrieblichen Grundsätze beachten wie das Gesamtprogramm: Die Einführung unnötigen Datenverkehrs ist zu vermeiden, passive Datenquellen sind nach Möglichkeit zu nutzen, und es muss klar vereinbart werden, wie Informationen erfasst, gespeichert und abgerufen werden.
Das Ziel besteht nicht darin, die lokalen Ingenieurteams zu umgehen oder die Bereitstellung auf deren Kosten zu beschleunigen. Tatsächlich verbessert eine frühzeitige Transparenz oft die Zusammenarbeit mit ihnen.
Ein zentrales Sicherheitsteam könnte einen unerwarteten Kommunikationspfad als potenziellen Verstoss gegen die Richtlinien betrachten. Ein Werksingenieur könnte darin hingegen die Verbindung erkennen, die ein OEM während der vierteljährlichen Wartungsarbeiten nutzt. Keine der beiden Sichtweisen ist für sich genommen ausreichend. Durch die gemeinsame Analyse des beobachteten Verhaltens kann das Team eine undokumentierte, aber legitime Abhängigkeit von einem Zugriff unterscheiden, der einfach länger als beabsichtigt offen geblieben ist.
Dieses Gespräch ist produktiver, als dem Werk eine fertige Sicherheitsarchitektur vorzustellen, die weitgehend auf zentralen Annahmen beruht.
Ausserdem schafft dies Vertrauen. Die Teams vor Ort erkennen, dass der Zweck der Überwachung nicht darin besteht, Kontrollen aufzuerlegen, ohne die Produktion zu verstehen, sondern Unsicherheiten zu verringern, bevor Änderungen vorgenommen werden.
Architektur als Ausrichtung, nicht als Voraussetzung
Nichts davon spricht gegen eine auf Langfristigkeit ausgerichtete Sicherheitsarchitektur.
Industrieunternehmen benötigen nach wie vor einheitliche Ansätze für Segmentierung, Fernzugriff, Überwachung, Reaktion auf Vorfälle und Sicherheitsabläufe. Umgebungen mit mehreren Standorten lassen sich nicht auf Dauer durch isolierte lokale Lösungen steuern. Standards sind von entscheidender Bedeutung, insbesondere wenn Unternehmen ein einheitliches Kontrollrahmenwerk über viele Standorte hinweg nachweisen müssen.
Es wird unterschieden zwischen Sicherheitsarchitektur als Selbstzweck und Architektur als Voraussetzung für das Lernen.
Wenn jede Entwurfsentscheidung, jeder Beschaffungsschritt und jede Standortabhängigkeit geklärt sein muss, bevor eine aussagekräftige Übersicht vorliegt, verschiebt das Programm die Informationen, die es am dringendsten benötigt nach hinten. Wird hingegen frühzeitig eine Übersicht geschaffen, kann die Architektur unter realen Bedingungen getestet und angepasst werden, bevor die Umsetzung kostspielig wird.
Dadurch ändert sich die Art und Weise, wie der Fortschritt gemessen wird.
Anstatt lediglich die Anzahl der eingerichteten Standorte oder installierten Sensoren zu erfassen, kann das Programm konkrete Verbesserungen erfassen:
- Bisher unbekannte Assets und Kommunikationswege identifiziert
- Kritische Produktionsabhängigkeiten validiert
- Fernzugriffsverbindungen überprüft.
- Annahmen zur Segmentierung bestätigt oder korrigiert
- Schwerpunktstandorte für zusätzliche Kontrollen ausgewählt.
- Gemeinsame operative Sichtweise für OT- und SOC-Teams geschaffen.
Diese Ergebnisse ersetzen zwar nicht die Reichweitenkennzahlen, zeigen jedoch, ob das Programm im Zuge seiner Ausweitung dazu beiträgt, Unsicherheiten abzubauen.
In der richtigen Reihenfolge investieren
Die wichtigste Erkenntnis ist nicht, dass grosse OT-Sicherheitsprogramme kleiner werden sollten. Vielmehr geht es darum, dass sie ihren Nutzen früher unter Beweis stellen sollten.
Ein Programm erfordert möglicherweise noch zusätzliche Firewalls, eine spezialisierte OT-Überwachung, strengere Zugriffskontrollen und eine engere Integration in den Sicherheitsbetrieb. An einigen Standorten wird eine neue Infrastruktur benötigt. An anderen Standorten ist eine sorgfältige Implementierung während geplanter Abschaltungen erforderlich.
Diese Investitionen lassen sich leichter rechtfertigen, wenn das Unternehmen aufzeigen kann, wo die aktuellen Risiken und Abhängigkeiten liegen.
Bei Exeon betrachten wir passive Visibilität als Mittel zur Unterstützung dieser ersten Phase und zur Verknüpfung der bereits verfügbaren Informationen aus der Netzwerk- und Sicherheitsinfrastruktur. Sie ist kein Ersatz für spezialisierte OT-Tools oder eine langfristige Architektur. Ihre Aufgabe besteht darin, Unternehmen dabei zu helfen, erste Erkenntnisse zu gewinnen, noch bevor alle Elemente des endgültigen Designs implementiert sind.
Die Sicherheit im operativen Bereich wird immer mit betrieblichen Einschränkungen verbunden sein. Wartungsfenster werden weiterhin begrenzt sein, Altsysteme lassen sich nur schwer ändern, und die lokalen Gegebenheiten werden sich auch weiterhin unterscheiden. Die Lösung besteht nicht darin, diese Realitäten zu ignorieren, sondern die Programme entsprechend darauf auszurichten.
Die robusteste Architektur ist nicht unbedingt diejenige, deren ursprünglicher Umfang am umfassendsten geplant wurde. Es ist vielmehr jene, die die Erkenntnisse der Organisation aufnehmen kann, sobald die tatsächlichen Rahmenbedingungen sichtbar werden.
Die wichtigsten Erkenntnisse
- Sicherheitsprojekte im Bereich der operativen Technik (OT) kommen oft ins Stocken, da eine umfassende Abdeckung von Beschaffungsmassnahmen, Netzwerkänderungen, Wartungsfenstern und standortspezifischer Koordination abhängt.
- Vorsicht bei der Umsetzung ist zwar angebracht, doch muss man nicht immer auf die endgültige Architektur warten, um einen nützlichen Überblick zu erhalten.
- Die vorhandene Infrastruktur kann oft einen ersten Überblick bieten, der dabei hilft, festzustellen, wo zusätzliche Kontrollmassnahmen und spezielle Sensoren am sinnvollsten sind.
- Eine Phase, in der die Visibilität im Vordergrund steht, verringert das Investitionsrisiko, indem die Programmschwerpunkte auf beobachteten Abhängigkeiten zwischen Kommunikation und Produktion abgestützt werden.
- Eine langfristig angelegte Struktur ist nach wie vor unverzichtbar, erweist sich jedoch eher als Leitlinie für das Programm denn als Voraussetzung für das Lernen.
Weiterlesen
OT-Sicherheit ohne zusätzlichen Aufwand
Wie können Unternehmen eine sinnvolle Transparenz im Bereich OT schaffen, ohne auf ein mehrjähriges Transformationsprogramm warten zu müssen?
Laden Sie das Whitepaper„OT-Sicherheit ohne zusätzlichen Aufwand“ herunter, um einen praktischen Ansatz zum Aufbau von Transparenz, zur Überprüfung der Segmentierung und zur Verbesserung der Vorkehrungen für den Fall von Vorfällen kennenzulernen – unter Berücksichtigung der betrieblichen Einschränkungen industrieller Umgebungen.
OT Security Evaluation Guide
Planen Sie eine Investition in die OT-Sicherheit oder überprüfen Sie ein bestehendes Programm? DerLeitfaden zur Bewertung der OT-Sicherheit bietet einen strukturierten Rahmen für die Beurteilung des Abdeckungsumfangs, der Bereitstellungsanforderungen, des betrieblichen Kontexts und der Möglichkeit, auf der bestehenden Infrastruktur aufzubauen.
