Einheitliches Datenformat für das Engineering
Bild 3: Die Funktion von „AutomationML“ als einheitliche Schnittstelle für das Security Engineering (Quelle: Admeritia GmbH; Grafik: VDE VERLAG)
Um diese Information effizient nutzen zu können, müssen die Security-Engineering-Basisdaten mit möglichst niedrigem Aufwand generierbar, pflegbar und weiterverwendbar sein. Natürlich gibt es bereits Tools, die zumindest die aufwendige Grundlagenarbeit für das Netzmodell erledigen könnten – Lösungen für Netzwerkinventarisierung und -monitoring. Auf der anderen Seite könnten Configuration Management Databases (CMDB) – die in der IT längst etabliert und auch in der OT im Vormarsch sind – aus dem Security-Engineering-Prozess resultierende Security-Konfigurationen aufnehmen (Bild 3).
All diese Potenziale sind nur nutzbar, wenn die Security-Engineering-Basisdaten, also Netzmodell und Anwendungsfälle, eine Sprache formen, die sowohl von Menschen als auch von Maschinen verstanden wird – sie müssen sich also in einem Datenmodell abbilden lassen.
Mit diesem Datenmodell soll jedoch nicht gleichzeitig die Abhängigkeit von einem bestimmten Toolhersteller einhergehen. Weiterhin muss anerkannt werden, dass Security Engineering für OT-Ingenieure nur „Zusatzaufgabe“ ist – die Sprache der Security-Engineering-Basisdaten muss also eine sein, die auch in ihrer eigenen Ingenieurdisziplin gesprochen wird.
Ein maschinenlesbares, herstellerneutrales, in anderen Ingenieurdisziplinen etabliertes Datenformat ist „AutomationML“ [4]. Die Automation Markup Language bietet auf Basis von XML ein einheitliches Datenformat für alle Engineering-Disziplinen rund um eine automatisierte Anlage und übernimmt somit quasi eine Dolmetscherfunktion zwischen verschiedenen Ingenieursprachen. Mit ihr lassen sich Informationen zwischen unterschiedlichen Engineering-Werkzeugen flexibel austauschen [5, 6].
Gleichzeitig enthält „AutomationML“ aber auch Ansätze zur Modellierung von Kommunikationssystemen und Netzwerken [7]. Auf Basis dieser Ansätze können die beschriebenen Security-Engineering-Basisdaten abgebildet werden.
Die Sprache der Security
Security-Engineering-Basisdaten als „Sprache der Security“ zu formulieren und mit einem offenen Datenformat wie „AutomationML“ als Dolmetscher für jeden nutzbar zu machen, birgt die Chance, Design, Implementierung und Verwaltung von Security endlich vom fragwürdigen Nimbus einer „Wissenschaft für sich“ zu befreien – und zwar in mehrfacher Hinsicht.
Zum einen machen diese Basisdaten die Analysen und Implementierungen der Security effizienter, sodass sie tatsächlich in den betrieblichen Alltag eines OT-Ingenieurs passen können. Zum anderen kann ein Security-Engineering-Prozess, der auf diesen Daten aufbaut durch (bereits bestehende) Tools unterstützt werden. Diese Unterstützung kann den Menschen zwar nicht die Denkarbeit, wohl aber die Fleißarbeit abnehmen – genau den Aspekt, der „Security by Design“ häufig zum Scheitern bringt.
Zusätzlich können OT-Ingenieure durch die Arbeit mit Basisdaten – also die Betrachtung von Funktionen und Anwendungsfällen – alle notwendige Denkarbeit für den Security-Prozess mit begrenztem Aufwand selbst erledigen. Zudem ebnet die Integration von Security-Engineering-Basisdaten in ein etabliertes Format wie „AutomationML“ auch den Weg zur Zusammenarbeit mit angrenzenden Ingenieurdisziplinen.
Wenn man es mit dem „Security by Design“ ernst meint, dann kann Security-Engineering nicht als Insel existieren, sondern muss sich mit dem bereits existierenden Kontinent der angrenzenden Ingenieurdisziplinen arrangieren. Und wie könnte interkontinentale Kommunikation besser funktionieren als durch eine gemeinsame Sprache? (no)
Literatur:
[1] Fluchs, S.; Rudoplh, H.: Wie OT-Security-Engineering eine Ingenieurwissenschaft wird – Ein Denkmodell und ein Datenmodell. atp (2019) H. 8
[2] Fluchs, S.; Rudolph, H.: Das Layered-Blueprints-Denkmodell – Wie OT Security Engineering eine Ingenieurwissenschaft wird. CITplus (2019) H. 3
[3] Fluchs, S.: Das Layered-Blueprints-Denkmodell – Wie OT Security Engineering eine Ingenieurwissenschaft wird. Forum Safety & Security, Sindelfingen, Weka Fachmedien, 2019
[4] AutomationML e. V., Magdeburg: www.automationml.org
[5] Schmidt, N; Lüder, A.: AutomationML in a Nutshell. www.automationml.org, 2015
[6] Drath, R.: Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA. VDI-Buch, Berlin: Springer, 2010, ISBN 978-3-642-04673-5
[7] Drath, R.: AutomationML Brochure, AutomationML consortium, www.automationml.org, 2018