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 langfristige Architektur 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 Sichtbarkeit erst dann möglich ist, wenn die gesamte Architektur fertiggestellt ist.
Nur wenige OT-Sicherheitsprogramme fangen bescheiden an.
Der anfängliche Umfang umfasst häufig eine verbesserte Erfassung von Systemressourcen, 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, Umspannwerken oder Aufbereitungsanlagen erstrecken.
Dieses Ziel ist keineswegs unrealistisch. Die meisten der vorgeschlagenen Kontrollmaßnahmen sind in irgendeinem Bereich der Umwelt notwendig.
Die Schwierigkeit liegt in der Reihenfolge.
Um die gesamte Architektur bereitzustellen, müssen die Teams zunächst die Technologie 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 nur wenige Male im Jahr zur Verfügung stehen. Produktionsteams benötigen die Gewissheit, dass die Überwachung die Verfügbarkeit nicht beeinträchtigt. 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 Hersteller, der plant, die OT-Überwachung an 18 Produktionsstandorten zu verbessern.
Das zentrale Sicherheitsteam entwickelt eine umfassende Architektur. An den relevanten Grenzen werden Netzwerksensoren installiert, zusätzliche Firewalls werden 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 beginnen die Standortbegutachtungen. Ein Werk verfügt über eine moderne Vermittlungsinfrastruktur 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 Stillstandsfenster erst in vier Monaten. An einem anderen Standort bereitet sich das lokale Team auf die Inbetriebnahme einer neuen Verpackungslinie vor und wird keine zusätzlichen Änderungen akzeptieren, bis sich die Produktion stabilisiert hat.
Die Architektur ist nach wie vor sinnvoll, kann jedoch nicht als ein einziges, einheitliches Projekt umgesetzt werden.
Dies ist in der Ergotherapie üblich. 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 weiß 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 Sicherheitsmaßnahmen. 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 Bereitstellung 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 der Umwelt 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 Transparenz 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 Transparenz 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 Kontrollmaßnahmen 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äßig verteilen, obwohl das operative Risiko nicht gleichmäßig verteilt ist.
Eine kleine Abwasseranlage mit begrenztem lokalem IT-Support kann andere Herausforderungen hinsichtlich der Transparenz mit sich bringen als ein hochautomatisiertes Pharmawerk. Ein Umspannwerk mit vorhersehbaren Kommunikationsmustern erfordert einen anderen Überwachungsansatz als ein Produktionsstandort, an dem sich OEMs regelmäßig 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 toten Winkel erfordern tatsächlich zusätzliche Sensoren oder andere Kontrollvorrichtungen?
Diese Fragen grenzen den Bereich ein, in dem größere Investitionen getätigt werden müssen.
Wenn die vorhandenen Netzwerk-Metadaten bereits ein aussagekräftiges Bild für einen Großteil 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 fließt, 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 Entwicklerteams 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 Verstoß 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 Architektur vorzustellen, die weitgehend auf zentralen Annahmen beruht.
Außerdem 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 Architektur.
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 Architektur als Fachrichtung 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. 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 Vermögenswerte und Kommunikationswege identifiziert
- Kritische Produktionsabhängigkeiten validiert
- Überprüfung der Fernzugriffsverbindungen
- Annahmen zur Segmentierung bestätigt oder korrigiert
- Für zusätzliche Kontrollen ausgewählte Schwerpunktstandorte
- OT- und SOC-Teams arbeiten auf der Grundlage einer gemeinsamen operativen Sichtweise
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 große 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 Transparenz 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 Beschaffungsmaßnahmen, 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 Kontrollmaßnahmen und spezielle Sensoren am sinnvollsten sind.
- Eine Phase, in der die Transparenz 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.
Leitfaden zur Bewertung der OT-Sicherheit
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.
