AutomationML-basierte Modellierungsansätze für ein Security-Engineering-Informationsmodell

Abstract

Industrial digitization and the introduction of Internet technologies pose a major challenge for security. With increasing networking of their components in the Industry 4.0 environment, these have become attractive targets for IT attacks and malware. While functional safety is deeply integrated into the development of products or processes, this is not the case with security. Security engineering, like functional safety, must integrate into existing automation engineering processes, which is currently undergoing significant changes, but most importantly, it must be efficient for automation engineers to perform. This paper justifies the need for a security engineering model, reports on the ongoing work on modeling approaches with AutomationML and compares them.

Full text

AutomationML-basierte Modellierungsansätze für ein Security-
Engineering-Informationsmodell
AutomationML-based modeling approaches for a security
engineering information model
Emre Tastan, Hochschule Pforzheim;
Sarah Fluchs, admeritia GmbH, Langenfeld und Helmut-Schmidt-
Universität/Universität der Bundeswehr, Hamburg;
Prof. Dr.-Ing. Rainer Drath, Hochschule Pforzheim;
Kurzfassung
Bei der industriellen Digitalisierung und der Einführung von Internettechnologien in die
Produktion stellt die Security eine der größten Herausforderungen dar. Mit zunehmender Ver-
netzung ihrer Komponenten in der Industrie 4.0-Umgebung sind diese zu attraktiven
Angriffszielen für IT-Angriffe und Malware geworden. Während die funktionale Sicherheit tief
in die Entwicklung von Produkten oder Prozessen integriert ist, ist dies bei der Security nicht
der Fall. Security-Engineering muss sich analog zur funktionalen Sicherheit in den
bestehenden und sich gerade stark verändernden Automatisierungs-Engineering-Prozess
eingliedern, vor allem muss es aber für Automatisierungsingenieure effizient durchführbar
sein. Dieser Beitrag begründet den Bedarf an einem Security-Engineering-Modell, berichtet
über die laufenden Arbeiten zu den Modellierungsansätzen mit AutomationML und stellt diese
in Vergleich.
Abstract
Industrial digitization and the introduction of Internet technologies pose a major challenge for
security. With increasing networking of their components in the Industry 4.0 environment, these
have become attractive targets for IT attacks and malware. While functional safety is deeply
integrated into the development of products or processes, this is not the case with security.
Security engineering, like functional safety, must integrate into existing automation engineering
processes, which is currently undergoing significant changes, but most importantly, it must be
efficient for automation engineers to perform. This paper justifies the need for a security
engineering model, reports on the ongoing work on modeling approaches with AutomationML
and compares them.

1. Motivation und Zielstellung
Die vierte industrielle Revolution (Industrie 4.0) verfolgt unter anderem die durchgängige
Digitalisierung und intelligente Vernetzung von Maschinen, Anlagen, Prozessen sowie von
Menschen. Systeme der Prozess- und Fertigungsautomation werden durch
Internettechnologien miteinander verbunden. Zeitgleich werden diese Anlagen jedoch auch zu
attraktiven Zielen für Cyberangriffe und Malware. Darüber hinaus sind bestehende industrielle
Anlagen und Maschinen auf Lebenszyklen von 20 Jahren und länger konzipiert, aber verfügen
oft kaum über Cybersecurity-Funktionalitäten [1]. Bisher wurden deshalb Security-
Maßnahmen üblicherweise nachträglich umgesetzt. Diese nachträgliche Umsetzung führt
dazu, dass Security bis heute ein "Fremdkörper" in der Domäne des Automation-Engineering
und auch in den zugehörigen Automatisierungs-Gremien ist. Erschwerend kommt hinzu, dass
die Schutzmaßnahmen der Cybersecurity häufig die Verfügbarkeit und Performance der
Produktionseinheiten verschlechtern. All diese Punkte sprechen dafür, Security-Engineering
zu systematisieren. Noch immer erfolgt Security-Engineering zu unsystematisch, oft getrieben
von Best-Practice-Lösungen. Wie gut eine Lösung ist, hängt vor allem von dem
Wissensumfang der beteiligten Security-Experten ab. Damit ein systematischeres Security-
Engineering für Automatisierungsingenieure bewältigbar bleibt, sind digitale Modelle
notwendig. Modelle, die es ermöglichen, eine Vogelperspektive über das gesamte technische
System zu schaffen. Nicht nur lesbar für den Menschen, um technische Systeme mit der
Security-Perspektive zu verbessern, sondern auch maschinenverarbeitbar, um unter anderem
security-relevante Merkmale zu visualisieren. Somit muss in Zukunft Security-Engineering ein
selbstverständlicher und organischer Bestandteil des Automatisierungs-Engineering-
Prozesses werden. Dafür werden neue Methoden benötigt, welche parallel mit dieser Arbeit
(„Security-Entscheidungen „by Design“ in das Engineering prozesstechnischer Anlagen
integrieren“) bei der Automation 2022 vorgestellt wird.
Im Kontext von Industrie 4.0 und sich schneller ändernden und zunehmend modular
aufgebauten Automatisierungslösungen gewinnt die Maschine-zu-Maschine-Kommunikation
an Bedeutung. Diese soll sicherstellen, dass Maschinen einander ihre Zustände und
Eigenschaften eindeutig und universell verständlich mitteilen können. Wie solch ein Modell für
ein Automation-Security-Engineering-Prozess aussehen kann und wie ein Security-
Domänenmodell im Engineering sowie auch in der späteren Betriebsphase helfen kann,
untersuchen die Autoren im Rahmen des öffentlich geförderten Projektes IDEAS "Integrated
Data Models for the engineering of Automation Security". Dazu wird unter anderem ein
elektronisches Security-Informationsmodell, das in elektronischer und standardisierter Form
den Austausch zwischen beteiligten Planungswerkzeugen maschinenlesbar und

maschinenverarbeitbar ermöglicht, entwickelt. Es fungiert dabei als modelltechnische
Grundlage des elektronischen Workflows und ermöglicht weitreichende Funktionen wie
Änderungsmanagement, Tracking von Entscheidungen über Phasen und Zeiten hinweg,
sowie Möglichkeiten zur Archivierung und Speicherung von Musterlösungen und als Basis für
neue Geschäftsmodelle der Zukunft.
Als Ausgangspunkt ist ein Ansatz zur
Strukturierung des Security-Engineering-
Prozesses vom Projektpartner admeritia
GmbH erarbeitet worden [2]. Die
Abbildung 1 zeigt ein methodenneutrales
Prozessmodell für das Security-Engi-
neering. Dieser beinhaltet vier aufein-
ander aufbauende Ebenen, in die sich
bestehende Vorgehensweisen einordnen
lassen. Der Leuchtturm beschreibt ein
allgemeines Security-Engineering-Pro-
zessmodell für den gesamten Security-
Engineering-Prozess: Ausgehend von der Identifikation schutzbedürftiger Funktionen (FC)
werden Risiken (RI) abgeleitet, Security-Anforderungen (RE) gegen diese Risiken definiert und
in einer Security-Lösung (IM) implementiert. [2]
Damit die Methodenneutralität des Modells bestehend bleibt, können die verschiedenen
Security-Risikoanalyse- oder Systems-Security-Engineering-Methoden in den vier Ebenen
eingesetzt werden, sodass keine Entscheidungen für oder gegen einen bestehenden Standard
getroffen werden müssen.
Im Rahmen dieses Beitrags werden die Autoren für die erste Ebene des Turmes (FC) die
Anforderungen an ein Security-Informationsmodell sowie vier Ansätze für ein konkretes Modell
mit einem Beispielen beschreiben. Dazu werden die Modellierungsansätze mit AutomationML
mit ihren Vor- und Nachteilen beschrieben und verglichen. Die anderen Ebenen sind
Gegenstand zukünftiger Arbeiten.
Darüber hinaus wurde seitens der Autoren bereits in [3] anhand von Anwendungsfällen die
Notwendigkeit eines Security-Engineering-Informationsmodells beschrieben und eine
Anforderungsanalyse an das Informationsmodell abgeleitet. Es beinhaltet einen
Modellierungsansatz in AutomationML zur Unterstützung der Anwendungsfälle und der
Erfüllung der Anforderungen. Dennoch existieren mehrere Modellierungsansätze für Security-
Merkmale, welche in der bisherigen Arbeit nicht erwähnt worden sind.
Abbildung 1: Allgemeines Prozessmodell für
Security-Engineering [2]

2. Stand der Technik
Als Technologie für das Informationsmodell wählen die Autoren die neutrale Modellierungs-
sprache AutomationML (AML) [4] [5]. Innerhalb des Automation-Engineerings mit seiner
Vielfalt an beteiligten Ingenieurdisziplinen von Verfahrenstechnik über Regelungstechnik und
Robotik bis hin zu funktionaler Sicherheit wird die Herausforderung der verschiedenen
Ingenieursprachen, diese in Einklang zu bringen, mit Hilfe von AutomationML verfolgt.
Insbesondere für die Zielsetzung des vorliegenden Security-Engineering-Informationsmodells
kann AutomationML angewendet werden.
Darüber sind in der Literatur erfolgreiche Ansätze in AutomationML beschrieben, auf denen
das neu zu entwickelnde Security-Informationsmodell aufbauen kann. AutomationML ermög-
licht die Modellierung von Anlagenkomponenten und Kommunikationssystemen in Form
hierarchischer Objektmodelle. Auch die Beschreibung von Geometrie, Kinematik, Dokumen-
tation, Schnittstellen oder Logik können in Form von Objekten und separaten Dateiformaten
abgelegt werden [6]. Es ist anzumerken, dass für das Security-Engineering-Informations-
modell ein gewisser Abstraktionsgrad notwendig ist und nicht alle Teilaspekte von AML
notwendig sind.
Die Modellierung von Kommunikationsnetzwerken ist für das Security-Engineering ein wesent-
licher Bestandteil des Informationsmodells. Durch die AML-Reihe IEC 62714 (insbesondere
der 2022 standardisierte Teil 5) werden Modellierungsempfehlungen für Kommunikationsnetz-
werke geliefert, die eine Klassifikation der Verbindungen zwischen logischer sowie physischer
Sichten liefert [7]. Für die Security-Analyse ist die logische Sicht des Netzwerkes essenziell.
Solch eine Modellierung wurde bereits in [8] publiziert, dass den ersten Ansatz für ein Security-
Modell in AML vorstellt. Eine Analyse, der für das Security-Engineering zu modellierenden
Informationen und Vorschläge für ihre Abbildung in der Verwaltungsschale ist in [9] erfolgt.
Zur Erleichterung der Modellierung von Prozessabläufen in komplexen Anlagen wird die
Dreiteilung der Daten in AML empfohlen. Hierzu wird das Produkt-Prozess-Ressource-
Konzept (kurz: PPR-Konzept) angewendet. Das PPR-Konzept erlaubt die interaktive
Modellierung von Arbeitsabläufen, Prozessabläufen und Systemkonfigurationen. Für die
Security-Analyse können hiermit Funktionen modelliert werden, d. h. eine systematische
Beschreibung der zu schützenden Systemkomponenten sowie deren Kommunikation
miteinander, der für die Erfüllung eines bestimmten Zwecks im System relevant ist. [4]
Darüber hinaus beschreibt [10] eine umfassende Analyse zu existierenden funktionsbasierten
Engineeringansätzen in verschiedenen Domänen. Es beinhaltet die Umsetzung eines
funktionsbasierten Systemmodells für die Fertigungsindustrie, welche in Form einer AML-
Modellierung und Bibliotheken vorliegt.

Auch wird mit AMLsec nicht nur eine ausführliche Risikobetrachtung nach ISA/IEC 62443-3-2
[11] vorgegeben, sondern auch eine AML-Bibliothek, die security-relevante Informationen wie
Security-Geräte und Security-Konfigurationen beinhaltet, welche für das vorliegende Security-
Informationsmodell genutzt werden. [12]
In Standardisierung und Forschung werden Konzepte wie die Verwaltungsschale [13], IEC
Common Data Dictionary [14], eCl@ss [15] oder das Common Information Model [16]
vorangetrieben. Für Security ist hierzu noch kein umfassendes Merkmalmodell vorhanden und
wird von den diversen Konzepten zusammenfassend betrachtet und ggf. abgeleitet.
3. Die erste Ebene im Security-Engineering-Prozessmodell: Funktion (FC)
Ein Modell soll eine klare Sicht auf die
Anlage als System schaffen. Solch eine
Systemmodellierung ist Voraussetzung
für die Entwicklung einer Security-Lö-
sung. Das Informationsmodell soll die
Anlage explizit und technisch fundiert ab-
bilden und die Komplexität auf security-
relevante Aspekte reduzieren können. In
dieser sollen alle betroffenen System-
komponenten und menschlichen Rollen
sowie deren Verbindungen mit Informa-
tionen zueinander abgebildet werden.
Um Security-Lösungen entwickeln zu
können, müssen Risiken im System erfasst werden. Und um diese zu ermitteln, werden aus
dem Systemmodell Funktionen abgeleitet, in der die security-relevanten Informationen im
Detail betrachtet werden. Eine Funktion ist eine Zusammenfassung von Systemkomponenten
sowie deren Verbindungen, dass einen Zweck im System erfüllt. Sie definiert konkret die zu
schützende Systemfunktion im Anwendungsbereich sowie deren Abhängigkeiten von
Menschen, Hardware und Software. Als Grundlage für die Modellierung einer Funktion und
der ersten Ebene des Security-Engineering-Prozessmodells wird eine vereinfachte
Netzwerkstruktur angewendet. Fehler! Verweisquelle konnte nicht gefunden werden. zeigt
exemplarisch eine Funktion für das Bedienen, Beobachten, Engineering und die Fernwartung
durch einen externen Dienstleister. Dabei greift ein Fremd-Techniker über die VPN-
Schnittstelle in das Prozessnetz ein und programmiert eine SPS. Im Folgenden werden vier
Ansätze zur Modellierung von Funktionen vorgestellt und bewertet.
Abbildung 2: Einfache Funktion - Remote Control

4. Anforderungen an die Modellierung der ersten Ebene (FC)
A1 – Transparente Teilmodelle:
Eine der wichtigsten Eigenschaften des Security-Informationsmodells ist die Reduzierung der
Komplexität aufgrund der großen Menge an Informationen aus verschiedenen Domänen. Für
die Modellierung der ersten Ebene ist die Informationsgewinnung von security-relevanten
Eigenschaften wesentlich und setzt einen höheren Abstraktionsgrad an die jeweiligen Objekte
vor. Somit wird eine Transparenz des Informationsmodells vorausgesetzt, das alle Information
einer Funktion leicht zugänglich und verständlich in klarer und einfacher Form widerspiegelt.
A2.1 – Modellierung von Objekten für Funktionen:
Das Security-Engineering-Modell benötigt für ein rein technisches System zusätzliche
Informationen. In einer Funktion werden Objekte mit den Eigenschaften von menschlichen
Rollen oder IT/OT-Systemen modelliert, welche Interaktionen und Kommunikation zwischen
diesen Objekten beinhalten. Jede Funktion zeigt den Teil des Systems in Form von Objekten,
der für die Erfüllung eines bestimmten Zwecks relevant ist. Darüber hinaus kann in der
Funktion eine Verbindung zum Risiko (zweite Ebene des Leuchtturms) hergestellt werden.
A2.2 – Modellierung des Informationsflusses:
Eine Funktion bildet den Informationsfluss zwischen den beteiligten technischen
Komponenten, Menschen sowie Interaktionen mit Kommunikationsverbindungen ab. Diese
müssen übersichtlich und abrufbar sein, da solche technischen Komponenten eine Vielzahl
von Verbindungen zu anderen Systemkomponenten besitzen.
A3 – Vermeidung der doppelten Datenhaltung:
In dem Security-Informationsmodell soll Inkonsistenz vermieden werden, indem keine Daten
mehrfach mit der gleichen Bedeutung abgelegt werden. Dies ist unter anderem der Fall, wenn
für eine Funktion aus dem gesamten Systemmodell eine Kopie des Objektes erstellt wird.
Somit besteht nicht die Möglichkeit, eine Änderung im Systemmodell durchzuführen, wenn
Eigenschaften eines Objektes in einer Funktion manipuliert werden. Eine doppelte Daten-
haltung führt zu mehr Arbeitsaufwand, da Daten mehrfach angepasst werden müssen. Dies
kann auch zu einer Mutationsanomalie führen, wenn diese Änderungen nicht fehlerfrei
durchgeführt werden, oder zu Verarbeitungsfehlern, wenn sich die Daten widersprechen.
A4 – Nutzbarkeit von vordefinierten Bibliotheken:
Für die wichtigsten Systemfunktionen kann eine zusätzliche Bibliothek genutzt werden, in der
bereits etablierte Funktionsvorschläge als Musterlösungen abgelegt sind. Diese beschreiben
alle notwendigen Informationen wie betroffene Anlagenkomponenten aus dem Netzwerk,
Rollen und Zugehörigkeiten von Risikoszenarien. Darüber hinaus kann mit einer
Rollenvergabe eine bessere Durchsuchbarkeit und maschinelle Verarbeitbarkeit der Objekte

durch das Filtern und Selektieren gewährleistet werden. Auch muss die Möglichkeit gegeben
sein, dass die jeweiligen Ansätze zur Modellierung der ersten Ebene in Bibliotheken abgeleitet
werden kann.
5. Modellierungsansätze für die erste Ebene (FC) mit AutomationML
5.1. Übersicht
Dieses Kapitel widmet sich der Modellierung mit der Objektmodellierungssprache Auto-
mationML. Analog zu einer gesprochenen Sprache, mit der eine Aussage auf verschiedene
Weisen formuliert werden kann, kann AutomationML einen gewünschten Sachverhalt mit Hilfe
verschiedener Modellierungsansätze unterschiedlicher Ausdruckskraft abbilden. Im Fol-
genden stellen die Autoren verschiedene Ansätze vor, um ein Security-Informationsmodell mit
AML zu modellieren. In Kapitel 6 erfolgt ein Vergleich und Empfehlung.
5.2. Ansatz 1: das AML-Gruppen-Konzept
In einem AML-Informationsmodell
kann eine Separierung der Objekte
von Strukturen oder Netzwerken
mithilfe des AML-Gruppen-Konzep-
tes realisiert werden. Die Objekte in
der Funktion werden durch ein ge-
spiegeltes Objekt (Mirror-Objekt)
modelliert. Durch die Referenzierung
im Mirror-Objekt wird mit der
eindeutigen globalen ID (Globally Unique Identifier; kurz: GUID) des Masters ein Verweis auf
das Informationsmodell generiert. Dadurch besteht stets ein direkter Bezug und Änderungen
können ohne doppelte Datenhaltung durchgeführt werden. Die Funktion wird anhand einer
Hierarchie modelliert wie in Abbildung 3 dargestellt. Anzumerken ist, dass die Eigenschaften
von und zwischen den Objekten der Funktion ausschließlich in den Master-Objekten
modifiziert werden können. Sollten mehrere Verbindungen zwischen den jeweiligen Objekten
bestehen oder mehrere Protokolle werden ausgetauscht, kann in diesem Konzept nicht
entschieden werden, welche für die Funktion genutzt werden. Darüber hinaus werden
menschliche Interaktionen im Informationsmodell nicht abgebildet (siehe [3]) und die Art der
Nutzerinteraktion bezogen auf das Folgeobjekt kann nicht modelliert werden. Durch das
Gruppen-Konzept wird lediglich eine Modellierung einer Hierarchie sowie alle Verbindungen
der betroffenen Entitäten abgebildet, die für die Funktion nicht von Bedeutung ist.
Abbildung 3: Mirror-Konzept

5.3. Ansatz 2: Verbindungen zwischen den Entitäten
Ein zweiter Ansatz (siehe Abbildung
4) beschreibt die Funktion, indem die
Objekte aus dem gesamten techni-
schen Systemmodell kopiert werden.
Dadurch besteht kein direkter Bezug
mehr zum Modell und Änderungen
müssen nachträglich durchgeführt
werden. Die „ExternalInterface“-
Schnittstelle, welche die Verbindun-
gen zwischen den Objekten herstellt,
muss bei der Modellierung der Funk-
tion nachträglich hinzugefügt werden.
Zusätzliche security-relevante Infor-
mationen, wie die Richtung, Reihen-
folge oder Art der Verbindung werden
als Attribute im InternalLink (Verbin-
dung zwischen Objekten) gespei-
chert. Damit besteht die Möglichkeit,
die Nutzerinteraktion einer mensch-
lichen Rolle im Modell abbilden zu
können. Demzufolge können nur Informationen zu den Verbindungen in Form von Attributen
definiert werden. Eine Modellierung von weiteren Objekten (CAEX InternalElements) an dem
InternalLink ist nicht möglich.
5.4. Ansatz 3: Verbindungen zwischen den Entitäten nach IEC 62714-5
Für die Modellierung von Kommunikationsstrukturen wird das empfohlene Konzept für Netz-
werkkommunikationen von AML angewendet. Das Netzwerk besteht aus zwei Ebenen von
Informationen: die logische und die physische Sicht, welche mithilfe der Bibliotheken aus [7]
dargestellt werden. Für die Zuordnung der Sichten wird das OSI-Modell [17] herangezogen.
Dabei entspricht die 1. und 2. Schicht für die physische und die 3. bis 7. für die logische Ebene.
In der Regel ist die logische Sicht für die Security-Analyse von Bedeutung. Auch wird in der 7.
Schicht (Anwendungsschicht) die menschliche Interaktion beschrieben. Der dritte
Modellierungsansatz ähnelt dem Ansatz aus 5.2. Als zusätzliche Änderungen werden die
Abbildung 4: Funktion mit einfachen Verbindungen

Verbindung zwischen den Objekten als
InternalElements zusätzlich modelliert.
Dementsprechend können zusätzliche In-
formation in Form von weiteren Objekten
(Internal-Elements) bei den Verbindungen
zugeordnet werden. Die betroffenen
Komponenten aus dem Informations-
modell werden in die Funktion kopiert,
dass wiederum zu einer doppelten
Datenhaltung führt. Dementsprechend hat
die Funktion keinen direkten Bezug zum
gesamten technischen Systemmodell.
5.5. Ansatz 4: „Sender-Process-Receiver“-Konzept (SPR-Konzept)
Mit dem folgenden Absatz wird der vierte
Ansatz (Abbildung 6) beschrieben: Bei der
Strukturierung komplexer Anlagen hat sich in
der Praxis der AutomationML die Dreiteilung
der Daten in Ressourcen, Prozesse und
Produkte bewährt, die auch als PPR-Konzept
bezeichnet wird [4]. Dieses Konzept bietet die
Grundlage zur Darstellung der Informations-
modellierung der Funktionen. Aufgrund der
Tatsache, dass das klassische PPR-Konzept
auf Produkten, Ressourcen und Prozessen
basiert, sind menschliche Rollen nicht
enthalten. Dementsprechend ist eine Unter-
scheidung von Produkt und Ressource nicht
möglich. Deshalb empfehlen die Autoren eine
Erweiterung des PPR-Konzeptes für das
Security-Informationsmodell. Folgende Rollen
werden hierfür eingesetzt: Sender, Prozess
sowie Receiver (Empfänger) und die
Abbildung 5: Ausschnitt der Funktion mit der
Kommunikationssyntax aus IEC 62714-5
Abbildung 6: Funktionsmodellierung mit dem
SPR-Konzept (aufgrund der Größe der
Funktion wurden die Inhalte angepasst)

Schnittstelle „SPRConnector“. Ein Sender
führt einen Prozess am Receiver durch. Mit
diesem Konzept können die Funktionen wie
einfache Sätze gelesen werden: "Techniker
programmiert SPS". Die Funktion besteht
aus mehreren Interaktionsdreiecken (siehe
Abbildung 7). Dadurch werden für den
Betrachter der Funktion drei Blick-
richtungen mit ihren Objekten und Rollen
generiert. Die Reihenfolge der Interaktions-
dreiecke wird in der AML-Datei mit der InterfaceClass „Order“ realisiert, welche sich beim
Sender befindet. Die Objekte werden, wie bei den beiden vorherigen Ansätzen aus dem
Informationsmodell kopiert. Eine Spiegelung der Objekte (siehe 5.2 – Gruppen-Konzept) ist
nicht möglich, da die Rollen Sender und Receiver jeweils getrennt an die gleichen Objekte in
der Funktion vergeben werden. Dadurch gibt es bspw. die SPS zweimal in der Funktion mit
jeweils der Rolle Sender und Receiver in unterschiedlichen Interaktionsdreiecken.
6. Vergleich der Ansätze und Ableitung einer Modellierungs-Lösung
In diesem Abschnitt werden die vorgestellten Modellierungsansätze verglichen und bewertet.
Anhand dieser Entscheidung können nächste Schritte für die Modellierung von Risiken,
Anforderungen und Implementierungsmöglichkeiten erstellt werden. Die folgende Tabelle
zeigt, ob die jeweiligen Ansätze die Anforderungen erfüllen.
Tabelle 1: Vergleich – Gegenüberstellung der Anforderungen zu den Ansätzen (grün: erfüllt;
orange: nicht empfohlen; rot: nicht erfüllt)
A1 - Transparente
Teilmodelle
A2.1 - Modellierung
von Objekten für
Funktionen
A2.2 - Modellierung
des Informationsflusses
A3 - Vermeidung der
doppelten
Datenhaltung
A4 - Nutzbarkeit von
vordefinierten
Bibliotheken
#1 Gruppen-
Konzept
#2 Einfache
Verbindungen
#3 Verbindungen
nach IEC 62714-5
#4 SPR-Konzept
Abbildung 7: SPR-Konzept - Interaktionsdreiecke

Für die Security-Analyse ist es erheblich, dass alle relevanten Informationen aus dem
gesamten Informationsmodell in einer Funktion abgebildet sind. Da das (#1) Gruppen-Konzept
nicht aufweisen kann, welche Protokolle für die Funktion genutzt werden, ist dieser Ansatz
nicht zu empfehlen. Darüber hinaus wird die Sicht der Funktion – das Denkmodell – verlassen,
indem das vollständige Informationsmodell betrachtet wird. Der Ansatz mit den (#2) einfachen
InternalLinks zwischen den Objekten zeigt, dass die Vollständigkeit der Informationen nicht
gewährleistet werden kann, da alles in Form von Attributen gespeichert werden muss. Wird
der Ansatz mit den (#3) Verbindungen nach IEC 62714-5 mit dem (#4) SPR-Konzept
verglichen, so ist ersichtlich, dass der Anwender diverse Informationen aus dem SPR-Konzept
mit den Sichten durch die Rollenvergabe gewinnen kann. Da die doppelte Datenhaltung bei
großen Netzwerkstrukturen auch zu einem Risiko führen kann, wird die Mirror-Eigenschaft aus
dem (#1) Gruppen-Konzept mit dem (#4) SPR-Konzept vereint.
Die Zusammenführung der Mirror-Eigenschaft mit den AML-Objekten wird ebenfalls bei
„Module Type Package“-AutomationML-Dateien [18] verfolgt. Die Modellierung zur
Vermeidung der doppelten Datenhaltung wird in Abbildung 8 dargestellt. Dabei wird dem
jeweiligen Objekt in der Funktion ein Attribut mit dem Type „xs:IDREF“ vergeben, dass auf das
Master-Objekt mit dieser GUID verweist. Dadurch wird gewährleistet, dass durch eine
verarbeitende Software die jeweiligen Objekte im Modell selektiert und dementsprechend
angepasst werden.
Abbildung 8: Vermeidung der doppelten Datenhaltung mit dem SPR-Konzept

7. Zusammenfassung und Ausblick
Mit den vorgestellten Ansätzen werden Modellierungsmöglichkeiten für die erste Ebene des
Security-Engineering-Prozessmodells evaluiert mit dem Ziel, die Workflows von Security- und
Automation Engineering zu vereinen. Dadurch wird eine Grundlage für die Durchführung einer
Security-Analyse, insbesondere für die Ableitung von Risiken, Security-Anforderungen und
Security-Lösungen geschaffen. Mithilfe des SPR-Konzeptes und dem Zusatz zur Vermeidung
der doppelten Datenerhaltung kann das zu schützende System mit allen notwendigen security-
relevanten Informationen modelliert werden.
Die Integration von security-relevanten Informationen in maschinenlesbare, maschinen-
verarbeitbare und maschinenverständliche Datenmodelle wie AutomationML, die bereits im
Bereich der Automatisierungstechnik etabliert sind, ist ein wichtiger Schritt zur Integration von
Security in den gesamten Prozess der Automatisierungstechnik. AutomationML war bereits
Grundlage für eine Vielzahl von Informationsmodellen in der Industrie und ist als Technologie
zur Modellierung von Teilmodellen für Engineering-Informationen in die Industrie 4.0 Verwal-
tungsschale bereits eingebettet.
Zusätzlich ist die Kompatibilität mit der Verwaltungsschale (VWS) ein bedeutsamer Aspekt für
die Zukunftstauglichkeit des Security-Informationsmodells. Das im Rahmen des Projektes
IDEAS zu entwickelnde methodenneutrale Informationsmodell dient als Datenlieferant für das
Teilmodell „Security-Engineering“ der VWS. Teilmodelle sind zentraler Bestandteil der
„Industrie 4.0 Verwaltungsschale“ und können innerhalb einer VWS voneinander getrennt
betrachtet werden. Unterschiedliche Teilmodell repräsentieren die verschiedenen Aspekte
eines Assets über den gesamten Lebenszyklus hinweg [19] [20].
In diesem Beitrag wird das Fundament für die Informationsmodellierung des Security-
Engineerings gelegt. Die Modellierung der nächsten Schritte im Security-Engineering-Prozess
(restliche Ebenen im Security-Engineering-Prozessmodell: Risiken, Anforderungen und
Implementierung) ist Teil zukünftiger Arbeiten im Forschungsprojekt.
In Zusammenarbeit mit dem NAMUR-Arbeitskreis 1.3 (Informationsmanagement und
Werkzeuge) wird das Informationsmodell für das Security-Engineering als UML-Modell
modelliert. Darüber hinaus wird die Verwendung des Security-Informationsmodells als
Teilmodell der Verwaltungsschale angestrebt.
8. Danksagung
Diese Arbeit wird unterstützt vom Bundesministerium für Bildung und Forschung (BMBF) im
Rahmen des Projektes „IDEAS“ (Integrated Data Models for the Engineering of Automation
Security, Vorhaben 16KIS1269K). [21]

9. Literatur
[1]
BMWi, „Der IT-Sicherheitsmarkt in Deutschland: Grundstein für eine makroökonomische
Erfassung der Branche.,“ 2013.
[2]
S. Fluchs und H. Rudolph, „Wie OT-Security-Engineering eine Ingenieurwissenschaft
wird - Ein Denkmodell und ein Datenmodell,“ atp magazin, 2019.
[3]
E. Tastan, S. Fluchs und R. Drath, „Warum wir ein Security-Engineering-
Informationsmodell brauchen - Motivation, Anwendungsfälle und Konzept für ein neues
Domänenmodell für Security-Engineering,“ Hochschule für Technik, Wirtschaft und
Kultur Leipzig, 18. AALE-Konferenz. Pforzheim, 2022.
[4]
„IEC 62714 Ed. 2: Engineering data exchange format for use in industrial automation
systems engineering (AutomationML). International Electrotechnical Commission,“ IEC,
2018.
[5]
R. Drath (Ed.), AutomationML – The Industrial Cookbook, Berlin: De Gruyter Oldenbourg,
2021.
[6]
M. Rentschler, R. Drath, J. Hinze und A. Gatterburg, „AutomationML als generische
Beschreibungssprache für den Digitalen Zwilling,“ VDI-Verlag, Baden-Baden, 2019.
[7]
„DIN EN 62714-5: Datenaustauschformat für Planungsdaten industrieller
Automatisierungssysteme - Automation markup language - Teil 5: Kommunikation,“
2020.
[8]
S. Fluchs, N. Schmidt und A. Mendl-Heinisch, „Ein Systemmodell für Security-
Engineering,“ TeSi, vol. 9, no. 11–12, 2019.
[9]
S. Fluchs, „On Modelling for Security Engineering. fluchsfriction 37,“ 2021.
[10]
A. Scholz, „Unterstützung des Engineerings von fertigungstechnischen
Produktionssystemen mit Hilfe von Maschinenfunktionen - Methode, Modell und
Beschreibungsmittel für ein funktionsorientiertes Planen,“ Helmut-Schmidt-Universität /
Universität der Bundeswehr Hamburg, Hamburg, 2018.
[11]
„ISA/IEC 62443-3-2: Security for industrial automation and control systems - Part 3-2:
Security risk assessment for system design,“ 2020.
[12]
M. Eckhart, A. Ekelhart und E. R. Weippl, „Automated Security Risk Identification Using
AutomationML-based Engineering Data,“ IEEE Trans. Dependable and Secure Comput.,
2020.
[13]
BMWi, Plattform I4.0: Usage View of Asset Administration Shell, Berlin:, 2019.

[14]
„IEC 61987-4 - SC 65E/WG 2: Common Data Dictionary,“ [Online]. Available:
https://cdd.iec.ch/cdd/iec61987/iec61987.nsf/.
[15]
A. Bondza, C. Eck, R. Heidel, M. Reigl und S. Wenzel, „eCl@ss: Toward Smart
Manufactoring with Data and Semantics,“ eCl@ss e. V., Köln, 2018.
[16]
DMTF, „Common Information Model (CIM) Metamodel,“ 2014.
[17]
H. Zimmermann, „OSI Reference Model--The ISO Model of Architecture for Open
Systems Interconnection,“ IEEE Transactions on Communications.
[18]
M. Hoernicke, K. Stark und L. Urbas, „MTP – Automation Engineering of Modular Process
Plants,“ in AutomationML - The Industrial Cookbook, De Gruyter Oldenbourg, 2021, pp.
125-164.
[19]
R. Drath, S. Malakuti, S. Grüner, J. Grothoff, C. Wagner, U. Epple und M. Hoffmeister,
„Die Rolle der Industrie 4.0 „Verwaltungsschale“ und des „digitalen Zwillings“ im
Lebenszyklus einer Anlage - Navigationshilfe, Begriffsbestimmung und Abgrenzung,“
VDI-Verlag - Tagungsband zur Automation 2017, Baden-Baden, 2017.
[20]
BMWi - Plattform Industrie 4.0, „Verwaltungsschale in der Praxis,“ 2020.
[21]
BMBF, „IDEAS - Integrierte Datenmodelle zur Berücksichtigung von IT-Sicherheit im
Entwicklungsprozess industrieller Anlagen,“ 2021. [Online]. Available:
https://www.forschung-it-sicherheit-kommunikationssysteme.de/projekte/ideas.