Mobile-Menu

Maschinensicherheit Worauf Maschinenhersteller hinsichtlich Security achten sollten

Von Sarah Fluchs, Johannes Frick, Heiko Rudolph*

Anbieter zum Thema

IEF-Werner GmbH
elobau GmbH & Co. KG
MDESIGN Vertriebs GmbH

Neben den Vorgaben etwa der Maschinenrichtlinie spielen auch Aspekte der Security eine wichtige Rolle, den Anforderungen an sichere Produkte gerecht zu werden. Doch welche Aspekte der Security sollten Hersteller unbedingt beachten?

(Bild: ©vectorfusionart - stock.adobe.com)

Auf den Punkt gebracht: „If it’s not secure, it’s not safe“, also etwa „ohne Security keine Produktsicherheit (Safety)“ – auf diesen Merksatz wird das Thema Security für die Maschinensicherheit oder die Sicherheit von elektrischen Geräten gerne zugespitzt. Was bedeutet dies für Hersteller von technischen Produkten? Sie müssen neben den explizit in EU-Richtlinien (z.B. Maschinenrichtlinie, Niederspannungsrichtlinie, etc.) genannten Safety-Anforderungen auch Aspekte der Security berücksichtigen, um den Anforderungen an sichere Produkte gerecht zu werden.

Für viele Hersteller stellt sich bereits an diesem Punkt die Frage: Was ist der 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.

Bildergalerie

Vorsicht vor Fehlannahmen zu Security

Obgleich uns das Thema Security in fiktiven Darstellungen oder auch in den Nachrichten nahezu täglich begegnet, haben viele Menschen noch immer eine sehr diffuse Vorstellung, was Security ist. Insbesondere Betreiber bzw. Anwender von technischen Produkten unterliegen einigen Fehlannahmen, die genauer unter die Lupe genommen werden sollten, etwa:

  • Warum sollte jemand gerade uns angreifen?
  • Böswillige Handlungen – gegen die NSA sind wir eh machtlos.

Ausgehend von diesen Fehlannahmen, die unter Betreibern oder Anwendern – also die Kunden von Herstellenden Unternehmen – häufig vorherrschen, werden nachfolgend deren Implikationen für Hersteller besprochen.

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 Annahmen, da die große Mehrzahl der Angriffe nicht gezielt erfolgt, sondern zufällig. Es gibt zwar Beispiele für spektakuläre, gezielte Hackerangriffe (der wohl bekannteste ist Stuxnet1, mit dem das iranische Urananreicherungsprogramm sabotiert wurde), aber viel wahrscheinlicher ist, dass Unternehmen Opfer eines ungezielten Angriffs werden.

Alle Geräte, die aus dem Internet erreichbar sind, sind ständigen Angriffen ausgesetzt.

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. So wird z. B. automatisch überprüft, ob die Zugangspasswörter den Standardpasswörtern entsprechen oder ob bestimmte Kanäle ungesichert sind.

Ein weiteres Szenario: Angreifer versuchen über bekannte Sicherheitslücken von eingesetzter (veralteter) Software Zugang zu Systemen zu erhalten.

Wie Angreifer von zufälligen Opfern profitieren

Es bestehen unterschiedlichste Anreize für kriminelle Gruppierungen, solche automatisierten Angriffe durchzuführen. Dies reicht von eher harmlosen Vorteilen wie der Nutzung von Rechner-Ressourcen zur Durchführung rechenintensiver Operationen, etwa zum Erzeugen von Krypto-Währungen, bis hin zur Verschlüsselung ganzer Server. Werden Server verschlüsselt, können die Angreifer Lösegeld für die Entschlüsselung dieser Systeme erpressen. Dabei handelt es sich um sogenannte Ransomware-Angriffe. Opfer eines solchen Angriffs wurde z. B. der Industrieautomatisierer Pilz2.

Die Annahme „Wer sollte uns schon angreifen?“ ist auch deshalb nicht zielführend, weil sie Kollateralschäden durch sich selbst verbreitende Schadprogramme außer Acht lässt. Hier kann es beispielsweise vorkommen, dass ein sogenannter Wurm ursprünglich gezielt eingesetzt wurde – aber nicht gegen Sie. Möglicherweise bemerkt Ihr Angreifer nicht einmal, dass Sie ebenfalls unter die Räder gekommen sind. Im Fall von Stuxnet finden sich mittlerweile Fragmente sich selbst verbreitender Software weltweit.

Fehlannahme 2: Gegen böswillige Handlungen ist man machtlos

Fehlannahme 2 ist im Ansatz 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 der im vorherigen Abschnitt beschriebenen automatisierten Angriffe besteht.

Eine häufige (verwandte) Fehlannahme ist, dass Security nur den Schutz vor böswilligen, kriminellen Handlungen umfasst. Böswillige Handlungen abzuwehren ist zwar ein wichtiger Bestandteil der Security, aber nicht der einzige: Security umfasst auch den Schutz von Maschinen, Anlagen oder Geräten vor menschlichen Fehlern ohne böswillige Intention.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Den menschlichen Faktor berücksichtigen

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 für „kreative Workarounds“ genutzt wird. Bezogen auf Maschinensteuerungen wäre das z. B., dass eine Maschine nur in Kombination mit einer Firewall ans Internet angebunden werden darf. Eine solche Konfiguration kann in bestimmten Situationen zu Einschränkungen führen. Ist es für Bediener oder Instandhaltungspersonal unkompliziert möglich etwa durch Umstecken von Netzwerkkabeln die Konfiguration ohne böse Absicht zu ändern, kann dies das Security-Niveau senken.

Wer verübt „böswillige Handlungen“? Dabei denkt man in der Regel an Fremde – kriminell sind immer die anderen. Und diese Fremden müssen sich ja erst einmal die Informationen über unsere Maschinen beschaffen, um genug Wissen für eine böswillige Manipulation zu haben – richtig? Aber: Der sogenannte Insider Threat spielt hier eine große Rolle. Damit sind frustrierte, bestochene oder durch Social Engineering absichtlich getäuschte eigene Mitarbeiter gemeint, die häufig die erste Stufe für einen Security-Angriff darstellen.

Security für Maschinen und elektrische Geräte

Kann man sich gegen ungezielte Angriffe schützen? Sie müssen sich ja nicht gleich gegen Geheimdienste und staatliche Hacker verteidigen: Wenn Sie nicht mehr Opfer jedes Angreifers werden, der nach „low hanging fruits“ sucht, 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 besteht darin, sich auf Security als eine neue Sichtweise auf die bekannte Maschine und bekannte Schadensszenarien einzulassen.

Der wichtigste Schritt in Richtung Anlagensicherheit besteht darin, sich auf Security als eine neue Sichtweise auf die bekannte Maschine und bekannte Schadensszenarien einzulassen. Vielleicht haben Sie Security bislang vielleicht nicht mit in Erwägung bezogen, doch Sie kennen Ihre Maschine, kennen deren Funktionalität und wissen, was nicht geschehen darf – damit besitzen Sie bereits die wichtigsten Informationen.

Eine neue Denkweise

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 kurzfristig ändern, etwa wenn

  • sich Software ändert,
  • oder eine neue Schwachstelle an bestehender Software bekannt wird.

Daher ist für die Security nicht nur zum Zeitpunkt des Inverkehrbringens wichtig: Die Security-Denkweise beginnt bereits bei der Entwicklung und setzt sich im alltäglichen Betrieb fort.

Wie lässt sich die neue Denkweise im Alltag umsetzen? Drei Empfehlungen für die drei Phasen Engineering, Inbetriebnahme und Betrieb.

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:

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.

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 ohne Kommunikationsschnittstellen 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 für die Security-Perspektive aufbauen: Erweitern Sie die Grenzen der Maschine um die Kommunikation, die zum Erfüllen 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.
  • Alternative: Der Bediener kann an seinem Büro-PC über eine Web-Oberflä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äß völlig unterschiedliche Angriffsszenarien, die im Zug der Security-Risikoanalyse genauer untersucht und auf unterschiedliche Art und Weise abgesichert werden müssen.

2. Identifizierung der Gefährdungen

Auch Gefährdungen können Sie zusätzlich aus der Security-Perspektive betrachten; „If it’s not secure, it’s not safe“ bekommt jetzt praktische Bedeutung. Die Liste von Safety-Gefährdungen aus EN ISO 12100 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 dennoch 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? Security-Aspekte sind also weitere Ursprünge von Gefährdungen.

Beispiele für Ursprünge und Gefährdungen

Ursprung Gefährdung
Safety Materialermüdung Herausgeschleuderte Teile
Security Manipulation der über WLAN übertragenen Daten Herausgeschleuderte Teile

Safety-Risikobeurteilung als Basis für Security

Zusammenhang zwischen Security- und Safety-Risikobeurteilungen entsprechend ISO/TR 22100-4.
Zusammenhang zwischen Security- und Safety-Risikobeurteilungen entsprechend ISO/TR 22100-4.
(Bild: ISO/TR 22100-4)

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

Was fehlt der Maschinensicherheit ohne die Betrachtung von Security? Diese Frage lässt sich wiederum in drei Fragen zerlegen. Die ersten beiden Fragen bauen direkt auf der bereits erledigten Maschinensicherheits-Risikobetrachtung auf4:

  • 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 herbeigeführt werden, also durch (böswillige) Manipulation von Maschinen und ihrer Kommunikationsschnittstellen?
  • 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, 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 nicht betrachtete Gefährdungsszenarien?
    Zum Beispiel werden in Risikoanalysen, die technisches Versagen in den Vordergrund stellen, sogenannte Common Cause Failures oder Common Mode Failures oft nicht betrachtet, also Fehlerzustände aufgrund derselben Ursache oder mit derselben Folge in mehreren Komponenten gleichzeitig. Für die Security sind solche Fälle höchst relevant: Findet ein Angreifer heraus, wie er sich Zugang zu einer Komponente beschaffen kann, ist es sehr wahrscheinlich, dass er dieselbe Methode für alle anderen Komponenten ausprobiert.
    Ein gutes Beispiel hierfür ist der Befall mit der Ransomware NotPetya bei dem Logistikunternehmen 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-Schadcode5.

Beim Beantworten der drei Fragen helfen die Funktionsmodelle, die bei Festlegung der Grenzen der Maschine erstellt wurden. Überlegen Sie nun auf Basis der Funktionsmodelle für jeden Schritt der modellierten Kommunikationssequenzen:

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

Inbetriebnahme: Dokumentation nicht nur für Sie alleine

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

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

Das Problem: Eine „sichere“ Maschine oder Anlage allein garantiert noch keine Security.

Der Einbau in die bestehende 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 Hersteller, wenn sie Kunden sichere Maschinen verkaufen wollen: Die Hersteller müssen sowohl die Security-Eigenschaften eines Produkts transparent machen als auch den Betreibern die nötigen Informationen und Instruktionen bereitstellen, damit diese die Maschinen sicher betreiben können.

Die gute Nachricht: Betreiber müssen sich dieselben Fragen stellen, die sich Hersteller während der Konstruktion ebenfalls 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 hat, helfen daher auch dem Betreiber. Ein Grund mehr, die Modelle gut zu pflegen – denn sie bleiben keine rein internen Dokumente: Sie eignen sich hervorragend, um Default-Konfigurationen und Security-Eigenschaften transparent zu machen.

Es ist nicht die Frage, ob Sie Opfer eines Security-Angriffs werden – sondern wann.

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 wann. Daher ist bei allen proaktiven Schutzmaßnahmen wichtig, auch reaktiv auf den Fall vorbereitet zu sein, sollte tatsächlich ein Angriff passieren oder eine Schwachstelle im Produkt bekannt werden.

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

  • Security-Angriffe leben von der Kreativität von Menschen, die Schutzmaßnahmen umgehen.
  • 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.
  • 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 eine Reihe hardwarenäherer Kommunikationsprotokolle, die Sie nicht selbst geschrieben haben – auch diese Protokolle können Schwachstellen enthalten. Ein spektakulärer Fall im Jahr 2021 waren die unter dem Namen Ripple 20 veröffentlichten Schwachstellen, die tief im TCP/IP-Protokollstack vergraben sind. Bis heute ist nicht umfassend geklärt, welche Produkte von diesen Schwachstellen betroffen sind.
Großes Vertrauen in Security ernten daher nicht solche Hersteller, die nie Schwachstellen in ihren Produkten bekannt machen, sondern solche, die mit bekannt gewordenen Schwachstellen professionell umgehen.

An diesen Punkten lässt sich nichts ändern. 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 bekannt gewordenen Schwachstellen professionell umgehen. Professionell bedeutet, dass:

  • Sie Ihre Kunden frühzeitig über eine Schwachstelle und/oder einen Angriff informieren,
  • Sie genau sagen können, bei welchen Produkten/Versionen) Ihr Kunde betroffen ist,
  • Sie Hilfestellung geben können, wie das Problem zu beheben ist – idealerweise durch ein Security-Patch, das 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-36 oder das JSON-basierte Format CSAF (Common Security Advisory Framework)7. Wichtig ist in erster Linie, dass Sie Informationen und Patches zeitnah, maschinenlesbar und security-überprüfbar bzw. über eine sichere Verbindung bereitstellen.

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.

Müssen Hersteller Security 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 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 Maschinenrichtlinie8:

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.

Richtlinie bietet Interpretationsspielraum

Dieses Zitat bietet 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 EN ISO 12100 bzw. der Maschinenrichtlinie beleuchtet werden:

  • bestimmungsgemäße Verwendung,
  • vorhersehbare Fehlanwendung.

Um hier nicht zu sehr in die Grundlagen der Safety-Risikobeurteilung abzutauchen, 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 auch 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 andererseits eine oft anspruchsvolle Aufgabe.

Keine vernünftigerweise vorhersehbare Fehlanwendung

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

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.

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.

Im Internet herrschen eigene Bedingungen

Ü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-Schutzarten10 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 um keine harmonisierte Norm mit Konformitätsvermutung entsprechend einer EU-Richtlinie handelt.

Weitere rechtliche Rahmenbedingungen

Ein weiteres Thema steht in den Startlöchern: die Security-Zertifizierung von Produkten. Der EU Cybersecurity Act fordert EU-weit einheitliche Security-Zertifizierungen11 – und Betreiber sehen dem freudig entgegen. Den Grund dafür haben Sie in den oben beschriebenen Schritten zur Security-Denkweise bereits kennengelernt: Betreiber brauchen eine transparente Kommunikation von Security-Eigenschaften – Zertifikate versprechen, diese zu liefern.

Buchtipp

Cybersicherheit ist nicht nur sinnvoll, sie ist die absolute Grundvoraussetzung für eine erfolgreiche Digitalisierung. Das Fachbuch Cybersicherheit erläutert die Relevanz von IT-Sicherheit in Industrieunternehmen und gibt die nötige Unterstützung, diese im eigenen Unternehmen umzusetzen.

Dem Thema Security proaktiv nähern

Viele Dinge im Zusammenhang mit Security sind noch nicht eindeutig geklärt. So ist noch unklar, welcher Standard künftig Basis sein soll für eine Zertifizierung entsprechend dem EU Cybersecurity Act. Ebenfalls zeichnet sich noch nicht ab, 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 erwähnt: In den obigen Ausführungen oben haben sich die Autoren dieses Artikels auf öffentlich-rechtliche Anforderungen beschränkt, mit denen der Staat Marktteilnehmern bestimmte Vorgaben macht. Darüber hinaus steht es Unternehmen 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 für Hersteller aufgrund von Security bestehen.

Security proaktiv angehen

Zur weiteren Vertiefung veranstaltet IBF gemeinsam mit Experten der Admeritia GmbH ein zweitägiges Praxis-Seminar (WEB bzw. Präsenz). Hier erfahren die Teilnehmer, welche Aspekte der IT-Security bei der Konzeption und Planung von Maschinen und Anlagen besonders beachtet werden sollten, um den gesetzlich geforderten "Stand der Technik" auch im Bereich der Security von Maschinen und Anlagen gewährleisten zu können.

Seminar: Security by Design

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 ähneln sich in allen Standards und lassen sich nicht in einer Woche aus dem Boden stampfen.

Wenn Sie sich angewöhnen, die Security-Perspektive in Konstruktion, Inbetriebnahme und Betrieb von Maschinen einzunehmen, verlieren sowohl das Thema als solches, als auch der Schritt zu einer Security-Zertifizierung – künftig möglicherweise ein Markteintrittskriterium – an Schrecken.

Fußnoten:

1 Mehr Informationen dazu: Kim Zetter, Countdown to Zero Day, 2014, Ralph Langner, Stuxnet und die Folgen
2German company Pilz hit by a Ransomware attack
3 Safety of machinery — Relationship with ISO 12100 — Part 4: Guidance to machinery manufacturers for consideration of related IT-security (cyber security) aspects
4 More information: Edward Marszal, James McGlone: Security PHA Review for Consequence-Based Cybersecurity, 2019

5 Andy Greenberg: Sandworm, 2019
Gavin Ashton: Maersk, me & notPetya, 2020
6IEC TR 62443-2-3:2015, Security for industrial automation and control systems - Part 2-3: Patch management in the IACS environment
7Oasis Common Security Advisory Framework
8 Maschinenrichtlinie 2006/42/EG
9 ISO/TR 22100-4: Safety of machinery — Relationship with ISO 12100 — Part 4: Guidance to machinery manufacturers for consideration of related IT-security (cyber security) aspects
10 IP steht in diesem Zusammenhang für Ingress Protection.
11 European Commission: The EU Cybersecurity Act

* Autoren:

  • Sarah Fluchs ist MSc Automatisierungstechnik, CTO und OT-Security Consultant bei der admeritia GmbH, Langenfeld;
  • Heiko Rudolph ist Gründer und Geschäftsführer der admeritia GmbH, Langenfeld.

(ID:47400677)

Weiterführende Inhalte