Neue Sicherheitsmeldung: Welche unserer Maschinen ist betroffen?

Freitag, 14:37 Uhr. Der Steuerungslieferant meldet eine Sicherheitslücke. Betroffen ist sein Controller X200 mit Firmware 5.1 bis einschließlich 5.4.

„Haben wir die irgendwo verbaut?“

Natürlich haben wir eine Stückliste. Sogar mehrere. Im Einkauf heißt die Steuerung allerdings 6AB1234, im Engineering „PLC Hauptanlage“. Und die Firmware wurde beim letzten Service aktualisiert. Vermutlich.

Für den Abgleich mit der Sicherheitsmeldung ziehen wir auch die Software Bill of Materials, kurz SBOM, heran. Sie beschreibt die Softwarekomponenten unseres Produkts. Jetzt müssen wir die Angaben des Lieferanten mit unseren Produktunterlagen und den tatsächlich installierten Versionsständen verbinden. Denn beantworten müssen wir:

Welche unserer ausgelieferten Maschinen müssen wir jetzt prüfen?

Folgen wir dieser Frage an einer fiktiven Maschine. Sie hat einen Industrie-PC für die Bedienoberfläche, eine speicherprogrammierbare Steuerung und drei intelligente Sensoren. Also einen IPC, eine PLC und genügend Abkürzungen für einen ganz normalen Schaltschrank.

Erst einmal die richtige Maschine finden

In der Meldung steht ein Produktname mit einem Firmwarebereich. Unsere Unterlagen müssen uns jetzt verraten, welche zugekaufte Steuerung dazugehört und in welchen Maschinen wir sie eingesetzt haben.

Beim IPC hilft uns die Softwarestückliste der Bedienanwendung: welche Bibliotheken wir verwendet und welche Version wir ausgeliefert haben. Was später auf dem Rechner installiert oder aktualisiert wurde, müssen wir zusätzlich erfassen.

Bei der PLC brauchen wir die Produktkennung des Lieferanten und den Firmwarestand. Eine eigene SBOM des Lieferanten kann weitere Softwaredetails liefern. Die interne Bezeichnung „PLC Hauptanlage“ reicht für den Abgleich mit seiner Meldung offensichtlich nicht weit.

Bei den Sensoren stellt sich dieselbe Grundfrage: Welcher Typ ist verbaut, welche Firmware läuft darauf und welches konkrete Gerät ist es? Einige dieser Informationen lassen sich bereits über die vorhandene Geräteschnittstelle auslesen.

Für unsere Freitagsmeldung führt die Spur zur PLC. Wir ordnen den Controller X200 der Bestellnummer 6AB1234 zu. Im Inventar finden wir 38 ausgelieferte Maschinen mit diesem Steuerungstyp. Bei 17 davon ist Firmware 5.3 dokumentiert.

Das ist endlich eine brauchbare Liste. Vorausgesetzt, die Versionsdaten sind aktuell. Ein Eintrag „5.3, zuletzt erfasst vor neun Monaten“ erzählt uns vor allem etwas über die Vergangenheit.

Wir gleichen deshalb die dokumentierten Stände mit aktuellen Gerätedaten oder nachvollziehbaren Serviceaufzeichnungen ab. Bleibt eine Version unbekannt, bleibt die Installation auf der Prüfliste. Fehlende Daten sind keine Entwarnung.

Am Ende unseres Beispiels bestätigen sich die 17 Installationen mit Firmware 5.3; die übrigen 21 liegen außerhalb des genannten Versionsbereichs. Jetzt können wir die Hinweise des Lieferanten für diese 17 Maschinen bewerten: Ist die betroffene Funktion im Einsatz? Welche Schutzmaßnahmen oder Updates sind nötig? Die konkrete Ausnutzbarkeit müssen wir dabei noch beurteilen.

Die SBOM hat uns beim Finden der Komponente geholfen. Für die Liste der Maschinen brauchten wir zusätzlich Produktkennungen, aktuelle Versionsstände und die Zuordnung der einzelnen Steuerungen zu ihren Maschinen.

Bis hierhin ging es um eine einfache Frage. Dass wir dafür gleich mehrere Standards brauchen, haben wir als Branche selbst eingerichtet. Schauen wir kurz unter die Haube.

Drei Fragen, die wir auseinanderhalten müssen

Bevor wir den Schaltschrank noch einmal durchgehen, lohnt sich eine kleine Sortierung:

Die Seriennummer bleibt bei einem Firmware-Update gleich. Der Versionsstand ändert sich. Tauschen wir dagegen die Steuerung aus, steht an derselben Stelle der Maschine eine neue Geräteinstanz. Auch das muss unser Inventar unterscheiden können.

Für eine eindeutige Instanzidentität braucht eine Seriennummer außerdem einen passenden Gültigkeitsbereich, etwa Hersteller und Modell. 4711 allein hat vermutlich noch jemand vergeben.

Manchmal benötigen wir zusätzlich die Identität einer ganz bestimmten Datei. Dafür kann ein kryptografischer Hash einer Firmware-Datei dienen. Er hilft beim Vergleich mit einem bekannten Artefakt, verrät aber noch nicht, auf welchen Maschinen dieses installiert ist.

Mit dieser Unterscheidung bekommen die folgenden Verfahren ihren Platz: Manche benennen Softwareprodukte, andere liefern Gerätedaten oder machen deren Austausch möglich.

Am IPC: Welche Software steckt drin, welche ist installiert?

Auf unserem IPC läuft eine Bedienanwendung. Für deren Bibliotheken haben Paketmanager schon viel Vorarbeit geleistet: Sie kennen Paketnamen, Versionen und gegebenenfalls einen Namespace.

Eine Package URL (PURL) bringt diese Angaben in eine standardisierte Schreibweise. Für eine .NET-Bibliothek sieht das beispielsweise so aus:

pkg:nuget/Newtonsoft.Json@13.0.3

Damit lässt sich das Paket in einer SBOM genauer beschreiben als mit „die JSON-Bibliothek“. Die PURL-Spezifikation legt fest, wie solche Kennungen aufgebaut sind. Für den Abgleich mit Schwachstelleninformationen muss die verwendete Datenquelle das Paket und seine Version allerdings ebenfalls zuordnen können.

Eine zweite Frage lautet: Welche Softwareprodukte sind auf dem IPC tatsächlich installiert? Hier können Software Identification Tags (SWID) helfen. Sie beschreiben Software unter anderem mit Name, Version und Herstellerinformationen. Im von NIST beschriebenen Lebenszyklus werden die Tags mit der Software installiert und bei ihrer Deinstallation wieder entfernt.

Praktische Einsatzfelder sind Softwareinventarisierung und Lizenzmanagement. Adobe nutzt SWID beispielsweise zur Unterscheidung von Installations- und Lizenzvarianten, IBM im Umfeld seines License Metric Tools.

Für unseren IPC ist das eine mögliche Informationsquelle, wenn der Softwarehersteller Tags bereitstellt, sie bei Änderungen pflegt und unser Inventarsystem sie auswertet. Allein aus dem Betriebssystem können wir diese Unterstützung nicht ableiten. Windows ist auch keine Voraussetzung: Die RHEL-8.0-Release-Notes beschreiben in Abschnitt 5.1.15 „Security“ SWID-Dateien unter /usr/lib/swidtag/redhat.com/. Diese identifizieren die RHEL-Installation selbst; eine vollständige Inventarisierung aller darauf installierten Anwendungen ist damit noch nicht gegeben.

Der IPC bleibt als Bedienrechner Teil der OT. Seine Software wird aber auf eine Weise installiert und verwaltet, die wir aus der IT kennen. Genau deshalb passt SWID hier in die Geschichte. Für die Firmware einer PLC würden wir zunächst klären, welche Identifikationsdaten der Lieferant tatsächlich bereitstellt.

Und auch ein korrekt erfasster SWID-Tag braucht noch den Gerätebezug: Auf welchem IPC wurde er gefunden, und zu welcher Maschine gehört dieser Rechner?

An der PLC: Das Gerät nach seinem Namen fragen

Zurück zu unserer Steuerung. Ihre Identität suchen wir am besten dort, wo Produkt und aktueller Versionsstand zusammenkommen: am Gerät selbst.

Damit wird OPC UA interessant. Viele verbinden damit zunächst den Austausch von Prozesswerten. Die zugehörigen Informationsmodelle können aber auch festlegen, wie sich eine Maschine oder Komponente beschreibt. OPC UA for Machinery behandelt die eindeutige Maschinenidentifikation ausdrücklich als Anwendungsfall.

Die Maschine kann also Auskunft über sich geben. Wir müssen ihr nur auch Fragen stellen, die über die aktuelle Drehzahl hinausgehen.

Das elektronische Typenschild aus OPC UA Devices sieht unter anderem Hersteller, Modell, Produktcode, Hardware- und Software-Revision sowie Seriennummer vor. Für unseren fiktiven Controller könnte ein entsprechend implementiertes Modell diese Angaben liefern:

ProductCode         = 6AB1234
SoftwareRevision    = 5.3
SerialNumber        = X200-001847
ProductInstanceUri  = https://example-automation.com/x200/X200-001847

Die ProductInstanceUri dient als global eindeutige Kennung der konkreten Instanz. In den Machinery-Identifikationsmodellen soll sie über deren Lebenszyklus stabil bleiben.

Deshalb kommt OPC UA hier vor: Passende Informationsmodelle geben den auslesbaren Angaben eine vereinbarte Bedeutung. Unser Inventarsystem muss dann nicht für jeden Lieferanten neu erraten, welches Feld den Produktcode enthält.

Ein OPC-UA-Server allein garantiert diese Daten allerdings noch nicht. Wir müssen prüfen, welche Modelle und Felder das Gerät unterstützt und was sein gemeldeter Softwarestand umfasst. Die Firmware-Revision ist beispielsweise noch keine Liste aller darin enthaltenen Bibliotheken.

Am Sensor: Das Typenschild ist schon digital

Unsere drei Sensoren hängen an PROFINET. Auch dort gibt es einen Ansatzpunkt: die Identification & Maintenance Functions, kurz I&M.

Die PI-Richtlinie zu I&M beschreibt diese Funktionen für Geräteidentifikation, Wartung und Asset Management. Sie können unter anderem Bestellnummer, Seriennummer sowie Hardware- und Softwarestände zugänglich machen.

Für unser Inventar ist das wertvoll: Wir können Produkt, Instanz und gemeldeten Versionsstand gemeinsam erfassen. Anschließend müssen wir die Bestellnummer noch der Bezeichnung zuordnen, die der Lieferant in seinen Sicherheitsmeldungen verwendet.

Dabei prüfen wir auch die Aussagekraft der Werte. Ein fehlender oder nicht aussagekräftiger Softwarestand lässt sich nicht zuverlässig mit einem betroffenen Firmwarebereich vergleichen. Dann brauchen wir einen anderen Nachweis, etwa aus einem Engineering Tool oder vom Lieferanten.

OPC UA und PROFINET I&M stehen hier also wegen der vorhandenen Zugänge zu Gerätedaten. Welche Quelle wir nutzen, hängt von der Komponente und ihrer Implementierung ab. Unser Ziel bleibt derselbe Inventareintrag: Produkt, Geräteinstanz, Versionsstand und Zeitpunkt der Erfassung.

Zurück am Schreibtisch: Wie bleiben die Daten verbunden?

Wir haben jetzt Produktinformationen aus der Entwicklung, Identitäten aus den Geräten und die Zuordnung zu ausgelieferten Maschinen. Diese Verbindungen müssen auch nach dem nächsten Update, Serviceeinsatz oder Systemwechsel noch nachvollziehbar sein.

Hier bekommt die Asset Administration Shell (AAS), auf Deutsch Verwaltungsschale, ihren Platz. Man kann sie sich für diesen Zweck als strukturierte digitale Geräteakte vorstellen. Ihr Metamodell berücksichtigt eine globale Asset-ID und zusätzliche Kennungen, beispielsweise aus Hersteller- und Kundensystemen.

Die AAS kommt hinzu, weil wir die Informationen über ein Asset über System- und Unternehmensgrenzen hinweg austauschen wollen. Für den Maschinenbauer und den Betreiber soll erkennbar bleiben, auf welches Gerät sich eine Information bezieht.

Technisch heißt die globale Asset-Kennung globalAssetId; weitere Kennungen lassen sich als specificAssetIds zuordnen. Die Verwaltungsschale selbst hat eine eigene ID. Ein Produktcode braucht dabei weiterhin Kontext: Er bezeichnet gewöhnlich einen Typ und identifiziert für sich allein keine einzelne Steuerung.

Über passend gestaltete Submodelle und Referenzen lassen sich weitere Produktdaten und SBOM-Bezüge einordnen. Die Beziehungen zwischen Maschine und Komponenten sowie die Pflege der Versionsstände müssen wir bewusst vorsehen. Die AAS aktualisiert sich nicht von selbst, wenn der Service am Freitag eine neue Firmware einspielt.

OPC UA und AAS ergänzen sich in unserem Beispiel: Über geeignete OPC-UA-Modelle lesen wir Geräteinformationen; mit der AAS können wir zugehörige Daten strukturiert weitergeben. Das ist eine mögliche Architektur. Auch ein bestehendes Asset- oder Service-System kann die benötigten Zuordnungen führen.

Und wie findet die Sicherheitsmeldung unser Produkt?

Die Meldung des Lieferanten muss zu diesen Daten passen. Hier begegnen uns noch zwei Begriffe mit unterschiedlichen Aufgaben.

Common Platform Enumeration (CPE) bezeichnet Produktklassen, etwa Anwendungen, Betriebssysteme oder Hardware, mit Merkmalen wie Hersteller, Produkt und Version. Die National Vulnerability Database verwendet CPE für die Zuordnung betroffener Produkte. Wenn wir diese Datenquelle nutzen, brauchen wir die passende CPE-Zuordnung. Ein selbst erfundener, plausibel aussehender Name genügt dafür nicht.

Common Security Advisory Framework (CSAF) macht die Sicherheitsmeldung selbst maschinenlesbar. Der CSAF-2.0-Standard bietet Identifikationshilfen wie CPE, PURL, Modellnummern, Seriennummern, Hashes und SBOM-Referenzen. Welche davon vorhanden sind, entscheidet der Herausgeber des Advisorys.

Für unsere PLC könnte die Meldung den Controller X200 mit Modellnummer 6AB1234 und Firmware 5.1 bis einschließlich 5.4 nennen. Unser Inventar kennt dieselbe Modellnummer, Firmware 5.3 und die Geräteinstanz in Maschine M-038. Damit lässt sich die Installation der Meldung zuordnen.

So entsteht die Verbindung, die wir am Anfang gesucht haben:

Advisory: Controller X200, Firmware 5.1 bis 5.4
    ↓ Produktkennung zuordnen
Bestellnummer 6AB1234 in unseren Produktunterlagen und SBOMs
    ↓ mit aktuellem Inventar abgleichen
Steuerung X200-001847, Firmware 5.3
    ↓ Einbauzuordnung verfolgen
Maschine M-038 beim Kunden → gezielt bewerten

Wir brauchen dafür diejenigen Kennungen und Datenmodelle, die unsere Lieferanten, Geräte und Systeme tatsächlich verwenden. Ihre Zuordnung sollte bereits stehen, wenn die nächste Meldung eintrifft.

Was das mit dem CRA zu tun hat

Der Cyber Resilience Act sieht in Anhang I Teil II die Identifikation und Dokumentation von Schwachstellen und enthaltenen Komponenten vor, einschließlich einer maschinenlesbaren SBOM mindestens für die Top-Level-Abhängigkeiten. Anhang II verlangt außerdem Informationen zur eindeutigen Identifikation des Produkts.

Für die hier beschriebenen Aufgaben legt der CRA keinen bestimmten Identifier wie PURL oder CPE und keine Architektur mit OPC UA oder AAS fest. Die praktische Aufgabe bleibt: Eine Lieferantenmeldung muss sich dem eigenen Produkt zuordnen lassen. Für Maßnahmen beim Kunden brauchen wir anschließend die Verbindung zu den ausgelieferten Instanzen.

Diese Verbindung gehört deshalb in die Produktentwicklung und in den Serviceprozess. Bei jedem Update muss der dokumentierte Stand mitziehen; bei jedem Komponententausch die Einbauzuordnung. Eine neue Marketingbezeichnung darf die bisherige Produktkennung nicht unauffindbar machen.

Mit Lieferanten würde ich dafür vor allem fünf Fragen klären:

• Welche Produktkennung verbindet eure Dokumentation, SBOM und Sicherheitsmeldungen?
• Wie lesen wir Hardware- und Softwarestände aus, und was genau beschreiben diese Werte?
• Wie identifizieren wir ein einzelnes Gerät über Updates hinweg eindeutig?
• Welche maschinenlesbaren SBOMs und Advisories liefert ihr, und bleiben Informationen zu alten Releases verfügbar?
• Wie erkennen und dokumentieren wir Updates oder einen Gerätetausch im Feld?

Freitag, die zweite

Beim nächsten Advisory wollen wir wieder dieselbe Frage stellen dürfen: „Haben wir die irgendwo verbaut?“

Diesmal finden wir die Produktkennung, gleichen den betroffenen Versionsbereich mit dem aktuellen Inventar ab und erhalten eine Liste konkreter Maschinen. Die Bewertung und die Planung der Maßnahmen bleiben Arbeit. Aber wir können damit anfangen.

Vielleicht ist der Kaffee dann sogar noch warm.

Wie verknüpfst du SBOMs, Gerätedaten und ausgelieferte Maschinen? Diskutiere mit uns auf LinkedIn.