Die Asset Administration Shell im Kampf gegen Schwachstellen von Produktionsmaschinen

Wartung einer Maschine in einer belebten Produktionshalle

Quelle: Universität Stuttgart IFF/Fraunhofer IPA, Foto: Rainer Bez, Heike Quosdorf

Die Asset Administration Shell im Kampf gegen Schwachstellen von Produktionsmaschinen

Sicherheitslücken in der Software von Produktionsmaschinen sind eine ständige Gefahr. Sie zu finden und zu beheben ist aufwändig und teuer. Vertreter aus Wissenschaft und Industrie haben deshalb auf Basis der Asset Administration Shell einen interoperablen Datenaustausch entlang der gesamten Wertschöpfungskette entwickelt.

Veröffentlicht am 23.11.2023

Lesezeit ca. 8 Minuten

In einer zunehmend vernetzten Industrielandschaft gewinnt die Cyber-Sicherheit an Bedeutung. Schwachstellen in der komplexen industriellen Landschaft bleiben nicht selten unentdeckt, da der Abgleich von öffentlich gemeldeten Sicherheitslücken mit den eigenen Systemen einem mühseligen Puzzlespiel gleicht. Divergierende Bezeichnungen und das Fehlen eines lückenlosen Asset-Inventars erschweren das Erkennen von Risiken erheblich. Der manuelle Aufwand zur Identifikation und Zuordnung von Schwachstellen zu betrieblichen Komponenten frisst Zeit und Ressourcen.

Um Verschwendung anzugehen, entwickeln Wissenschaftler vom Fraunhofer IPA im Forschungsprojekt »InterOpera« gemeinsam mit Industriepartnern eine neue Softwarelösung auf Basis der Asset Administration Shell (AAS). Sie adressiert vor allem den interoperablen Datenaustausch von Schwachstellen und den dazugehörigen Informationen zum Beheben der Schwachstellen (Security Advisories) entlang der Wertschöpfungskette.

Das Dilemma der Schwachstellenbewältigung

Vorhandene Schwachstellen in Softwarekomponenten sind ein offenes Tor für Angreifer. Sicherheitslücken und Security Advisories werden zwar in öffentlichen Repositories aufgeführt, etwa in der National Vulnerability Database oder im VDE CERT. Doch die Verbindung zu den tatsächlich im Einsatz befindlichen Systemen bleibt häufig unklar. Das gleicht einer Bibliothek, in der jedes Buch in einer anderen Sprache verfasst ist – die Aufgabe, relevante Inhalte zu finden, wird zur Sisyphusarbeit. Genauso verhält es sich mit der manuellen Zuordnung von Sicherheitshinweisen zu den Unternehmenskomponenten. Die Betreiber von Produktionsmaschinen müssen die Schwachstellen und Security Advisories der Hersteller manuell mit viel Aufwand mit den im Unternehmen vorhandenen Komponenten abgleichen. Zum einen gibt es Unterschiede bei der Benennung, zum anderen setzt dies ein umfassendes Asset-Inventar mit detaillierten Komponenteninformationen voraus, das jedoch oft nicht in dem gewünschten Umfang vorhanden ist.

Screenshot einer Tabelle
Abbildung 1: Der Markt bietet bisher Systeme, die nur das Software-Inventar und die Schwachstellen einzelner Komponenten aufzeigen. (Quelle: Sonatype)

Der Markt bietet aktuell Lösungen, wie sie Abbildung 1 zeigt: Systeme, die das Software-Inventar und die Schwachstellen einzelner Komponenten aufzeigen. Allerdings handelt es sich meist um proprietäre Systeme. Ein Hersteller könnte diese für seine Produkte nutzen. Doch ein Betreiber, der mit Maschinen verschiedener Hersteller arbeitet, steht vor einer Herausforderung. Die Daten aus den verschiedenen Herstellersystemen sind oft nicht kompatibel. Für Betreiber wird es somit schwierig, die nötigen Informationen zeitnah und mit vertretbarem Aufwand zusammenzuführen. An dieser Stelle wird die Interoperabilität entscheidend – sie ist der Schlüssel zum effizienten Informationsaustausch entlang der gesamten Wertschöpfungskette.

An diesen Stellen könnte die Asset Administration Shell (AAS) Unterstützung bieten, indem es eine eindeutige Zuordnung zwischen Schwachstellen, Security Advisories und Komponenten in interoperablem Format herstellt.

Die Asset Administration Shell und ihre Teilmodelle schaffen Interoperabilität

Die AAS wurde als Abbildung des Digitalen Zwillings für industrielle Assets auf der Grundlage von internationalen Industrie-4.0-Standards entwickelt. Die Struktur und das Metamodell der AAS wurden in der internationalen Normenreihe IEC 63278 spezifiziert und standardisiert. Die enthaltenen Informationen können in einem zusammengesetzten Dateiformat mit der Erweiterung ».aasx« gespeichert werden und über technologie-spezifische Schnittstellen in AAS ausgetauscht werden.

Die Teilmodelle sind die Hauptinformationsträger der AAS, die je einen bestimmten Aspekt des dazugehörigen Assets darstellen. Sie sind sowohl für Menschen als auch für Maschinen lesbar und ermöglichen damit einen automatisierten Austausch von Informationen durch Software. Ein Teilmodell besteht aus einer hierarchischen Anordnung von mehreren Submodel Elements (SME). Die verschiedenen SME-Typen, unter anderem Property, File, Multi Language Property (MLP) oder Reference Element, erfüllen unterschiedliche Funktionen bei der Beschreibung und Unterscheidung von Assets aus spezifischen Perspektiven. Eine umfassende Liste und Erklärung der SMEs findet sich im aktuellen Entwurf zu Teil 1 der Normenreihe IEC 63278.

Die Interoperabilität wird durch die standardisierte Semantik und Syntax der AAS gewährleistet. Die Syntaxspezifikationen beziehen sich auf das standardisierte Metamodell der AAS sowie auf standardisierte Teilmodellvorlagen, die die Regeln und das Format für die Strukturierung und Darstellung der Daten für die entsprechenden Anwendungsfälle festlegen. Die Entwicklung von Teilmodellvorlagen wird hauptsächlich innerhalb der AAS-Gemeinschaft vorangetrieben. Hierzu gehören solch wesentliche Akteure wie die Nutzerorganisation Industrial Digital Twin Association (IDTA), die nationalen Projekte wie InterOpera oder Catena-X, die entsprechenden Spiegelgremien in DKE/VDE-Gremien sowie die Plattform Industrie 4.0. Die standardisierten Teilmodellvorlagen werden kontinuierlich von den entsprechenden Arbeitsgruppen weiterentwickelt und aktualisiert. Die Semantik bezieht sich auf die gemeinsame Bedeutung und den Kontext der in der AAS enthaltenen Informationen. Dies wird unter anderem durch die Verwendung von standardisierten Merkmalen geregelt. Die SMEs der Teilmodelle können über eindeutige Identifikationen auf die bestehenden standardisierten Datenspezifikationen wie dem IEC Common Data Dictionary (CDD) und ECLASS verweisen. Damit soll sichergestellt werden, dass die Daten in verschiedenen Systemen und Kontexten konsistent und sowohl von Menschen als auch von Maschinen korrekt interpretiert werden.

AAS-Teilmodell-Vorlage für Software Bill of Material und Vulnerability Management

Im Rahmen des Forschungsprojekts InterOpera wurde eine Expertengruppe zur Entwicklung der AAS-Teilmodell-Vorlage für Software Bill of Material (SBoM) und Vulnerability Management gegründet. Zu den Mitgliedern der Expertengruppe gehören die Class.Ing Ingenieur-Partnerschaft, die Technische Hochschule Ostwestfalen-Lippe, Verband der Elektrotechnik Elektronik Informationstechnik (VDE), das Bundesamt für Sicherheit in der Informationstechnik sowie die Firmen Hegla New Technology, ifm electronic und bill-X.

Die Definition von Schwachstellen geschieht entweder durch den Anbieter oder Hersteller selbst in Form von Advisories oder standardisiert in zentralen Vulnerability-Datenbanken. Für die Beschreibung und den Austausch wird auf standardisierte Formate zurückgegriffen. Die Beschreibung von Schwachstellen, der Verweis auf bestehende Datenquellen und die Bewertung der Schwachstellen wird im Teilmodell »Vulnerability Management« abgebildet. Um die identifizierten Schwachstellen präzise den physischen Komponenten zuordnen zu können, wird das Teilmodell SBoM herangezogen. Das SBoM stellt ein formelles, maschinenlesbares Inventar von Software-Komponenten und deren Abhängigkeiten sowie Informationen über diese Komponenten und ihre hierarchischen Beziehungen dar.

In Abbildung 2 werden zwei unterschiedliche Datenflüsse betrachtet. Die bunten Pfeile stellen dabei den Datenfluss durch die Verwaltungsschalen und die schwarzen Pfeile den Datenfluss über Advisories oder Vulnerability-Datenbanken dar. Die durchgängige Verwendung gleicher AAS-Teilmodellvorlagen und die Weiternutzung der Daten entlang der Wertschöpfungskette haben einen großen Vorteil. Denn es wird auf bereits existierende und etablierte Standardformate gesetzt, die entsprechend integriert werden. Mit diesem Vorgehen wird eine Zuordnung zwischen konkreten Assets und Schwachstellen ermöglicht.

Datenflüsse
Abbildung 2: Zwei unterschiedliche Datenflüsse. (Quelle: Class.Ing Ingenieur-Partnerschaft)

Außerdem können die aktuellen Informationen einfach zwischen Akteuren ausgetauscht werden. Die aus den Komponenten erstellte Maschine berücksichtigt sowohl die Schwachstellen der einzelnen Komponenten als auch mögliche Schwachstellen, die durch die Konstruktion der Maschine hinzugefügt wurden. Der Integrator stellt zunächst einen Typ AAS mit allen Ausführungen der Maschine zur Verfügung. Wenn die Maschine an den Operator übergeben wird, erstellt der Integrator auch eine Instanz der AAS, die den »As-Built«-Zustand darstellt und ebenfalls übertragen wird. Der Bediener erhält die Instanz AAS (As-Built) der Maschine und nutzt diese weiter im Inneren. Dies macht die AAS zu einer »Ist«-AAS, für die der Operator verantwortlich ist. Wenn Schwachstellen vom Integrator an den Operator gemeldet werden, liegt es in der Verantwortung des Betreibers, diese für sich in seinem Umfeld zu bewerten und in VEX-Einträgen zu kommentieren.

Ihre Ansprechpartner

B.Sc. Olga Meyer

Leiterin der Gruppe Interoperabilität für die digitale Produktion
Telefon: +49 711 970-1068

Dachuan Shi

Mitarbeiter der Gruppe Interoperabilität für die digitale Produktion
Telefon: +49 711 970-1203