Was fehlt der Maschinensicherheit ohne Security?

Eine Annäherung

Autoren: Johannes Frick, Heiko Rudolph, Sarah Fluchs.
Dieser Beitrag ist am 11. Februar 2021 auf ibf-solutions.com erschienen.

Photo by Rock’n Roll Monkey on Unsplash

If it’s not secure, it’s not safe”, also etwa “ohne Security keine Produktsicherheit (Safety)” — auf diesen kurzen Satz wird das Thema Security für die Maschinensicherheit oder die Sicherheit von elektrischen Geräten gern eingedampft. Für Hersteller von technischen Produkten bedeutet dies, dass neben den explizit in EU-Richtlinien (z.B. Maschinenrichtlinie, Niederspannungsrichtlinie, etc.) genannten Safety-Anforderungen auch Aspekte der Security relevant sind, um den Anforderungen an sichere Produkte gerecht zu werden.

Doch was ist nun der genaue Unterschied zwischen „Safety“ und „Security“? Während die Safety Menschen (und Umwelt) vor Maschinen schützt, schützt die Security z.B. Maschinen oder elektrische Geräte (und damit auch deren Umfeld) vor Menschen.

Beispiel Flughafen: In der Safety-Einweisung erklären die Flugbegleiter, wie wir uns schützen können, wenn das Flugzeug abstürzt. Der Security-Check sorgt dafür, dass wir Menschen nichts mit ins Flugzeug bringen können, was einen Flugzeugabsturz herbeiführen könnte.

Dieser Beitrag liefert Herstellern einen Überblick, welche Aspekte der Security unbedingt in den Produktentstehungsprozessen von Maschinen, Anlagen und elektrischen Geräten beachtet werden sollten.

1. Vorsicht vor Fehlannahmen zu Security

Obgleich uns das Thema Security in fiktiven Darstellungen oder auch in Form von Nachrichten nahezu täglich begegnet, haben viele Menschen noch immer eine sehr diffuse Vorstellung davon. Insbesondere für Betreiber bzw. Verwender von technischen Produkten existieren einige Annahmen, die wir genauer betrachten sollten. Diese sind z.B.:

• Warum sollte jemand gerade uns angreifen?
• Böswillige Handlungen — Gegen die NSA sind wir eh machtlos!

Ausgehend von diesen Fehlannahmen, die Betreiber oder Verwender, also die Kunden von Herstellenden Unternehmen, häufig haben, wollen wir dann in den nachfolgenden Kapiteln die Implikationen für Hersteller besprechen.

1.1 Fehlannahme 1: Warum sollte gerade uns jemand angreifen?

“Wir sind doch kein Ziel!” und “Wer sollte uns denn angreifen?” sind zwar verständliche, aber dennoch gefährliche Abwägungen, da die große Mehrzahl der Angriffe gar nicht gezielt ablaufen, sondern zufällig erfolgen.
Es gibt zwar Beispiele für spektakuläre, gezielten Hackerangriffe (der wohl bekannteste ist Stuxnet, mit dem das iranische Urananreicherungsprogramm sabotiert wurde), aber viel wahrscheinlicher ist, dass Sie Opfer eines ungezielten Angriffs werden.

Alle Geräte, die aus dem Internet erreichbar sind, sind ständigen Angriffen ausgesetzt. Diese Angriffe erfolgen in Form von automatisierten Scans und automatisierten Angriffsversuchen. Z.B. wird automatisch überprüft, ob die Zugangspasswörter den Standardpasswörtern entsprechen, oder es wird geprüft, ob bestimmte Kanäle ungesichert sind. Ein weiteres Szenario: Angreifer versuchen über bekannte Sicherheitslücken von eingesetzter (veralteter) Software Zugang zu bekommen.

Was hat ein Angreifer von zufällig ausgewählten Opfern?
Es existieren unterschiedlichste Anreize für kriminelle Gruppierungen, solche automatisierten Angriffe durchzuführen. Dies reicht von eher harmlosen Dingen (wie z.B. der Nutzung von Rechner-Ressourcen (z.B. CPU) zur Durchführung rechenintensiver Operationen, etwa der Erzeugung von Krypto-Währungen) bis hin zur Verschlüsselung ganzer Server. Das Ziel der Verschlüsselung von Server ist es, Lösegeld für die Entschlüsselung dieser Systeme zu erpressen. Dies sind sogenannte Ransomware-Angriffe. Bekanntes Opfer eines solchen Angriffs wurde z.B. auch der Industrieautomatisierer Pilz.

Bedrohung durch „Kollateralschaden“
Die „wer sollte uns schon angreifen“-Fehlannahme ist auch deshalb nicht zielführend, weil sie Kollateralschäden durch sich selbst verbreitende Schadprogramme außer Acht lässt. Hier kann es z.B. vorkommen, dass ein Wurm ursprünglich gezielt eingesetzt wurde — aber nicht gegen Sie. Möglicherweise merkt Ihr Angreifer noch nicht einmal, dass Sie mit unter die Räder gekommen sind. Im Fall von Stuxnet gibt es Fragmente sich selbst verbreitender Software, die sich mittlerweile auf der ganzen Welt finden.

1.2 Fehlannahme 2: Böswillige Handlungen — Gegen die NSA ist man eh machtlos.

Fehlannahme 2 ist im Ansatz gar keine Fehlannahme. Die Mission, sich gegen jeden gezielten Angriff zu schützen, ist nahezu unmöglich. Eine falsche Schlussfolgerung aus der Fehlannahme wäre aber, aus diesem Grund das Thema Security gar nicht zu beachten, zumal das sehr viel wahrscheinlichere Bedrohungsszenario aus denen im vorherigen Abschnitt beschriebenen automatisierten Angriffen bestehen.

Eine häufige (verwandte) Fehlannahme ist, dass Security nur den Schutz vor böswilligen, kriminellen Handlungen umfasst. Diese böswilligen Handlungen sind zwar ein wichtiger Bestandteil der Security, aber nicht der einzige: So beinhaltet Security auch den Schutz der Maschinen, Anlagen oder Geräten vor menschlichen Fehlern ohne böswillige Intention. In der Praxis ist die wichtigste Ergänzung von Security gegenüber Safety häufig, dass sie menschliche Kreativität berücksichtigt — egal, ob diese böswillig oder nur für “kreative Workarounds” genutzt wird. Bezogen auf Maschinensteuerungen wäre das z.B., dass eine Maschine nur in Kombination mit einer Firewall mit dem Internet verbunden werden darf. Eine solche Konfiguration kann in bestimmten Situationen zu Einschränkungen führen. Ist es für Bediener oder Instandhaltungspersonal einfach möglich (z.B. durch Umstecken von Netzwerkkabeln) die Konfiguration (ohne böse Absicht) zu ändern, kann dies zu einer Reduzierung des Security-Niveaus führen.

Wer verübt „böswillige Handlungen“?
Bei “böswilligen Handlungen” denkt man gemeinhin an Fremde — kriminell sind immer die anderen. Und diese Fremden müssen sich ja erst einmal die Informationen über unsere Maschinen beschaffen, um überhaupt genug Wissen für eine böswillige Manipulation zu haben, richtig? Nicht zu vernachlässigen ist jedoch der “Insider Threat”: Frustrierte, bestochene oder auch nur durch “Social Engineering” getäuschte eigene Mitarbeiter sind ein häufiger erster Schritt zum Security-Angriff.

2. Früchte höher hängen — Schritte zur Security für Maschinen und elektrische Geräte

Aber ist es nun machbar, sich gegen solche ungezielten Angriffe zu schützen? Grundsätzlich hilft es ohnehin, das Bild vom James-Bond-Hacker aus dem Kopf zu bekommen, wenn Sie Ihre Security planen. Sie müssen sich nicht gleich gegen Geheimdienste und staatliche Hacker verteidigen. Wenn Sie nicht mehr Opfer jedes Angreifers werden, der auf der Suche nach “low hanging fruits” ist haben Sie schon viel gewonnen. Durch das Einbauen von Hürden fallen Sie für einen Großteil dieser Angriffe bereits durchs Raster.

Der wichtigste Schritt in Richtung Anlagensicherheit ist es, sich auf Security als eine neue Sichtweise auf die bekannte Maschine und bekannte Schadensszenarien einzulassen.
Sie haben Security bislang vielleicht zwar noch nicht mitbetrachtet, aber Sie kennen Ihre Maschine, wissen, wie Sie funktioniert, und was nicht geschehen darf — und damit haben Sie die wichtigsten Informationen schon beisammen.

Security ist mehr eine Denkweise als eine Checkliste zum Abarbeiten. Im Gegensatz zu Gefährdungsszenarien, die auf technischem Versagen beruhen, können sich Security-Gefährdungen recht kurzfristig ändern, wenn sich Software ändert, oder wenn eine neue Schwachstelle an der bestehenden Software bekannt wird.
Daher ist für die Security nicht nur zum Zeitpunkt des Inverkehrbringens wichtig, sondern die Security-Denkweise, die schon bei der Entwicklung beginnt, hört auch im Betrieb nicht auf.

Wo fängt man da an? Drei Empfehlungen für die drei Phasen Engineering, Inbetriebnahme und Betrieb:

3. Engineering: Security-Perspektive auf die Risikobeurteilung

Bei einer Risikobeurteilung aus Security-Sicht können Sie grundlegend das bekannte Verfahren aus Produktsicherheitsrichtlinien wie z.B. der Maschinenrichtlinie verwenden — mit einigen kleinen Erweiterungen:

3.1 Festlegung der Grenzen: Kommunikation

Wenn Sie im ersten Schritt der Risikobeurteilung die Grenzen der Maschine oder eines elektrischen Betriebsmittels festlegen, beantworten Sie Fragen wie “Wo kommt das Produkt zum Einsatz? Wer bedient die Maschine bzw. das Betriebsmittel? Was ist die bestimmungsgemäße Verwendung inkl. vernünftigerweise vorhersehbare Fehlanwendung?”

Auch für Security ist der erste wichtige Schritt, zu verstehen, wer Ihre Maschine benutzt und welche wichtigen Funktionen sie erfüllt. Darüber hinaus ist für die Beurteilung von Security immer die Kommunikation eines Systems wichtig, sei es mit anderen Systemen oder mit Menschen. Ein System, das keine Kommunikationsschnittstellen bietet, bietet weniger Security-Angriffsfläche (und — je nach Anwendung — leider auch wenig Nutzen).

Gemäß Maschinenrichtlinie definieren Sie unter “Verwendungsgrenzen” bereits, wer Ihre Maschine wie bedient, und unter “Räumliche Grenzen” fallen bereits Mensch-Maschine-Schnittstellen. Darauf können Sie aufbauen für die Security-Perspektive:
Erweitern Sie die Grenzen der Maschine um die Kommunikation, die für die Erfüllung ihrer wichtigsten Funktionen notwendig ist — egal ob zwischen Mensch und Maschine oder zwischen Maschinenkomponenten.

Eine Funktion, aus Security-Sicht modelliert, könnte zum Beispiel so aussehen:

• Ein Bediener setzt einen Parameter an der Maschine. Dafür verwendet er das LCD-Bedienpanel, das z.B. ein proprietäres Siemens-Kommunikationsprotokoll nutzt, um den Wert an die SPS der Maschine weiterzugeben.

Alternativ:

• Der Bediener kann aus seinem Büro über eine Weboberfläche einen Parameter setzen, der über LAN an das Bedienpanel oder direkt an die SPS übertragen wird?

Da sich die beiden oben genannten Beispiele hinsichtlich der Kommunikationswege stark unterscheiden, bieten diese naturgemäß auch völlig unterschiedliche Angriffsszenarien, welche im Zuge der Security-Risikoanalyse genauer untersucht und auf unterschiedliche Art und Weise abgesichert werden müssen.

3.2 Identifizierung der Gefährdungen

Auch Gefährdungen können Sie nun einmal zusätzlich aus der Security-Perspektive betrachten.
“If it’s not secure, it’s not safe” bekommt jetzt eine praktische Bedeutung. Die Liste von Safety-Gefährdungen aus ISO 12100:2010 einfach um Security-Gefährdungen zu erweitern, trägt den unterschiedlichen Eigenschaften der beiden Gefährdungsarten allerdings nicht genügend Rechnung.

Die Security-Risikoanalyse baut aber trotzdem auf der Safety-Risikoanalyse auf: Anhand Ihrer bereits bestehenden Gefährdungsszenarien, die Sie mit Safety-Maßnahmen verhindern wollen, überlegen Sie nun rückwärts: Kann auch eine Security-Gefährdung zu diesem Szenario führen?

Die Security-Aspekte sind also weitere Ursprünge von Gefährdungen.

Tabelle 1: Beispiele für Ursprünge und Gefährdungen

Die technische Regel ISO/TR 22100–4:2018 schlägt diesbezüglich vor, dass auf Basis einer Safety-Risikobeurteilung Safety-Maßnahmen ermittelt werden, welche dann auf deren Security-Schwachstellen untersucht werden. Dies ist zwar ein wichtiger Teilaspekt einer Security-Risikobeurteilung, für sich allein aber aus Sicht der Autoren nicht ausreichen, dazu unten mehr.

Abbildung 1: Zusammenhänge zwischen Security- und Safety-Risikobeurteilungen entsprechend ISO/TR 22100–4

Was fehlt der Maschinensicherheit ohne die Betrachtung von Security?
Im Wesentlichen können Sie das Problem in drei Fragen zerlegen.

Die ersten beiden Fragen bauen direkt auf der bereits erledigten Maschinensicherheits-Risikobetrachtung auf (vgl. auch Marszal/McGlone):

1. Zuerst nehmen Sie die identifizierten Gefährdungen in den Fokus und fragen: Können diese schon bekannten Gefährdungen auch durch eine Security-Gefährdungsszenario, also durch (böswillige) Manipulation meiner Maschinen und ihrer Kommunikationsschnittstellen, herbeigeführt werden?
2. Dann wenden Sie sich den definierten Schutzmaßnahmen zu und fragen: Kann eine Safety-Maßnahme durch eine Security-Gefährdung verändert werden, sodass sie im Anforderungsfall nicht mehr wirkt wie vorgesehen (vgl. Abbildung 1, ISO/TR 22100–4)?
3. Die dritte Frage ist weitreichender, weil sie eine der Grundannahmen der Safety-Risikoanalyse hinterfragt: Sorgt die Einbeziehung menschlicher Kreativität für neue, bislang gar nicht betrachtete, Gefährdungsszenarien?
   Zum Beispiel werden in Risikoanalysen, die technisches Versagen in den Vordergrund stellen, sogenannte “Common Cause Failures” oder “Common Mode Failures”, also Fehlerzustände durch dieselbe Ursache oder mit derselben Folge in mehreren Komponenten auf einmal, oft nicht betrachtet. Für die Security sind solche Fälle aber höchst relevant: Wenn ein Angreifer herausfindet, wie er sich Zugang zu einer Komponente beschaffen kann, ist es sehr wahrscheinlich, dass er dieselbe Methode auch für alle anderen Komponenten ausprobiert.
   Ein gutes Beispiel ist der Befall mit der Ransomware „NotPetya“ beim Logistiker Maersk: Alle Active-Directory-Server waren untereinander synchronisiert, sodass im Falle eines Ausfalls immer direkt ein Backup zur Verfügung gestanden hätte. Nur eben nicht im Falle des gleichzeitigen Ausfalls ALLER Server — und genau das verursachte der Ransomware-Schadcode.

Für die Beantwortung aller drei Fragen helfen die Funktionsmodelle, die Sie bei der Festlegung der Grenzen der Maschine erstellt haben.
Nehmen Sie die Funktionsmodelle und überlegen Sie für jeden Schritt in Ihren modellierten Kommunikationssequenzen:

• Was kann schiefgehen?
• Wie kann jemand die beschriebenen Kommunikationsmöglichkeiten ausnutzen, um ein Gefährdungsszenario herbeizufügen?
• Was kann jemand (auch, aber nicht nur mit böswilliger Absicht) schlimmstenfalls tun, um diese Kommunikationsmöglichkeit auszunutzen?

4. Inbetriebnahme: Dokumentation nicht nur für Sie selbst

Ihre Kunden stehen vor dem Problem Security wahrscheinlich schon eine Weile länger als Sie — denn: Am Ende liegt das Security-Risiko meist in der Verantwortung der Betreiber.

Vielleicht haben Sie Kunden, die unter die kritischen Infrastrukturen fallen (zum Beispiel aus den Branchen Energie, Wasser, Verkehr und Logistik oder Ernährung), unter die Störfallverordnung (zum Beispiel aus der Chemiebranche) oder TISAX erfüllen müssen (Automobilbranche) — all diese Gruppen haben bereits heute gesetzliche Verpflichtungen zum Nachweis von Security.

Das Problem ist, dass eine “sichere” Maschine und Anlage allein noch keine Security garantiert.

Der Einbau in die existierende Betriebsumgebung — aus Security-Sicht besonders relevant: in die existierenden Kommunikationsnetzwerke — sowie die tatsächlichen Konfigurationen im Betrieb spielen eine wichtige Rolle. Das ist ein Problem für den Betreiber, da er das Risiko für die Sicherheit Ihrer Maschine nur dann tragen kann, wenn er weiß, welche Security-Eigenschaften sie hat — und wenn er sicherstellen kann, dass er die Maschine auch so in Betrieb genommen und an seine existierende Kommunikationsinfrastruktur angebunden hat, dass diese Security-Eigenschaften auch funktionieren.

Es ist aber auch ein Problem für Sie als Hersteller, wenn Sie Ihren Kunden sichere Maschinen verkaufen wollen: Sie müssen sowohl die Security-Eigenschaften eines Produkts transparent machen als auch den Betreibern die nötigen Informationen und Instruktionen liefern, damit diese sicher betreiben können.

Die gute Nachricht:
Betreiber müssen sich dieselben Fragen stellen, die Sie sich während der Konstruktion auch stellen mussten: Wer bedient die Maschine, mit welchen Menschen oder anderen Maschinen kommuniziert sie zu welchem Zweck und auf welchem Wege? Die Funktionsmodelle, die Sie während der Konstruktion erstellt haben, helfen daher auch dem Betreiber. Ein Grund mehr, sie gut zu pflegen — denn die Modelle bleiben keine rein internen Dokumente. Sie sind hervorragend geeignet, um Default-Konfigurationen und Security-Eigenschaften transparent zu machen.

5. Betrieb: Kommunikation und Schwachstellenmanagement

Dieser Satz ist in der Security eine Binsenweisheit: Es ist nicht die Frage, ob Sie Opfer eines Security-Angriffs werden, sondern nur wann.
Deswegen ist es bei allen proaktiven Schutzmaßnahmen wichtig, auch reaktiv auf den Fall vorbereitet zu sein, wenn tatsächlich ein Angriff passiert, oder eine Schwachstelle im Produkt bekannt wird.

Selbst wenn Sie Security vorbildlich in Ihrem Entwicklungsprozess berücksichtigen, können in einer zum Zeitpunkt der Auslieferung als sicher (secure) angenommenen Maschinen später Sicherheitslücken bekannt werden. Dafür gibt es drei wesentliche Gründe:

1. Security-Angriffe leben von der Kreativität von Menschen, die Schutzmaßnahmen umgehen.
2. Schutzmaßnahmen sind volatil; sie können — werden! — sich auch nach Auslieferung der Maschine verändern, weil sie in der Regel von Software und Netzwerkkommunikation abhängen.
3. Software und Kommunikationsprotokolle basieren auf einer großen Anzahl von Modulen, deren Entwicklung Sie nicht selbst in der Hand haben. Sie verwenden wahrscheinlich das IP-Protokoll und darunter noch eine Reihe hardwarenäherer Kommunikationsprotokolle, die Sie nicht selbst geschrieben haben — auch diese Protokolle können Schwachstellen enthalten. Ein spektakulärer Fall in diesem Jahr waren die unter dem Namen “Ripple 20” veröffentlichten Schwachstellen — tief im TCP/IP-Protokollstack vergraben. Bis heute ist nicht umfassend geklärt, welche Produkte von diesen Schwachstellen betroffen sind.

Diese drei Punkte können Sie nicht ändern und sie sind nicht Ihre Schuld. Bekanntwerden von Schwachstellen in Ihren Produkten ist daher keine Schande. Großes Vertrauen in Security ernten daher nicht solche Hersteller, die nie Schwachstellen in ihren Produkten bekannt machen, sondern solche, die mit den bekannt gewordenen Schwachstellen professionell umgehen.

Professionell bedeutet, dass Sie Ihre Kunden frühzeitig über die Schwachstelle und / oder den Angriff informieren, dass Sie aussagefähig sind, in welchen Fällen (bei welchen Produkten / Versionen) Ihr Kunde betroffen ist und dass Sie möglichst unkomplizierte Hilfestellung dabei geben können, wie das Problem zu beheben ist — idealerweise durch ein Security-Patch, dass die Security-Lücke nachhaltig beseitigt.

Apropos Patch: Sie helfen Ihren Kunden enorm, wenn Sie Security-Patches und wichtige Informationen über diese Patches in einem Format bereitstellen, das Kunden automatisiert auswerten können.
Es gibt mehrere Initiativen zu solchen Formaten, etwa das XML-Schema des ISA/IEC TR-62443–2–3 oder das JSON-basierte Format CSAF (Common Security Advisory Framework)— aber wichtig ist in erster Linie, dass Sie Informationen und Patches überhaupt zeitnah, maschinenlesbar und security-überprüfbar bzw. über eine sichere Verbindung bereitstellen.

6. Haben Hersteller die Pflicht, Security zu berücksichtigen?

Security lässt sich mit der Systematik der EU-Produktsicherheitsrichtlinien wie der Maschinenrichtlinie oder der Niederspannungsrichtlinie durchaus berücksichtigen, wenn man regelmäßig die Security-Perspektive einnimmt. Hinsichtlich der Frage, ob die Maschinenrichtlinie bzw. andere EU-Richtlinien selbst die Berücksichtigung von Security fordern, gibt es unterschiedliche Meinungen, die sich zum Teil auch in Normen wiederfinden.

Keine explizite Forderung nach Security, aber implizit?

Klar ist, dass die aktuell weder die Maschinenrichtlinie noch die Niederspannungsrichtlinie Security explizit fordern. Allerdings ist es gerade ein Merkmal dieser „New Approach“-Richtlinien, dass grundlegende Anforderungen anstelle von technischen Details definiert werden. Man könnte also argumentieren, dass Security implizit gefordert ist, um die grundlegenden Anforderungen überhaupt erfüllen zu können.

Eine solche grundlegende Anforderung ist beispielsweise die Anforderung an die “Sicherheit und Zuverlässigkeit von Steuerungen” der Maschinenrichtlinie:

1.2.1. Sicherheit und Zuverlässigkeit von Steuerungen
Steuerungen sind so zu konzipieren und zu bauen, dass es nicht zu Gefährdungssituationen kommt. Insbesondere müssen sie so ausgelegt und beschaffen sein, dass

- sie den zu erwartenden Betriebsbeanspruchungen und Fremdeinflüssen standhalten;

- ein Defekt der Hardware oder der Software der Steuerung nicht zu Gefährdungssituationen führt;

- Fehler in der Logik des Steuerkreises nicht zu Gefährdungssituationen führen;

- vernünftigerweise vorhersehbare Bedienungsfehler nicht zu Gefährdungssituationen führen.

Dieses Zitat beinhaltet durchaus Interpretationsspielraum: Sind “zu erwartende Betriebsbeanspruchungen und Fremdeinflüsse” auch böswillige Angriffe auf die Kommunikationsschnittstellen? Fallen darunter auch Angriffe auf bedienende Menschen durch “Social Engineering”, also das Überzeugen von Bedienern, potenziell schädliche Aktionen auszulösen durch Vorgeben einer falschen Identität und / oder besonders dringlichen Situation?

In diesem Zusammenhang müssen zwei grundlegende Begriffe der Safety-Risikobeurteilung ISO 12100:2010 bzw. der Maschinenrichtlinie beleuchtet werden:

• Bestimmungsgemäße Verwendung
• Vorhersehbare Fehlanwendung

Um hier nicht zu sehr in die Grundlagen der Safety-Risikobeurteilung abzutauchen nur ganz knapp zusammengefasst: Bei der Risikobeurteilung sind Konstrukteure und andere beteiligte Personen gefordert, nicht nur die Verwendung ihrer Produkte entsprechend der bestimmungsgemäßen Verwendung zu betrachten, sondern eben auch vernünftigerweise vorhersehbare Fehlanwendungen zu berücksichtigen, z.B. reflexartiges Verhalten. Die Frage, wie weit die (zu beachtende) vernünftigerweise vorhersehbare Fehlanwendung geht, und wo Missbrauch oder Vorsatz beginnt, ist einerseits situationsabhängig (z.B. ob die Anwender nur Fachkräfte sind, oder auch Laien oder sogar Kinder) und andersseits meistens eine anspruchsvolle, da wenig hart abgrenzbare, Aufgabe.

Die bereits zitierte technische Regel ISO/TR 22100–4:2018 argumentiert nun, dass Security keine Pflicht von Herstellern ist, da ein Angriff eben keine vernünftigerweise vorhersehbare Fehlanwendung darstellt:

Every kind of intentional violation (sabotage/spying) of a machine is de facto a criminal act which is outside the scope of current safety legislation.9

Der Standard relativiert die Aussage insofern, als dass Maschinenhersteller dennoch IT-Security-Aspekte behandeln sollten:

However, manufacturers providing machinery which can have vulnerabilities to IT-security attacks and/or threats should take this aspect into account in particular when IT-security attacks and/or threats can have an impact to safety of machinery.

Überdies ist fraglich, ob die Aussage hinsichtlich des nicht einschlägigen Anwendungsbereiches («outside the scope») in alle Ewigkeit Bestand haben wird.

Einerseits könnte man argumentieren, dass es sich bei Security-Aspekten gar nicht um eine vorhersehbare Fehlanwendung handelt, sondern genau um die bestimmungsgemäße Verwendung, nämlich die Nutzung eines Produkts (Maschine, el. Geräte) in Verbindung mit einer Kommunikationsschnittstelle ins Internet. Und im Internet herrschen eben gewisse Bedingungen, denen man Rechnung tragen muss. Analog dazu muss man bei der Konstruktion von Produkten für die Verwendung im Freien auch den Anforderungen hinsichtlich Feuchtigkeit durch entsprechende IP-Schutzarten (Ingress Protection, nicht Internet Protocol!) Rechnung tragen.

Andererseits schreitet die Überarbeitung der Maschinenrichtlinie voran. In diversen Veröffentlichungen ist bereits zu lesen, dass mit der Überarbeitung auch das Thema «Security» zukünftig explizit behandelt werden wird.

Es sei noch erwähnt, dass es sich bei der technischen Regel ISO/TR 22100–4:2018 um keine harmonisierte Norm mit Konformitätsvermutung entsprechend einer EU-Richtlinie handelt.

Weitere rechtliche Rahmenbedingungen
Ein weiteres Thema steht in den Startlöchern: Security-Zertifizierung von Produkten.
Der EU Cybersecurity Act fordert EU-weit einheitliche Security-Zertifizierungen — und Betreiber sehen dem freudig entgegen. Den Grund haben Sie in den oben beschriebenen Schritten zur Security-Denkweise bereits kennen gelernt: Betreiber brauchen eine transparente Kommunikation von Security-Eigenschaften, und Zertifikate versprechen, diese zu liefern.

7. Fazit

Viele Dinge im Zusammenhang mit Security sind noch nicht zu 100 % klar. So ist noch nicht klar auf Basis welches Standards entsprechend dem EU Cybersecurity Act zukünftig zertifiziert werden soll. Ebenfalls ist nicht klar, welchen Stellenwert Security bei der mitunter bereits begonnenen Überarbeitung von EU-Produktsicherheitsrichtlinien und weiteren Gesetzen einnehmen wird.

Bezüglich dieser gesetzlichen Pflichten zur Beachtung von Security sei noch folgendes erwähnt: In den Ausführungen oben haben wir uns rein auf öffentlich-rechtliche Anforderungen, d.h. auf solche, in denen der Staat den Marktteilnehmern bestimmte Vorgaben macht, beschränkt. Darüber hinaus steht es Unternehmen natürlich frei vertraglich Security-Aspekte einzufordern. Eine Herausforderung, der sich Zulieferer mehr und mehr stellen werden müssen — auch ohne Verpflichtung zu Security auf Basis von Gesetzen.
Ebenfalls zu berücksichtigen ist die Frage, welche Haftungsrisiken Hersteller aufgrund von Security haben. Zu dieser Frage ist bereits ein eigenständiger Fachbeitrag in Arbeit.

Unabhängig von diesen noch nicht explizit ausformulierten Anforderungen ist es jedoch bereits jetzt ratsam, dem Thema Security proaktiv zu begegnen, denn keiner der möglichen Standards erfindet die Security neu — die grundlegenden Security-Anforderungen sind in allen Standards ähnlich, und sie sind nichts, was man in einer Woche aus dem Boden stampft. Wenn Sie nun in Ruhe beginnen, sich Security-Perspektive in Konstruktion, Inbetriebnahme und Betrieb von Maschinen anzugewöhnen, verliert sowohl das Thema als solches, als auch der Schritt zu einer Security-Zertifizierung — künftig möglicherweise ein Markteintrittskriterium — an Schrecken.