(Bild: Markus Dahlmanns/Martin Henze)
Martin Henze vom Fraunhofer FKIE (l.) und Markus Dahlmanns von der RWTH Aachen im Interview mit der IEE. Sie hatten, mit dem Internet verbundenen Steuerungen gesucht, die das OPC UA Protokoll verwenden – und gefunden. Markus Dahlmanns/Martin Henze
Martin Henze vom Fraunhofer FKIE und Markus Dahlmanns von der RWTH Aachen haben mit Kollegen nach unsicheren, mit dem Internet verbundenen Steuerungen gesucht, die das OPC UA Protokoll verwenden – und gefunden. Von etwa 1100 Geräten waren 92 % nicht ausreichend sicher konfiguriert. Dabei gilt OPC UA eigentlich als sicheres Industrieprotokoll.
Herr Henze, Herr Dahlmanns, Ihre Veröffentlichung trägt den Namen „Das Gewissen mit OPC UA erleichtern“. Hatten Sie mit diesen Ergebnissen gerechnet?
Markus Dahlmanns: In der Vergangenheit haben Forscher bereits aufgezeigt, dass viele Industrieanlagen ohne jegliche Sicherheitsvorkehrungen mit dem Internet verbunden sind. Hier fokussierte sich die Forschung allerdings auf Protokolle, die in ihrem Ursprung gar keine Sicherheitsvorkehrungen bieten, weil sie nur für die Nutzung in abgeschotteten Produktionsnetzwerken vorgesehen waren, beispielsweise Ethernet/IP. Bei OPC UA war zunächst die Frage, ob es überhaupt Installationen gibt, die aus dem Internet erreichbar sind und wenn ja, wie viele. Wir hatten natürlich gehofft, dass es im Gegensatz zu unsicheren Protokollen immer mehr Anwendung findet und daraufhin alle vier Milliarden IPv4-Adressen abgesucht und letztendlich auch einige gefunden, hinter denen Geräte erreichbar waren, die das OPC UA Protokoll verwenden.
Martin Henze: Was uns dabei überrascht hat, war der große Anteil an Systemen, die teilweise massiv unsicher konfiguriert sind. Dass beispielsweise 44 % der aus dem Internet erreichbaren Systeme keinerlei Zugriffskontrolle implementieren, haben wir so nicht erwartet. Noch überraschender war für uns jedoch, dass hunderte Geräte eines Herstellers das gleiche Sicherheitszertifikat verwenden.
Welche Geräte haben Sie genau gefunden?
Markus Dahlmanns: "Bei OPC UA war zunächst die Frage, ob es überhaupt Installationen gibt, die aus dem Internet erreichbar sind und wenn ja, wie viele." Markus Dahlmanns/Martin Henze
Markus Dahlmanns: Wir haben Geräte unterschiedlichster, allerdings durchweg sehr bekannter Hersteller von industriellen Komponenten gefunden. Die ausgelesenen Gerätebezeichnungen ließen, unter anderem, Rückschlüsse auf verschiedene Komponenten, beispielsweise speicherprogrammierbare Steuerungen, zu. Und auch die Daten, die die Geräte bereitstellen, deuten auf verschiedenste Einsatzzwecke hin; von Gebäudeautomatisierungen über Parkhausmanagementsysteme bis hin zu Wasser- und Entwässerungssystemen. Dementsprechend ist die Problematik der öffentlich zugreifbaren Geräte auch sehr weitreichend: von verletzter Privatsphäre durch das Veröffentlichen von Kennzeichendaten im Falle der Parkhaussysteme bis hin zu möglicherweise physischen Eingriffen in Abläufe der Entwässerungssysteme.
Was sind die Gründe dafür, dass die Geräte unsicher sind?
Markus Dahlmanns: Häufig ist eine falsche Konfiguration durch vermeintliche Unachtsamkeit der Anwender ursächlich. Wir haben vereinzelt in die Datenblätter der gefundenen Geräte geschaut und gemerkt, dass sie häufig dazu fähig wären, sicherer zu kommunizieren, aber die entsprechenden Funktionalitäten wohl nicht aktiviert wurden, sei es durch Unachtsamkeit oder Unwissen.
Martin Henze: Umgekehrt muss man aber auch festhalten, dass viele der Geräte nicht von Werk aus sicher konfiguriert ausgeliefert werden. In der Wissenschaft ist die vorherrschende Meinung, dass Systeme grundsätzlich so sicher wie möglich, sogenanntes “secure by default”, ausgeliefert werden sollten, um zu vermeiden, dass unbeabsichtigt unsichere Konfigurationen in Betrieb genommen werden. Eine etwaige abgeschwächte Sicherheitskonfiguration, zum Beispiel um Kompatibilität mit älteren Geräten herzustellen, wäre dann immer eine bewusste Entscheidung der Anwender.
Was haben die 8 % „richtig“ gemacht?
Markus Dahlmanns: Wir haben unsere Konfigurationsanalyse an den Empfehlungen der OPC Foundation orientiert. Das heißt die 8 % der gefundenen Geräte folgen diesen Empfehlungen, deaktivieren also nicht die Kommunikationssicherheit durch alleinige Unterstützung des Security Modes “None”, bieten aktuelle Sicherheitsalgorithmen durch entsprechende Security Policies an und verbieten gleichzeitig anonyme Zugriffe.
Martin Henze: Aber auch die verbleibenden 92 % haben zumindest schon mal einen Schritt in die richtige Richtung gemacht, indem sie immerhin auf ein Protokoll setzen, das grundsätzlich ein ausreichendes Sicherheitsniveau bieten kann. Somit liegen zumindest die notwendigen Voraussetzungen vor, um in Zukunft einen sicheren Betrieb realisieren zu können. Im Gegensatz dazu gibt es immer noch eine Vielzahl an industriellen Geräten, die über ältere Protokolle ohne jegliche Sicherheitsfunktionalität, wie das eben schon genannte Ethernet/IP oder auch Modbus, im Internet erreichbar sind.
Welche Folgen haben die unsicher konfigurierten OPC UA Geräte und was wäre das Worst-Case-Szenario?
Martin Henze: "Häufig ist eine falsche Konfiguration durch vermeintliche Unachtsamkeit der Anwender ursächlich." Markus Dahlmanns/Martin Henze
Martin Henze: Das ist sehr vom Einzelfall abhängig und ohne böswillige Intention nur schwer einzuschätzen. Im schlimmsten Fall erlangen Angreifer aber vollständigen Zugriff auf das Gerät und können so beispielsweise Daten ändern oder Funktionen ausführen, die sofortigen Einfluss auf physische Aktionen der Maschine haben könnten. Ein solcher Zugriff ist für jeden, ohne besonderes Wissen, bei hunderten der im Internet erreichbaren OPC UA Systeme möglich. Natürlich haben wir nicht ausprobiert, was passiert, wenn man Änderungen an Daten vornimmt oder Funktionen aufruft. Aber man kann sich natürlich leicht vorstellen, dass es ziemlich fatal ausgehen kann, wenn jemand von außen beispielsweise eine CNC-Maschine oder eine Gebäudeautomatisierung steuern kann.
Gab es Feedback betroffener Einrichtungen, die Sie über ihre Sicherheitslücke informiert haben?
Markus Dahlmanns: Wir haben durch manuelle Analyse der auf den Geräten verfügbaren Daten Betreiber von 50 Geräten identifizieren können, die wir daraufhin auch kontaktiert haben. Auf diese Aufklärungskampagne haben wir leider nur zwei Antworten bekommen – bei einem Großteil der Geräte hat sich seitdem nichts an der Konfiguration geändert. Außerdem haben wir Kontakt zu dem Hersteller aufgenommen, dessen Geräte in vielen Fällen das gleiche Sicherheitszertifikat verwenden. Das hat dazu geführt, dass der Hersteller seine Kunden nochmals, über die Handbücher seiner Produkte hinaus, in einer Kundeninformation auf Sicherheitsrisiken wie zum Beispiel mögliche Immitationsattacken, hingewiesen hat. Leider stellen wir aber noch immer mehr und mehr Geräte fest, die dieses Zertifikat nutzen. Darüber hinaus wurden wir im Nachgang nun, unter anderem, von einem Interessenverband für Industrieunternehmen kontaktiert, die unsere Studie nutzen möchten, um Mitglieder weiter für das Thema IT-Sicherheit zu sensibilisieren.
In Ihren Ergebnissen der gefundenen Geräte stechen manche Unternehmen hervor. Sind diese vermehrt im Einsatz oder von Haus aus „unsicherer“?
Markus Dahlmanns: Wir haben uns bewusst dazu entschieden die Herstellernamen bei der Analyse der Sicherheitsprobleme nicht zu nennen. Das heißt die Nennung der Namen lässt keine Rückschlüsse darauf zu, ob die Geräte entsprechender Hersteller unsicherer konfiguriert sind als andere. Den im Text erwähnten Herstellern konnten wir anhand unserer Methodik und vorliegenden Daten die meisten Geräte zuordnen und haben weitere Hersteller mit, teilweise auch nur leicht, geringerer Anzahl an gefundenen Geräten unter “others (andere)” zusammengefasst. Generell ist es aber schwierig, anhand der Daten von “nur” 1000 Systemen belastbare Aussagen über den vermehrten Einsatz oder die (Un-)Sicherheit von Systemen einzelner Hersteller zu treffen.
Sehen Sie das Sicherheitsproblem eher auf Seiten der Anwender oder der Hersteller beziehungsweise wessen „Gewissen“ meinten Sie?
Martin Henze: Mit dem Titel wollten wir zum Ausdruck bringen, dass es einen Trend zu geben scheint, das eigene Gewissen dadurch zu erleichtern, dass man “einfach” ein sicheres Protokoll wie OPC UA einsetzt. Unsere Forschung zeigt jedoch, dass dieser guten Absicht weitere Schritte folgen müssen. Aus Anwendersicht bedeutet dies insbesondere, dass industrielle Geräte sicher konfiguriert und in die bestehende Infrastruktur integriert werden müssen.
Markus Dahlmanns: Das setzt aber natürlich voraus, dass Hersteller auch Geräte liefern, die entsprechende Sicherheitsvorkehrungen unterstützen, wobei wir in unserer Studie nicht großflächig untersucht haben, ob das der Fall ist. Grundsätzlich ließe sich diese Pflicht aber auch auf Standardisierungsgremien übertragen, die dafür sorgen könnten, dass Hersteller es Anwendern so einfach wie möglich machen, ihre Geräte sicher zu konfigurieren. Das wäre beispielsweise auch möglich indem eine secure by default Konfiguration vorgeschrieben wäre.
Was könnte die Sicherheit standardmäßig erhöhen?
Markus Dahlmanns: Im Grunde alles, was es Anwendern so schwer wie möglich macht Geräte unsicher zu konfigurieren. Hinsichtlich sicherer Auslieferungskonfigurationen kennt man ähnliches zum Beispiel von modernen Internetroutern, die das WLAN von Anfang an automatisch verschlüsseln. Außerdem gibt es dort zusätzliche Warnmeldungen, die Anwender deutlich vor unsicheren Konfigurationen warnen. Abgerundet werden könnte das ganze durch regelmäßige Überprüfungen, die auch für Änderungen in der Sicherheitslandschaft, zum Beispiel veraltete Sicherheitsverfahren, Sorge tragen. Damit hatten wir uns Anfang des Jahres beschäftigt und entsprechende Softwaremodule kostenlos bereitgestellt.
Martin Henze: Dieser Punkt zeigt, dass die Absicherung von Systemen zur Prävention von Cyberangriffen nur ein wichtiger erster Schritt zur Erhöhung der Sicherheit ist. Industrieunternehmen und insbesondere Betreiber von kritischer Infrastruktur, also kurz Kritis, müssen sich zunehmend auch Gedanken über die Detektion von und Reaktion auf IT-Sicherheitsvorfälle machen, da eine 100%ige Sicherheit auch in Zukunft niemand wird garantieren können. Ein zunehmend wichtiges Thema wird aus meiner Sicht dabei Intrusion Detection werden, also die Erkennung von Angriffen oder Anomalien beispielsweise anhand von Kommunikationsmustern. Insbesondere im industriellen Umfeld sehe ich hierbei großes Potential in cyber-physischen Ansätzen, die semantisches Wissen über die (physikalischen) Produktionsprozesse heranziehen, um gerichtete Cyberangriffe auf Industrieanlagen besser erkennen zu können.
Sollten Industrieanlagen überhaupt an das Internet angeschlossen sein?
Martin Henze: Aus IT-Sicherheitssicht und insbesondere, wenn wir über das Themenfeld Kritis reden, ist die offensichtliche Antwort darauf “nein”. Industrieanlagen sollten soweit wie irgend möglich abgeschottet, also insbesondere nicht direkt aus dem Internet erreichbar, sein. Aus funktioneller Sicht, insbesondere im Zuge der Bestrebungen rund um Industrie 4.0 und dem Internet of Production, ist aber davon auszugehen, dass Industrieanlagen tatsächlich vermehrt über das Internet erreichbar sein werden. Im Bereich Kritis gibt es ähnliche Entwicklungen, etwa zur Realisierung von virtuellen Kraftwerken durch den Zusammenschluss dezentraler Energieerzeugungsanlagen.
Markus Dahlmanns: In jedem Fall muss man aber immer auch die Lebenszeit der Geräte im Hinterkopf behalten. Sie müssen ja von dem Zeitpunkt, von dem sie ans Netz gehen, bis zu dem Zeitpunkt wo sie ausgetauscht werden stets aktuelle Sicherheitsmechanismen unterstützen. Durch die lange Lebensdauer ist das bei industriellen Geräten aber nochmals deutlich schwieriger als bei IT-Geräten. Da gilt es immer abzuwägen, ob es nicht sinnvoller wäre die industrielle Anlage hinter entsprechenden Netzwerkkomponenten, beispielsweise VPN Hardware, zu betreiben, die die Anlage etwas abschirmen und gleichzeitig einfacher auszutauschen sind. Trotzdem darf man die Netzwerksicherheit der Anlage selbst nicht aus den Augen verlieren.
Das Interview führte Dr. Martin Large, Redakteur IEE
(ml)
