Prozessleittechnik- und Automatisierungsingenieure (im Folgenden: PLT-Ingenieure) tun sich schwer, Verantwortung für die Security ihrer eigenen Systeme zu übernehmen. Kein Wunder: Operational Technology (OT) Security Engineering verdient bislang die Bezeichnung „Engineering“ nicht. Es fehlen Methoden für die technisch fundierte Problemdefinition und die systematische Lösungsherleitung. Dieser Beitrag stellt ein Denkmodell für OT Security Engineering aus PLT-Ingenieursperspektive vor.

Das Denkmodell soll helfen, Security in Entwicklungs- und Wartungsprozesse zu integrieren und den fachlichen Austausch über OT-Security zu systematisieren und versachlichen. Das Denkmodell schreibt keine Methodik vor; vielmehr stellt es einen Rahmen, in den alle bisher vorhandenen Methodenfragmente integriert werden können.
Es erfüllt die drei Kernanforderungen:

• Angemessenheit
• Technische Wirksamkeit
• Reproduzierbarkeit

Grundstruktur des Denkmodells
Die Grundstruktur des Layered-Blueprints-­Denkmodells für OT Security Engineer­ing ist in Abb. 1 dargestellt. Es besteht von unten nach oben aus vier aufeinander aufbauenden Ebenen; jede dieser Ebenen fügt dem zu erarbeitenden Security-Blueprint einen Aspekt hinzu.
Das Fundament bildet die Ebene „Func­tion“. Ihr Zweck ist die eindeutige Problembeschreibung durch funktionale Anforderungen in Form von Schutzzielen und Annahmen.
Die darüberliegende Ebene „Risk“ analysiert Unsicherheiten („uncertainties“ gemäß ISO/IEC 27000:2018, “risk = the effect of uncertainty on objectives“), welche die zuvor identifizierten Schutzziele gefährden können, damit in der dritten Ebene, „Requirement“, Security-Anforderungen zum Abmildern der Unsicherheiten definiert werden können. In der Ebene „Implementation“ geht es um die individuell angepasste Konzeptionierung und Implementierung von Lösungen, die die zuvor festgelegten Security-Anforderungen erfüllen.
Alle Elemente des Denkmodells werden in der Berufspraxis der Autoren laufend angewendet. Die folgenden Abschnitte geben einen kurzen Überblick, wie das Denkmodell die Kernanforderungen Angemessenheit, technische Wirksamkeit und Reproduzierbarkeit ermöglicht.

Angemessenheit
Angemessenheit bedeutet, dass die Entwicklung von OT-Security-Lösungen in den betrieblichen Alltag der PLT-Ingenieure integrierbar ist. Zu diesem Zweck baut das Denkmodell im Fundament auf einen Schritt zur Komplexitätsreduktion und expliziten, visuellen Definition von Annahmen für alle weiteren Denkmodell-Teilschritte: Das Netzmodell.
Ein Netzmodell bildet alle Komponenten und Kommunikationsverbindungen reduziert auf die aus Security-Sicht relevanten Aspekte ab. Im Unterschied zu einem Netzplan ist das Ziel also nicht eine vollständige Dokumentation des Netzwerks. Für die Netzmodellerstellung werden aus Security-Per­spektive wiederkehrende Muster identifiziert, Klassen gebildet und nur eine Instanz jeder Klasse modelliert. Klassen können Typen von Standorten, Verbindungen und Systemkomponenten sein.
Das Netzmodell dient als grundlegende Dokumentation des Geltungsbereichs und der getroffenen Annahmen für alle weiteren Teilschritte des Security-Engineering-Denkmodells.
Angemessene OT-Security-Lösungen sind außerdem auf die individuellen Schutzziele ihres Anwenders zugeschnitten. Dafür müssen Schutzziele jedoch zuerst klar definiert werden.
Für die Schutzziele werden sowohl für IT- als auch für OT-Security oft die Prinzipien der Vertraulichkeit, Integrität und Verfügbarkeit von Daten bzw. Informationen bemüht. Diese Schutzziele treffen den Kern nicht, wenn es um OT geht. OT möchte physische Prozesse optimal ablaufen lassen, nicht Daten schützen.
Die Denkweise in Vertraulichkeit, Integrität und Verfügbarkeit ist für PLT-Ingenieure nicht intuitiv, was dazu führt, dass sie sich die Schutzziele ihrer eigenen Anlagen von ihrer internen IT-Abteilung oder Externen vordeklinieren lassen, statt sie selbst festzulegen. Häufig resultiert dies in einer pauschalisierten, schwammigen Festlegung von Schutzzielen. Wer seine Schutzziele nicht genau kennt, für den ist prinzipiell jede Gefährdung potenziell relevant – ein äußerst fruchtbarer Boden für Panikmache.
Das Layered-Blueprints-Denkmodell wirkt dem entgegen, indem es Schutzziele auf der Basis von Anwendungsfällen festlegt. Diese beschreiben die missionskritische Grundfunk­tionalität des betrachteten Systems – und damit exakt das, was schützenswert ist. Für die Definition von Schutzzielen in Form von Anwendungsfällen ist der Beitrag von Ingenieuren, die die OT-Systeme administrieren und täglich mit ihnen arbeiten, nicht nur notwendig, sondern unverzichtbar.

Technische Wirksamkeit
Die meisten bestehenden Methodikfragmente für OT-Security sind auf die Identifikation von Gefährdungen (Threat Modeling) und die Risikobewertung fokussiert. Um technische Wirksamkeit sicherzustellen, legt das Layered-Blueprints-Denkmodell den Fokus jedoch auf die technische Analyse und die Dokumentation der betrachteten Systeme.
Dies zeigt sich bereits in der Dokumenta­tion der Anwendungsfälle. Diese werden in der Kommunikationsanalyse auf Basis von Kommunikationssequenzen dokumentiert.
Das Prinzip für einen einfachen Beispiel-Anwendungsfall „Steuern“ zeigt die Abbildung. Zu sehen sind alle Rollen, die steuern können, sowie alle Klassen von Komponenten, über die gesteuert werden kann; außerdem die gesamte Kommunikationssequenz inklusive der beteiligten Protokolle, die für das Steuern gebraucht werden.
Wenn die Kommunikationsanalyse abgeschlossen ist, existiert gleichwohl die Daten­basis für eine komplette Kommunikationsmatrix des Netzmodells, in der für jede Komponente alle Kommunikationspartner und -proto­kolle vermerkt sind. Dies ist eine hervorragende Grundlage für Netzsegmentierung, Fire­wallregelwerke sowie Standardkonfigurationen.
Die Identifikation von Unsicherheiten erfolgt im Sinne der technischen Wirksamkeit auf Basis dieser technischen Anwendungsfalldefinition. Die Unsicherheiten selbst sind ebenso wir ihre Risikobewertung methodisch frei gestaltbar: Denkbar sind etwa Gefährdungen, Bedrohungen, Schwachstellen, Attack Trees, Cyber Fragilities, Dependencies oder Petrinetze.

Reproduzierbarkeit
Für Security Engineering gibt es bislang nur Methodikfragmente; vornehmlich die bereits erwähnten Threat-Modelling- sowie Risikoeinschätzungsmethoden. Es fehlt eine übergreifende Systematik, um bestehende Fragmente durchgängig vom Problem zur Lösung zu verbinden. Dies hat zur Folge, dass vorhandene OT-Security-Lösungen nicht genug Informa­tionen mitliefern, um nachzuvollziehen, welches Problem sie lösen sollen, warum sie dies lösen, und was Alternativen zu dieser Lösung wären.
Lösungen auf Basis des Layered-Blueprints-Modells beinhalten all diese Informationen – im Denkmodell-Turm muss dafür nur jeweils eine „Treppe abwärts“ genommen werden. Von der Implementierung ist es nur eine „Treppe abwärts“ zur zu erfüllenden Anforderung. Ebenso ist nachvollziehbar, aus welcher Unsicherheit diese Anforderung resultiert und aufgrund welches Anwendungsfalls die Unsicherheit zustande kommt. Diese Reproduzierbarkeit ermöglicht die Wartbarkeit und Flexibilität von Security-Lösungen.

Ausblick: Security als Teil des ­Engineering-Prozesses
Das vorgestellte Denkmodell hilft bei der angemessenen, technisch wirksamen und reproduzierbaren Erarbeitung von OT-Security-Lösungen aus PLT-Ingenieurssicht. Security ist für PLT-Ingenieure jedoch naturgemäß nie im Fokus, sondern muss sich stets hinter den funktionalen Anforderungen anstellen. Umso wichtiger ist eine effiziente Implementierung von Security-Lösungen – etwa durch automatisierte Umsetzung.
Die strukturierten Informationen des Denkmodells können für die (teil-)automatisierte Umsetzung von Lösungen genutzt werden – etwa eine automatische Generierung von Firewall­regeln aus der Kommunikationsanalyse. Dafür ist eine maschinenlesbare Form des Denkmodells notwendig – ein Datenmodell. Dazu wurde ein Entity-Konnektor-Relationship-Modell entwickelt, das im nächsten Schritt in Datenmodelle und Werkzeuge integriert werden soll, die PLT-Ingenieure ohnehin nutzen. Vielversprechende Kandidaten sind AutomationML, OPC UA, das Konzept der Verwaltungsschale sowie bestehende Tools für Inventarisierung und Alarmierung.
Wenn Security by Design nicht nur eine Absichtserklärung bleiben sondern machbar werden soll, braucht es die Symbiose aus technisch fundierter Methodik und praktikabler Integration in Werkzeuge, die in das Betriebsregime der PLT-Ingenieure passen, die sie anwenden.