Phoenix Contact

(Bild: Phoenix Contact)

  • CSAF 2.0 hat ein großes Potenzial, das Sicherheitsniveau in industriellen Anwendungen zu heben.
  • Das Framework beschreibt nicht nur die Datenformate, sondern ebenfalls den automatisierbaren Bezug der Sicherheitswarnungen.
  • Besonders wichtig sind Akzeptanz und Unterstützung der Security Community, damit CSAF 2.0 ein Erfolg wird.

Viele Cyberangriffe nutzen Schwachstellen in den Produkten aus. Bei den sogenannten Zero-Day-Attacken handelt es sich um Angriffsflächen, die den Produktherstellern oder -anwendern noch nicht bekannt sind. Solche Attacken lassen sich durch Maßnahmen der Cybersecurity abmildern, aber nicht verhindern. Zudem setzen Hacker häufig auch an Schwachstellen an, für die es bereits Sicherheitswarnungen (Security Advisories) gibt und gegebenenfalls schon Updates bereitstehen.

In diesem Fall haben die Anwender nicht oder nicht zeitnah auf die verfügbaren Informationen reagiert. Ein automatisiertes Schwachstellenmanagement kann dabei helfen, unnötige Verzögerungen zu vermeiden. Stand heute ist es üblich, dass die Produkthersteller oder die Certs (Computer Emergency Response Team) als Koordinatoren hinsichtlich der Veröffentlichung von Schwachstellen entsprechende Security Advisories als Dokumente publizieren, die von Menschen gelesen und ausgewertet werden müssen. Hierdurch entstehen relevante Aufwände und ein Zeitverlust: Sind die betroffenen Produkte überhaupt in der Anwendung eingesetzt? Tangiert die Sicherheitswarnung den derzeit installierten Versionsstand? Eine weitere Herausforderung liegt im Bezug der Informationen. Zumeist werden diese von den Produktherstellern auf deren Webseiten zur Verfügung gestellt und lassen sich zum Beispiel per E-Mail abonnieren. Einige Certs sammeln die Meldungen mehrerer Hersteller ein und verteilen diese dann weiter. Je nach Anspruch des jeweiligen Certs werden die Informationen aber verändert, weil das Cert sie auslegt und überarbeitet.

Herstellerunabhängige Verwaltung und Aktualisierung von Geräten

Device-and-Update-Management-Lösungen (Daum) verwenden im industriellen Umfeld oft ein herstellerspezifisches Verfahren, um auf proprietäre Weise eigene Dateien auf eigene Geräte zu verteilen und zu installieren. Mit dem auf OPC UA basierenden Daum-Service von Phoenix Contact ist die herstellerunabhängige Verwaltung und Aktualisierung von Automatisierungsgeräten möglich.

Hierbei kann es sich um Steuerungen, I/O-Module, Frequenzumrichter, Roboter, Netzwerkgeräte, Spannungsversorgungen oder weitere in der Automatisierungstechnik eingesetzte Komponenten handeln. Der Daum-Service nutzt den OPC UA-Standard 10000-100. Nicht nur die Option, viele verschiedene Komponenten aus dem Automatisierungssystem zu aktualisieren, ist dabei neu, sondern auch die Tatsache, dass die Security in allen Ebenen des Systems durchgängig ermöglicht wird. Sämtliche Kommunikation und alle Kommandos werden lediglich authentisiert und autorisiert durchgeführt, wobei streng auf die IEC 62443 referenziert wird. Eine weitere Facette des Daum-Services ist die Option, ihn auf unterschiedlichen Ebenen betreiben zu können. Er kann sowohl auf einem Edge-PC in der Anlage, einer zentralen Server-Instanz des Anwenders oder einem Automatisierungsgerät selbst verwendet werden – je nach Anwendungsfall und Systemgröße.

Standardisierte Warnungen hersteller­übergreifend bereitstellen

Vor diesem Hintergrund wird ein automatisiertes Schwachstellenmanagement benötigt, das Advisories automatisch bezieht und deren Auswertung unterstützt. Um diese Anforderungen erfolgreich umzusetzen, müssen die Sicherheitswarnungen in einem standardisierten sowie maschinenlesbaren Format vorliegen. Darüber hinaus sind Methoden zum interoperablen und herstellerübergreifenden Austausch der Informationen erforderlich. Mit dem Common Security Advisory Framework (CSAF) 2.0 ist nun ein erfolgversprechendes Format erhältlich. Es nimmt die Vorarbeiten des Common Vulnerabilty Reporting Frameworks (CVRF) 1.1 auf, das lediglich wenige Anwender verwendet haben. Das neue Format CSAF 2.0 wurde im Juni 2022 von der gemeinnützigen Standardisierungsorganisation Oasis freigegeben. Der frei verfügbare Standard stößt nicht nur im IT-Bereich auf großes Interesse, sondern ebenso in der Automatisierungswelt. Seine Verbreitung soll durch die Bereitstellung von Open Source Tools gefördert werden.

Identifikation der betroffenen Produkte über den Hersteller, Produktnamen und die Produktnummer („skus“, stock keeping number(s)) sowie die betroffene(n) Version(en).
Identifikation der betroffenen Produkte über den Hersteller, Produktnamen und die Produktnummer („skus“, stock keeping number(s)) sowie die betroffene(n) Version(en). (Bild: Phoenix Contact)

Die Security Advisories werden im CSAF 2.0 in einem JSON-Schema beschrieben. JSON (JavaScript Object Notation) hat sich als Datenformat weit etabliert und lässt sich sofort von modernen Programmierumgebungen interpretieren. Deshalb ist es möglich, bestehende Systeme zum Asset Management zu erweitern oder eigene Tools zu schreiben. Das Dateiformat umfasst alle Elemente, die für eine automatisierte Auswertung benötigt werden. Dazu gehören die Verwaltungsinformationen wie der Herausgeber des Advisories und der Ausgabestand. Beim betroffenen Produkt sind Hersteller und Produktname und/oder Produktnummer sowie die jeweiligen Versionsstände im CSAF 2.0 enthalten. Dabei handelt es sich um die in der Automatisierungstechnik üblichen Informationen. Auf der Grundlage dieser Daten kann das Asset Management einen automatischen Abgleich mit den in der Anwendung genutzten Produkten durchführen. Das spart wertvolle Arbeitszeit. Als Beispiel ist ein Advisory zur PLCnext-Produktfamilie dargestellt: „Multiple Linux component vulnerabilities fixed in latest PLCnext Firmware release 2023.0.0 LTS“. Dieses Advisory gilt beispielsweise für die PLCnext-Steuerung AXC F 2152. Die Beschreibungen der Schwachstellen mit der gängigen Bewertung gemäß Common Vulnerability Scoring System (CSVV) sowie die empfohlenen Gegenmaßnahmen entsprechen den herkömmlichen Sicherheitswarnungen, sind aber maschinenlesbar organisiert.

Umstellung auf CSAF 2.0

Phoenix Contact steht seinen Kunden seit vielen Jahren im Bereich der Cybersecurity zur Seite, unter anderem mit der Bereitstellung von Security Advisories. Deren Veröffentlichung erfolgt in Zusammenarbeit mit dem Cert@VDE als verantwortlicher CVE Numbering Authority (CNA). Das Psirt-Team (Product Security Incident Response Team) des Blomberger Unternehmens publiziert die Schwachstellenwarnungen anschließend unter https://www.phoenixcontact.com/psirt. Sowohl bei Phoenix Contact als auch beim Cert@VDE wird die Umstellung auf CSAF 2.0 vorbereitet. Die Anwender können die Advisories dann ebenfalls automatisiert in einem maschinenlesbaren Format beziehen. Zur Unterstützung des Managements der Geräte sowie beim Ausrollen von Patches bietet der Automatisierungsspezialist ein Device-and-Update-Management an.

PLCnext-Steuerung AXC F 2152
Das Psirt hat beispielsweise ein Advisory für die PLCnext-Steuerung AXC F 2152 veröffentlicht. (Bild: Phoenix Contact)

Ein weiteres wesentliches Element des Common Security Advisory Frameworks bildet die organisierte Verteilung der Information. Im Framework findet sich neben der Rolle des Herstellers als „Provider“ der Information ebenfalls die der Anbieter von Listen und Aggregatoren. Ein „CSAF Lister“ fungiert als eine Art Telefonbuch und übermittelt die Information, wo CSAF Advisories zu bekommen sind. Im Gegensatz dazu sammelt der „CSAF Aggregator“ die Advisories aus mehreren Quellen ein, um deren Abruf durch den Anwender zu erleichtern. Die Inhalte bleiben dabei unverändert. Der Anwender kann die CSAF-Dokumente also auf verschiedenen Wegen beziehen. Als Quellen dienen entweder die Produkthersteller selbst oder ein Cert als Aggregator, der die Advisories mehrerer Hersteller gebündelt zur Verfügung stellt. Zudem unterstützt ein sogenannter „Trusted Provider“ bei der Prüfung der Authentizität der Advisories durch digitale Signaturen im PGP-Format.

Maschinenlesbare Beschreibung einer Schwachstelle.
Maschinenlesbare Beschreibung einer Schwachstelle. (Bild: Phoenix Contact)

Hinterlegen der Versionsstände im Asset Management

Zur Auswertung der Advisories im Rahmen eines Asset Managements muss dieses die Informationen vorhalten, die für einen automatischen Abgleich notwendig sind. In der Automatisierungstechnik werden Produkte zumeist über den Hersteller- und Produktnamen oder die Produkt-/Bestellnummer identifiziert. Da Security Advisories oftmals bestimmte Versionsstände einer in der Anwendung eingesetzten Software oder Firmware betreffen, ist diese Information auch im Asset Management zu hinterlegen. Die inhaltliche Bewertung des Advisories bleibt weiterhin dem Anwender überlassen. Inwieweit eine gemeldete Schwachstelle tatsächlich Auswirkungen auf die Applikation hat, sollte im Asset Management dokumentier- und verfolgbar sein. Es bietet sich ferner an, die umgesetzte Lösungsstrategie ebenso aufzuzeichnen. Gleiches gilt für die Nachverfolgung des Realisierungsstands der neuen Schutzmaßnahmen. Sinnvollerweise sollte der Anwender über ein Device Management verfügen, das entweder in das Asset Management integriert ist oder eine eigenständige Lösung darstellt. Das Device Management steht dem Anwender im automatisierten Ausrollen von Updates oder Patches zur Seite.

Sie möchten gerne weiterlesen?