Auf Grund der Softwarekomplexität einzelner Baugruppen in einer vernetzten OT-Umgebung muss man davon ausgehen, dass in jeder einzelnen Installation zahlreiche bekannte Cyberschwachstellen existieren. Sie werden von IT-Sicherheitsexperten als CVEs bezeichnet und inzwischen sogar systematisch gesucht und erforscht. In der IT-Welt ist es üblich, für jede identifizierte Schwachstelle eine direkte oder indirekte Korrekturmaßnahme (Patch) zu entwickeln, um die entsprechende Sicherheitslücke zu schließen. Hinsichtlich der Automatisierungstechnik entspricht dieses Verhalten sowohl bei Produktanbietern als auch Nutzern noch nicht dem aktuellen Stand der Technik. Bedingt durch neue EU-Verordnungen, wie die NIS-2-Richtlinie, den Cyber Resilience Act (CRA), aber auch den Cybersicherheitsaspekten in der neuen Maschinenverordnung 2023/1230 sowie dem Zusammenhang zur CE-Kennzeichnung, wird sich dieser Zustand grundlegend ändern.
CVEs sind öffentlich
Die Abkürzung CVE steht für Common Vulnerabilities and Exposures. Mit ‚Vulnerabilities‘ sind hier ganz allgemein bekannte Sicherheitslücken und Schwachstellen in Computersystemen gemeint. ‚Exposures‘ bedeutet in diesem Kontext in etwa ‚Enthüllen‘ bzw. ‚Aufdecken‘. Hinter der CVE-Idee steht ein umfangreiches Programm, das Ende 1999 von US-Sicherheitsorganisationen geschaffen wurde, um IT-Sicherheitslücken zu erfassen und in einem Standarddatenformat zu veröffentlichen. Dadurch wurde ein Referenzsystem zur kontinuierlichen Verbesserung der Cybersicherheit erschaffen. Inzwischen beteiligen sich im Rahmen einer hierarchischen Organisationsstruktur zahlreiche internationale Partner am CVE-Programm. Als Root-Organisation dient die MITRE Corporation, ein Dienstleister der US-Regierung. Die Erfassung von Sicherheitslücken und Schwachstellen erfolgt weltweit durch sogenannte CNAs (CVE Numbering Authorities). Dafür existiert ein CVE-Partnerprogramm. Es beinhaltet u.a. einen speziellen Boardingprozess, um neue Mitglieder einzubinden. Ein Beispiel für eine CVE wäre die GNU/Linux-basierte Steuerung in einer Maschine A des Herstellers B, die aus unbekannten Gründen per LAN-Schnittstelle den Zugriff auf den undokumentierten TCP-Port 8899 ermöglicht, über den sich das gesamte System jederzeit anhalten lässt. Nachdem diese Sicherheitslücke entdeckt, innerhalb der CVE-Organisationsstrukturen gemeldet und geprüft wurde, bekommt sie eine Registriernummer im Format CVE-yyyy-nnnn. In dieser CVE-ID ist ‚yyyy‘ die Jahreszahl der Veröffentlichung und ’nnnn‘ die fortlaufende Nummerierung aller Veröffentlichungen in dem betreffenden Jahr (zwischen dem Entdecken einer Sicherheitslücke und der CVE-Veröffentlichung liegen manchmal allerdings größere Zeitspannen). Zu jeder neuen Sicherheitslücke wird eine Kurzbeschreibung erstellt und durch Zusatzinformationen ergänzt. Der finale CVE-Datensatz (Record) wird von einem CNA gemäß den organisatorischen Vorgaben zusammengestellt und mit Produkt- und Herstellernamen in der frei zugänglichen CVE-Datenbank gespeichert. Danach ist eine Sicherheitslücke über die CVE-ID eindeutig referenzierbar. Der gesamte CVE-Datenbestand ist im Internet über verschiedene Webseiten abfrag- und durchsuchbar (also z.B. die Kombination Hersteller = GNU und Produkt = Glibc, siehe hierzu auch www.cvedetails.com). Als Suchbegriffe lassen sich neben Hersteller- und Produktnamen beispielsweise auch Versionsnummern nutzen. Zur Integration in spezielle Werkzeuge sind die CVEs auch als maschinenlesbare Datenobjekte verfügbar.
Schwachstellen isolieren
Zunächst einmal ist jede CVE eine theoretische Schwachstelle, die in Datenbeständen jeweils bestimmten Hardware- bzw. Softwarekomponenten zugeordnet wurde. Wie viele CVEs in einer Baugruppe, Maschine oder Anlage jeweils tatsächlich existieren, in welchem Patch-Zustand sich jede einzelne befindet und zu welchen Auswirkungen das im ungünstigen Fall führen kann, lässt sich in der Praxis nicht ohne Weiteres beantworten. Die Klärung einer solchen Fragestellung ist zum gegenwärtigen Zeitpunkt nur durch überwiegend manuelle Analysetätigkeiten bedingt möglich. Für die Zukunft sind hier automatisierte Prozesse zu erwarten, aber auch sogenannte Software Bill of Materials (SBoMs, also Datenobjekte, die als Softwarestückliste zu einer Funktionseinheit mit digitalen Elementen gehören).
Die theoretische CVE-Anzahl einer industriellen Steuerung, die z.B. ein Linux-Betriebssystem plus Real-Time-Erweiterung, eine IEC61131-Laufzeitumgebung sowie jeweils einen OPC UA- und Profinet-Stack enthält, dürfte vermutlich deutlich oberhalb von 5.000 liegen. Für eine mittelgroße Anlage mit mehreren Steuerungen im fortgeschrittenen Lebensalter kommt man dann schon auf eine fünfstellige Anzahl theoretisch ungepatchter Sicherheitsschwachstellen. Um beispielsweise die bereits angesprochene NIS-2-Richtlinie zu erfüllen, sollte man sich im Rahmen eines systematischen Schwachstellenmanagements mit allen CVEs auseinandersetzen, um Prioritäten zu bestimmen, eigene Handlungsanweisungen zu erarbeiten und anschließend die möglichen Auswirkungen reduzieren.
Auf jeden Fall muss zwischen OT- und IT-Netzwerken eine klare Segmentierung existieren. Am Verbindungspunkt beider Segmente ist eine entsprechend konfigurierte Firewall erforderlich, die praktisch alle segmentübergreifenden Zugriffe unterbindet . Nur die tatsächlich erforderlichen und funktional eindeutig identifizierten logischen Verbindungen sind zugelassen (z.B. der Dialog zwischen den OPC UA-Servern im OT-Netzwerk und einem Client in der IT).
Direkt oder indirekt patchen
Nachdem alle OT-CVEs in einem eigenen Netzwerksegment isoliert sind, sollte man sich auf die in der Regel überschaubare Anzahl an Schwachstellen in den OT-Komponenten konzentrieren, die durch die Firewall hindurch mit IT-Anwendungen kommunizieren. Jede einzelne CVE dieser kritischen Restmenge ist hinsichtlich ihres Sicherheitsrisikos innerhalb der jeweiligen Anwendung zu bewerten. Dabei wird üblicherweise auch die Wahrscheinlichkeit einer missbräuchlichen Nutzung bestimmt und eine Prioritätsliste für Abstellmaßnahmen erstellt. Zu allen hochpriorisierten Schwachstellen wird dann in Zusammenarbeit mit den Herstellern bzw. Anbietern der betroffenen Komponenten nach einem Patch gesucht (beispielsweise eine neue Version eines OPC UA-Servers). Existiert ein solcher Patch, wird er nach einer Evaluierung innerhalb der Anlage installiert.
Kann der Komponentenhersteller hinsichtlich der direkten Schwachstellenbeseitigung nicht weiterhelfen oder hat sich bei der Evaluierung herausgestellt, dass sich durch den Patch das Baugruppenverhalten funktional verändern würde, ist ein virtueller Patch eine Lösung. Eine solche Patch-Methode korrigiert nicht die eigentlich fehlerhafte Anwendung bzw. Firmware der betroffenen OT-Baugruppe (der alte Baugruppenzustand und die jeweilige CVE bleiben also unverändert erhalten). Der virtuelle Patch sorgt stattdessen über eine externe Zwischen- bzw. Isolationsschicht indirekt dafür, dass sich die Sicherheitslücke nicht durch Zugriffe aus dem IT-Netzwerk heraus missbräuchlich ausnutzen lässt, beispielsweise für Cyberattacken. Mithilfe der virtuellen Patch-Technik kann in der Praxis auch ein alter Windows-PC, für den es schon lange keine Updates mehr gibt, der aber im Moment funktional unersetzbar ist, mit überschaubarem Risiko weiterbenutzt werden.
