Warum Sicherheitsprojekte im Bereich „ OT “ ins Stocken geraten, bevor sie Ergebnisse liefern

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 Sicherheitsprojekte im Bereich „ OT “ ins Stocken? Erfahren Sie, wie ehrgeizige „ Umfang “, 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 Sicherheitsprogramme für „ OT “ 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 bleiben die „ blinde Flecken “, die die Investition gerechtfertigt haben, während der gesamten Planungsphase bestehen.

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 ist in „ OT “ gang und gäbe. Standardisierung mag ein legitimes Ziel sein, doch der Weg dorthin unterscheidet sich je nach Standort.
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 festen Bestandteil der „Abhängigkeit “-Kette zur Gewährleistung von Transparenz geworden.

Warum „vollständig“ ein teurer Ausgangspunkt ist

In „ IT “-Umgebungen lässt sich das Hinzufügen von Sicherheits Telemetrie en oft über Software Bereitstellung oder Konfigurationsänderungen bewerkstelligen.
OT bringt eine Reihe anderer Einschränkungen mit sich.

Ein „ agent “ wird möglicherweise auf einer Entwicklungs-Workstation nicht unterstützt, auf der eine von „ Hersteller “ gesteuerte Konfiguration ausgeführt wird.
„Active Scan “ ist für empfindliche Geräte möglicherweise ungeeignet. Das Hinzufügen eines „ sensor “ 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 Entwicklungsprioritä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 Sicherheitsplattformen vonOT liefern möglicherweise bereits nützliche Informationen über assets und Kommunikationsflüsse. Diese liefern zwar möglicherweise nicht alle Protokolldetails und decken auch 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übergehenden Zugriff. Ein neuerMES Schnittstelle stellt die Kommunikation zwischen der Produktion und einem Anwendungsserver her. Während der Wartung wird eine firewall -Ausnahme hinzugefügt. Ein Laptop des Engineering-Teams wird zwischen den Fertigungslinien 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 Reihenfolge der „ Bereitstellung “ 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 „ Telemetrie “ bereitstellen? 

• 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 Die Teams sind zu Recht vorsichtig bei allem, was die Produktion beeinträchtigen könnte. Eine Phase, in der Transparenz im Vordergrund steht, muss daher dieselben operativen Grundsätze beachten wie das Gesamtprogramm: Die Erzeugung 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, Vorfall Reaktion und Sicherheitsabläufe. Umgebungen mit mehreren Standorten lassen sich nicht auf Dauer durch isolierte lokale Lösungen steuern. Standards sind wichtig, insbesondere wenn Unternehmen ein einheitliches Kontroll framework ü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. 

• Segmentierung Annahmen 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 unter Umständen noch zusätzliche Firewalls, eine spezialisierte Überwachung der „ OT “, strengere Zugriffskontrollen und eine tiefere Integration in den Sicherheitsbetrieb. An einigen Standorten wird eine neue Infrastruktur benötigt. An anderen sind sorgfältige „ Bereitstellung “ während geplanter Ausfallzeiten 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. 

OT Sicherheit wird immer mit betrieblichen Einschränkungen verbunden sein. Wartungsfenster werden begrenzt bleiben,legacy -Systeme lassen sich weiterhin nur schwer ändern, und die lokalen Gegebenheiten werden sich auch künftig unterscheiden. Die Lösung besteht nicht darin, diese Realitäten zu ignorieren, sondern Programme entsprechend darauf auszurichten. 

Die robusteste Architektur ist nicht unbedingt diejenige, die auf der Grundlage der umfassendsten Anfangs Umfang s entworfen wurde. Es ist vielmehr jene, die die Erkenntnisse der Organisation aufnehmen kann, sobald sich die tatsächlichen Rahmenbedingungen abzeichnen. 

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-Security 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-Security 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 Sicherheit vonOT oder überprüfen Sie ein bestehendes Programm? Der „OT Security EvaluationGuide“ bietet einen strukturiertenLeitfaden ( framework ) zur Bewertung des Schutzumfangs, der Anforderungen an dieBereitstellung , des betrieblichen Kontexts und der Möglichkeit, auf bestehender Infrastruktur aufzubauen.