Das vom NAMUR-Arbeitskreis 1.3 „Informationsmanagement und Werkzeuge“ unter der Leitung von Andreas Schüller, Yncoris, erarbeitete Dokument beschreibt ein UML-Informationsmodell (Unified Modeling Language ist eine visuelle Modellierungssprache für die Architektur, das Design und die Implementierung von komplexen Softwaresystemen und besteht aus verschiedenen Diagrammarten), das die für das Automation Security Engineering notwendigen und während des Security Engineering entstehenden Informationen beinhaltet. Es ist für das Automation Security Engineering in der Design- und Betriebsphase eines Automatisierungssystems nutzbar und kann von Herstellern, Integratoren und Betreibern gleichermaßen verwendet werden – branchen- und standortunabhängig.

Der Anwendungsbereich des Informationsmodells ist die Dokumentation der Informationen, die beim Security-Engineering eines Automatisierungssystems verwendet und/oder erzeugt werden. Es dokumentiert also die Security von Automatisierungssystemen. Die Security der Informationen im Informationsmodell wird in dieser NAMUR-Empfehlung nicht betrachtet.

Zielsetzung

„Heutzutage wird die OT-Security meist nachgelagert zum Engineer­ing des Automatisierungssystems betrachtet. Durch das in der NE 193 beschriebene Informationsmodell kann die OT-Security früher und verzahnter mit anderen Gewerken im Planungsprozess diskutiert und direkt im Modell dokumentiert werden. Die NE 193 ermöglicht ein Security by Design von Automatisierungssystemen in der Prozessindustrie“ erläutert Andreas Schüller gegenüber CHEManager. Und Sarah Fluchs von Admeritia, die maßgeblich an der Erstellung des Dokuments beteiligt war, betont: „Das Security Engineering für Automatisierungssysteme ist eine ziemlich junge Disziplin; es ist noch nicht so klar wie in anderen Domänen, was genau eigentlich „Automation Security-Daten“ sind. Mit der NE 193 haben wir dafür einen ersten Wurf gemacht – und zwar gleich so, dass die Daten auch digital verarbeitet werden können, also in einem formalen UML-Informationsmodell.“

    Andreas Schüller, Yncoris

„Mit dem in der NE 193 beschriebene Informationsmodell kann die OT-Security früher und verzahnter diskutiert und dokumentiert werden.“

Anwendungsfälle

„Verwaltungsschale, digitaler Zwilling, Industrie 4.0: Alle Ingenieur­domänen sind gerade dabei, ihre über Jahrzehnte analog angesammelten Daten digital verfügbar zu machen. Damit das klappt, braucht man Informationsmodelle“ ordnet Fluchs das Dokument ein, das für das Automation Security Engineer­ing verschiedene Anwendungsfälle hat:

• Informationsaustausch zwischen Security-relevanten Planungswerkzeugen:

Security-relevante Informationen gibt es in vielen verschiedenen Softwarewerkzeugen bzw. Dateien: in IT Administrationstools wie Asset-Inventaren, Konfigurationsmanagement- oder Versionierungstools, in dedizierten Security Tools wie Anomalieerkennungs- oder Intrusion-Detection-Systemen, aber auch in Engineering-Werkzeugen, die Risikobetrachtungen oder architekturelle Entscheidungen enthalten. Es ist unwahrscheinlich, dass diese verschiedenen Werkzeuge ihre Datenformate in absehbarer Zeit harmonisieren werden, weshalb ein neutrales Informationsmodell zum Austausch der Security-relevanten Informationen die pragmatischere Lösung zu sein scheint.

• Modellbasiertes Security Engineering und Security by Design:

Ein Informationsmodell ist die Basis, um modellbasiertes Security Engineering zu ermöglichen und flexible Visualisierungen des zu schützenden Systems, seiner Security-Probleme bzw. der Security-Lösungen zu erzeugen. Ein Informationsmodell für das Security Engineering hilft auch dabei, Security möglichst früh in den Automation-Engineer­ing-Workflow zu integrieren (Security by Design) – so kann man schon Security-Entscheidungen treffen, auch wenn das Detail Engineering noch nicht abgeschlossen ist.

   Sarah Fluchs, Admeritia

„Der Austausch von Informationen zwischen Herstellern und Betreibern wird wichtig vor dem Hintergrund des Cyber Resilience Act.“

• Treffen von Security-Entscheidungen während des Betriebs:

Security-Entscheidungen wie das Patchen einer Schwachstelle oder das Anwenden einer Alternativmaßnahme für Schwachstellen, für die kein Patch verfügbar ist, erfordern Kontextinformationen aus typischerweise verschiedenen Quellen. Relevant sind z. B. der Schweregrad der Schwachstelle, die bestehenden Risiken und frühere Vorfälle für eine Komponente, die Kritikalität des Versagens oder der Manipulation der Komponente, die Netzwerkexposition der Komponente und die Kritikalität der daran angeschlossenen Komponenten. Diese Informationen sind jedoch wahrscheinlich an verschiedenen Orten gespeichert und müssten zeitaufwändig gesammelt und verarbeitet werden – sofern sie überhaupt verfügbar sind. Ein Informationsmodell hilft, alle Security-relevanten Engineering-Informationen auch in der Betriebsphase noch verfügbar zu haben.

• Verwaltung von Standardkonfigurationen:

Effizienzgewinne im Betrieb von Security-Lösungen ergeben sich oft aus der Standardisierung von Komponenten und ihren Konfigurationen. Diese Standards müssen maschinenverarbeitbar gespeichert, gepflegt und verwaltet werden. Selten deckt ein Tool alle relevanten Informationen ab. Solche Standardkonfigurationen über viele Tools verteilt zu speichern und zu pflegen ist jedoch fehleranfällig und ineffizient.

   Björn Höper, LTsoft

„Eine zunehmende externe Bedrohungslage macht ein systematisches Management der Security unumgänglich.“

Ausblick

Für all diese Anwendungsfälle besteht der Wert des Informationsmodells in der Einigung auf ein generisches Modell, das alle Beteiligten nutzen. Das Ziel der NAMUR-Em­pfehlung ist, einen Vorschlag für solch ein konsensfähiges Modell zu machen. Fluchs dazu: „Wir hoffen auf breite Nutzung und viele Verbesserungsvorschläge aus der Praxis, denn ein Informationsmodell ist nur dann etwas wert, wenn es viele nutzen. Damit wäre es zum Beispiel möglich, relevante Informationen für das Automation Security Engineering zwischen Herstellern und Betreibern auszutauschen – das wird wichtig vor dem Hintergrund des Cyber Resilience Act, oder zwischen verschiedenen Security-Tools, die ein Betreiber im Einsatz hat – zum Beispiel Asset Inventory-, Intrusion Detection- und Risikoanalyse-Tools.“ Und Björn Höper von LTsoft, ebenfalls Mitglied des AK 1.3, fasst die Notwendigkeit zur Umsetzung eines systematischen Managements der Security in der Prozessindustrie zusammen: „Als IT/OT-Systemintegrator erleben wir eine deutliche Beschleunigung der notwendigen Anpassungen an den Landscapes unserer Kunden und eine ebenso deutliche Zunahme der Komplexität. Die Verbindung dieser Faktoren mit steigenden regulatorischen Anforderungen wie bspw. NIS2 und einer zunehmenden externen Bedrohungslage machen ein systematisches Management der Security unumgänglich, um die Intellectual Property und die Betriebsfähigkeit der Unternehmen zu schützen. Mit dem Security-Informationsmodell haben wir ein Werkzeug geschaffen, mit dem diese Aufgabe formalisiert und effizient erledigt werden kann.“

Autor: Volker Oestreich, CHEManager