KANBrief 3/23
Komponenten der funktionalen Sicherheit schützen das Leben und die Gesundheit von Personen, etwa indem sie den Zugang zu gefährlichen Bereichen von Maschinen und Anlagen verhindern. Wichtig ist, dass auch Manipulationen von außen die Sicherheit nicht beeinträchtigen. Dazu muss der Stand der Technik konsequent umgesetzt werden und Hersteller und Betreiber müssen im Falle von Sicherheitslücken angemessen darauf reagieren.
Damit Sicherheitsfunktionen von Steuerungen zuverlässig funktionieren können, muss auch die Steuerung selbst sicher sein – geschützt also vor Ausfall und Manipulation. Die steigende Frequenz neuer Katastrophenmeldungen im Bereich Industrial Security wirkt erschreckend. Doch es gibt Grund zur Hoffnung, denn fast alle Sicherheitslücken können nach dem Stand der Technik eigentlich sehr leicht vermieden werden, wie folgendes typische Beispiel zeigt.
Bereits 1883 stellte Auguste Kerckhoffs sechs Grundvoraussetzungen für eine vertrauliche Kommunikation auf1. Die zweite lautete „Das System darf keine Geheimhaltung erfordern und muss ohne Nachteil in die Hände des Feindes fallen können“. Diese Schrift kannte Guglielmo Marconi offensichtlich nicht. Seine Telegraphie zur vertraulichen Kommunikation erforderte, dass niemand in Besitz eines der Geräte kommt oder eines nachbaut und auf die gleiche Frequenz einstellt. Nevil Maskelyne machte 1903 auf das Problem aufmerksam, indem er während Marconis Vorführung unflätige Nachrichten dazwischen morste, und gilt dadurch als einer der ersten Hacker (englisch). Obschon die sichere Verschlüsselung mit kryptographischen Methoden lange bekannt ist, findet sich der gleiche Designfehler auch heute noch etwa in Funksteuerungen für Ampelsysteme2 oder Industriekranen3.
Der Navigator für Normen mit Bezug zu Security von der Universität Bremen hat aktuell rund 800 Normen und über 2000 Treffer zu Rechtsvorschriften in einer Datenbank erfasst. Problematisch ist, dass die Dokumente unterschiedliche Begriffe verwenden und zum Teil nicht eindeutig definieren. Während manche Dokumente umfassend von Security oder Informationssicherheit handeln, erfinden andere neue Begriffe als Kofferwort aus „Cyber“ und einem weiteren Wort. Diese neu geschaffenen Wörter müssen im Dokument genau definiert werden, da sie für sich keine eindeutige Bedeutung haben. Mal ist „Cybersicherheit“ eine Tätigkeit, mal ist es eine Maßnahme gegen Angriffe aus dem Internet, ein anderes Mal ein Zustand, bei dem das Produkt vor Angriffen über Funk geschützt ist.
Besser als neue Wörter zu erzeugen ist es, mit den eindeutigen Begriffen Informationssicherheit oder Security zu arbeiten. Muss der Bedeutungsumfang etwa auf Angriffe über Funk reduziert werden, sollte die Einschränkung klar benannt werden. Einen anderen sehr eleganten Weg hat die EU-Maschinenverordnung gewählt, indem sie in Anhang III 1.1.9 einen „Schutz gegen Korrumpierung“ fordert und in diesem Punkt auch deutlicher ist als die bisherige EU-Maschinenrichtlinie. Dabei fokussiert sie sich auf das Schutzziel, dass etwa bei Fernzugriff keine gefährlichen Situationen entstehen dürfen und lässt offen, wodurch die Korrumpierung im Detail hervorgerufen wird.
Eine schnelle und effektive Kommunikation ist der Schlüssel zur angemessenen Reaktion auf Sicherheitslücken. Wie schlecht es jedoch um die Kommunikation bestellt ist, zeigte sich im Dezember 2021, als eine Sicherheitslücke in der Softwarebibliothek Log4J Schlagzeilen machte. Diese Softwarebibliothek ist nicht nur Bestandteil vieler Serverdienste, sondern auch vieler Industriekomponenten. Während einerseits Vorwürfe laut wurden, dass die Bibliothek falsch eingesetzt wurde und die Sicherheitsprobleme durch Lesen der Dokumentation verhindert worden wären, rätselten gleichzeitig viele Hersteller, ob sie von Sicherheitslücken betroffen sind. Nicht selten brauchten Hersteller viele Monate, bis sie wussten, ob ihre Produkte betroffen sind.
Zusammengefasst fehlte es an
Der Mangel an einheitlichen Informationen und Schnittstellen wird durch einen Satz offener Spezifikationen behoben, die von verschiedenen Zusammenschlüssen von Unternehmen, Behörden und Organisationen erarbeitet wurden und die jedes Unternehmen ab sofort umsetzen kann (siehe Tabelle). Ein Notfallkontakt nach der IETF-Spezifikation RFC 9116 wird in einer einfachen security.txt-Datei auf der Webseite hinterlegt. Darin kann ein Hersteller auch auf seine Liste der Handlungsempfehlungen (CSAF)4 verweisen. Jedes Hardware- und Softwareprodukt bekommt eine weltweit eindeutige Identifikation (CPE), damit die Internationalen Warnmeldungen (CVE) automatisch den exakten Produkten und Versionen zugeordnet werden können. Die Kritikalität der Sicherheitslücke wird durch einen weltweit einheitlichen Index (CVSS) so gut es eben geht eingestuft. Anhand der offenen Spezifikation SPDX nach ISO/IEC 5962:2021 kann zu jedem Projekt maschinenlesbar dokumentiert werden, welche Bibliotheken verwendet wurden. Auf Betreiberseite kann dann ein Programm zu allen Produkten regelmäßig abfragen, ob Sicherheitswarnungen vorliegen und die Handlungsempfehlungen anzeigen.
Einige große Unternehmen setzen bereits auf diese Spezifikationen. Entscheidend ist nun, dass auch alle anderen Unternehmen schnell folgen, damit die Information zu Sicherheitsproblemen schnell und kostensparend erfolgt.
Als ersten Schritt sollten Unternehmen jetzt zumindest die Erreichbarkeit bei Sicherheitsvorfällen sicherstellen und einen Notfallkontakt bekannt machen. Mit der Anleitung auf cert.dguv.de kann das in wenigen Minuten umgesetzt werden.
Jonas Stein
Leiter des Prüflabors für Industrial Security und Leiter des Arbeitskreises Security der DGUV
Jonas.Stein@dguv.de
1 Auguste Kerckhoffs 1883: „La cryptographie militaire“ (Französisch)
2 ARD-Reportage 2021, „Hacker schalten Ampeln in Hannover auf Grün“ 2021
3 Andersen et al, 2019 “A Security Analysis of Radio Remote Controllers for Industrial Applications” (Englisch, pdf)
4 csaf-v2.0, Common Security Advisory Framework Version 2.0. Edited by Langley Rock, Stefan Hagen and Thomas Schmidt. 18 November 2022. OASIS Standard.