nachgehakt! bei Jan Hoff, Dragos
„Ein ‚One-Size-Fits-All-Modell‘ ist nicht sinnvoll.“
Angesichts des digitalen Wandels benötigen Unternehmen neben IT- auch ein solides Verständnis von OT-Cybersicherheit und der Unterschiede zwischen beiden. Was das beinhaltet, erklärt Jan Hoff.
Herr Hoff, inwiefern hat sich die Kommunikation zwischen OT- und IT-Experten verändert?
Die Kommunikation und damit das Verständnis zwischen beiden hat sich in den letzten Jahren positiv weiterentwickelt. Denn obwohl der Bereich OT als Teil der Automatisierungstechnik nicht neu ist, hat der Begriff OT als Abgrenzung von Industrietechnik zur IT zu Missverständnissen geführt. Traditionell fokussierte sich OT auf die Zuverlässigkeit und Safety physischer Prozesse, während IT sich auf Daten- und Netzwerksicherheit konzentrierte. Heutzutage können beide Bereiche nicht mehr getrennt arbeiten. Die Konvergenz begann früh mit der Übernahme von IT-Komponenten in industrielle Anlagen.
Welche Integrationstrends zeichnen sich zwischen IT- und OT-Security ab?
Aus Business-Sicht besteht die Notwendigkeit, Daten über verschiedene Unternehmensbereiche hinweg auszutauschen, was auch die OT-Sicherheit betrifft. Sicherheitswerkzeuge werden zentralisiert, etwa für gemeinsames Logging und Monitoring, während spezialisierte OT-Werkzeuge weiterhin genutzt werden können, um Alarme gezielt zu behandeln.
Aus Sicherheitssicht erfordern Fachkräftemangel und unterschiedliche Reifegrade eine Zusammenarbeit von IT und OT, um Unternehmen und Industrieumgebung zu schützen. Oft wird fälschlicherweise angenommen, dass IT-Werkzeuge und Prozesse einfach auf OT übertragen werden können. Daher müssen IT und OT in gemeinsame Sicherheitsstrukturen integriert werden, wie etwa in einem Security Operation Center – immer unter Berücksichtigung individueller Anforderungen. Ein ‚One-Size-Fits-All-Modell‘ ist aufgrund der Unterschiede nicht sinnvoll. Die Grundlage für eine Referenzarchitektur ist eine ‚Defensible Architecture‘, die Schutzmaßnahmen und Reaktionen auf Vorfälle berücksichtigt. Ein erster Schritt ist das Purdue-Modell, um darauf basierend eine gemeinsame IT/OT-Referenzarchitektur zu entwickeln.
Wie unterscheiden sich die einzelnen Branchen in den Anforderungen der IT/OT-Security?
Historisch lag der Fokus stark auf der Energiewirtschaft und der Öl- und Gasbranche, aber ein produzierendes Unternehmen kann nicht wie ein Energieversorger behandelt werden. Gemeinsamkeiten sind etwa die statische Architektur und abgrenzbare Netzwerke von Industrieanlagen sowie vorhandene Sicherheitsmaßnahmen. Ein zentraler Faktor bleibt der Mensch, der diese Umgebungen absichert und betreibt.
Die Digitalisierung hat dazu geführt, dass sich Infrastrukturen und Herausforderungen in der IT/OT-Security angleichen. Schutzziele wie Verfügbarkeit, Integrität, Vertraulichkeit, Produktivität, Zuverlässigkeit und Safety sind in fast allen Branchen vorhanden. Je nach Branche variieren gesetzliche Anforderungen aus KRITIS oder NIS, so dass eine ‚Compliance nach Schablone‘ nicht möglich ist.
Sollten Unternehmen eigene Security-Kompetenz aufbauen?
Unternehmen, die Security-as-a-Service in Betracht ziehen, müssen bedenken, dass Dienstleister nur begrenzt internes Wissen über Sicherheits- und Industrieprozesse bereitstellen können. Internes Fach- und Sicherheits-Know-How ist entscheidend für effektive Reaktionen auf Vorfälle. Aber: Der Aufbau von Security-Kompetenz ist langwierig und schwierig. Betreiber sollten strategisch die Fähigkeit aufbauen, externe Dienstleister zu steuern. Eigenes OT-Security-Personal vorzuhalten, ist oft unwirtschaftlich oder wegen des Fachkräftemangels unmöglich. Daher können externe OT-Security-Experten internes Personal ergänzen und die Nutzung von Technologien wie Netzwerkmonitoring ermöglichen, während das Betriebspersonal sich auf seine Hauptaufgaben konzentriert und die Anlage geschützt bleibt. Unabhängig davon sollten fünf Maßnahmen umgesetzt werden: ein OT-spezifischer Incident Response Plan, eine gut zu verteidigende Architektur, Visibilität in Netze und Systeme, sichere Fernzugriffe und ein risikobasiertes Schwachstellenmanagement.










