Die zunehmende Vernetzung und Digitalisierung industrieller Systeme bringt neue Herausforderungen in Bezug auf die IT-Sicherheit mit sich. Ein vertrauenswürdiger, sicherer Umgang mit sensiblen Daten wie Produkt- und Produktionswissen ist ebenso notwendig wie der Schutz vor Angriffen auf vernetzte Systeme, wie es nicht zuletzt von einschlägigen Normen wie der IEC 62443 „Industrielle Kommunikationsnetze – IT-Sicherheit für Netze und Systeme“ gefordert wird. Um möglichen Schäden entgegenzuwirken, muss die Sicherheit der Informationstechnologie (IT) und der Operational Technology (OT) nicht nur im laufenden Betrieb, sondern bereits während des gesamten Entwicklungsprozesses eines Systems und seiner Software gewährleistet werden. Daher ist es wichtig – und auch von der IEC 62443 gefordert – Bedrohungen für das System so früh wie möglich im Entwicklungsprozess zu analysieren und ihnen durch geeignete Entwurfsentscheidungen entgegenzuwirken.

Für die Vernetzung industrieller Systeme, insbesondere an der Schwelle zwischen OT und IT, bietet sich der Einsatz von OPC UA an. OPC UA ist mehr als nur ein Kommunikationsprotokoll, da es auch Datenmodelle und Interaktionskonzepte beschreibt und einen herstellerübergreifenden Standard bietet, der die Vernetzung einzelner Komponenten erheblich vereinfachen kann. Weiterhin bietet OPC UA Informationsmodelle, welche die Eigenschaften, Fähigkeiten und Zugriffsrechte von Maschinen und Anlagen typsicher und semantisch eindeutig beschreiben. OPC UA wurde überdies von vornherein mit expliziter Betrachtung der IT-Sicherheit – also secure by design – entwickelt. Dies wurde im Rahmen einer vom Bundesamt für Sicherheit in der Informationstechnik (BSI) in Auftrag gegebenen Studie unter Federführung des TÜV SÜD Rail bestätigt. Aber OPC UA ist nicht standardmäßig sicher (secure by default): Die vorhandenen Sicherheitsmechanismen müssen aktiviert und OPC UA sicher in die jeweilige Anwendung integriert werden.

Klar definierte Vorgehensweisen

Bild 1. Die Auswirkungen des Security Development Lifecycle (SDL) von Microsoft auf die IT-Sicherheit ihrer Anwendungssoftware.

© Fraunhofer IEM

Der Einsatz von klar definierten Vorgehensweisen für die sichere Entwicklung von Software kann die Angriffsanfälligkeit dabei drastisch senken, wie Microsoft durch eine Studie für den Einsatz seines Security Development Lifecycles (SDL) zeigt (siehe Bild 1). Dazu wurden die Schwachstellen in zwei Produkten (Windows und SQL-Server) jeweils vor und nach der Einführung des SDL miteinander verglichen. Im Fall des SQL-Servers ist hier sogar eine Reduzierung der Schwachstellen von mehr als 90 % zu verzeichnen. In den frühen Phasen des SDL ist eine systematische Erfassung möglicher Be­drohungen vorgesehen, zum Beispiel mit Microsofts ‚Stride‘-Methode und dem zugehörigen Softwarewerkzeug. Stride unterstützt die systematische, in Teilen automatisierte Analyse von Bedrohungen anhand eines Datenflussmodells des Systems.

SDL und Stride sind nicht nur für reine IT-, sondern ebenso für IT/OT-Systeme anwendbar. Um den Aufwand dafür zu verringern, können die Methoden an die Spezifika von OT-Systemen angepasst werden. Für die Bedrohungsanalyse mit Stride und OPC UA hat das Fraunhofer IEM genau das getan: Über einen Erweiterungsmechanismus von Stride wurden für OPC UA spezifische Bedrohungen zur automatischen Betrachtung ergänzt, welche anhand einer sicher und einer unsicher konfigurierten OPC-UA-Verbindung evaluiert wurden. Im Folgenden werden die Stride-Methode sowie die erstellte Erweiterung vorgestellt.

Die ‚Stride‘-Methodik

Die von Microsoft entwickelte Stride-Methode bietet ein systematisches Vorgehen zur Analyse von Bedrohungen für ein System. Dabei werden die klassischen drei Schutzziele – Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability) – um drei weitere Schutzziele, den sogenannten ‚Triple A‘, erweitert: Authentifizierung (Authentification), Autorisierung (Authorization) und Zurechenbarkeit (Accountability). Diesen sechs Schutzzielen stehen die Bedrohungskategorien gegenüber, welche das Akronym Stride ergeben: Spoofing (Die Identität eines anderen vortäuschen), Tampering (Daten manipulieren), Repudiation (Nachweisbarkeit, dass eine bestimmte Person eine Aktion durchgeführt hat), Information Disclosure (Offenlegung von Informationen), Denial of Service (Das System für legitime Benutzer unbenutzbar machen), Elevation of Privilege (Bestehende Rechte ausweiten). 

Bild 2. Datenflussdiagramm im Microsoft Threat Modeling Tool.

© Fraunhofer IEM

Bei der Anwendung von Stride in der Bedrohungsanalyse gibt es zwei Möglichkeiten: ‚Stride per Element‘ und ‚Stride per Interaction‘. Im ersten Fall werden die einzelnen Elemente, also die Elemente eines Systems mittels der Bedrohungskategorien betrachtet, wohingegen im zweiten Fall die Betrachtung basierend auf den Interaktionen zwischen den Elementen eines Systems vollzogen wird.

Zur Unterstützung dieser Methodik hat Microsoft das ‚Threat Modeling Tool‘ entwickelt. Dieses kann für eine frühe Bedrohungsanalyse des zu entwickelnden Systems genutzt werden. Hierzu erstellt man in einem ersten Schritt ein Modell des Systems bestehend aus Komponenten und Datenflüssen. Dieses Modell ist das Datenflussdiagramm (DFD) – exemplarisch in Bild 2 abgebildet. Ein DFD besteht aus externen Entitäten (andere Systeme, welche mit dem eigenen interagieren, wie beispielsweise der menschliche Nutzer), Prozessen (Komponenten des eigenen Systems, wie etwa der OPC-UA-­Client), Datenflüssen (Interaktionen zwischen den Elementen des DFD, wie beispielsweise die OPC-UA-Kommunikation zwischen OPC-UA-Client und -Server) und Datenspeicher (dies können bei­spielsweise Datenbanken, Dateien oder auch Speicherbereiche sein, wie beispielsweise die Database). Zusätzlich werden sogenannte Trust Boundaries, also Vertrauensgrenzen, in das DFD integriert – wie beispielsweise die Internet Boundary. Diese sind essenziell für die eigentliche Aufgabe des Tools, welche darin besteht, automatisch existierende Bedrohungen für das aktuell modellierte System zu generieren.

In dem Fall der Kommunikation über Vertrauensgrenzen hinweg entstehen die größten Bedrohungen, da in diesem Fall dem Kommunikationsweg nicht vertraut werden kann und somit eine erhöhte Wahrscheinlichkeit für einen Angriff besteht. Es könnte beispielsweise ein Angreifer im Fall der unverschlüsselten Übertragung per HTTP und OPC-UA-Secure-Channel ‚None‘ die Kommunikation mitlesen. Die generierten Bedrohungen des Tools werden an sämtlichen Kommunikationswegen zwischen Elementen angelegt und ermöglichen es somit, bereits während des Designs sicherzustellen, dass diese Bedrohungen nicht vergessen werden. 

Da immer wieder neue Bedrohungen gefunden werden und jede Technologie individuell verwundbar ist, verwendet das ‚Microsoft Threat Modeling Tool‘ ein anpassbares Template, welches einfach um weitere Bedrohungen ergänzt werden kann. Dazu muss für eine Bedrohung ein entsprechender beschreibender Text, am besten mit möglichen Gegenmaßnahmen, erstellt werden. Zusätzlich ist es entscheidend, über Include- und Exclude-Bedingungen festzulegen, wann eine Bedrohung generiert werden muss. Dies ist ein wichtiger Mechanismus, um bekannte Bedrohungen in neuen Systementwicklungen zu berücksichtigen und entsprechende Gegenmaßnahmen zu implementieren. Für OPC UA fehlte dieses Template allerdings bisher. Das jetzt von Fraunhofer IEM entwickelte Template wird im Folgenden vorgestellt.

Für OPC UA hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) unter Federführung des TÜV SÜD Rail im Jahr 2015 eine Sicherheitsana­lyse durchgeführt. Die OPC-UA-­Kommunikation wurde hinsichtlich der Secure-Channel-, Session- und Discovery-Dienste systematisch und spezifisch ana­lysiert. Die Spezifikationsanalyse hat keine systematischen Fehler ergeben und damit gezeigt, dass OPC UA im Gegensatz zu vielen anderen Industrieproto­kollen ein hohes Maß an Sicherheit ­bietet. Jedoch müssen diese Sicherheitsmechanismen auch korrekt bezüglich möglicher Bedrohungen konfiguriert ­werden. 

Gefahren bei der OPC-UA-Kommunikation

Die größte Gefahr für jegliche Kommunikation ist, dass vertrauliche Daten mitgelesen werden und somit Informationen offengelegt werden, oder, dass die Integrität der versendeten Daten nicht gewähr­leistet werden kann und somit Infor­ma­tionen verändert, manipuliert oder ­verfälscht den Empfänger unbemerkt erreichen. Weitere Gefahren in der Kommunikation mittels OPC UA bestehen darin, dass die Authentizität verschleiert wird oder nicht autorisierte Operationen wie „Schreiben von Daten“ oder „Löschen von Daten“ durchgeführt werden. Letztendlich besteht die Gefahr, dass die Konfiguration eines OPC-UA-Servers oder dessen Informationsmodells geändert wird, sodass zum Beispiel kein Zugriff mehr auf Stammdaten oder Vergangenheitsdaten möglich ist. 

Zur Modellierung der OPC-UA-Prozesse hat das Fraunhofer IEM ein OPC-UA-Stride-Template im ‚Microsoft Threat Modeling Tool‘ erstellt. Dabei bilden sogenannte ‚Stencils‘ Prozesse wie OPC-UA-Server und -Clients oder Datenflüsse wie eine OPC-UA-Kommunikationsbeziehung ab. Jeder dieser OPC-UA-spezifischen Stencils verfügt über OPC-UA-relevante Security-Konfigurationseinstellungen. Die Stencils werden zur Modellierung und Konfiguration eines Systems genutzt. Abhängig vom Systemmodell kann automatisch eine Bedrohungsanalyse durchgeführt werden. Diese Analyse bezieht sich auf die verwendeten Stencils und deren Eigenschaften. Damit OPC-UA-spezifische Bedrohungen automatisch analysiert und ein Bericht generiert werden kann, wurden als zweiter Schritt Bedrohungen auf Basis der Stencils und deren Eigenschaften im Stride-Template modelliert. Die Bedrohungen wurden gemäß Stride in die entsprechenden Bedrohungskategorien einsortiert. 

Zusammengefasst bedeutet die Verwendung eines Templates für das ‚Microsoft Threat Modeling Tool‘, welches sich der spezifischen Bedrohungen für OPC UA annimmt, einen Zugewinn an Sicherheit in der Anwendung von OPC UA. Die automatisierte Betrachtung von OPC-UA-spezifischen Bedrohungen reduziert manuelle Arbeit in einer durch die IEC 62443 vorgeschriebenen Bedrohungsanalyse und stellt sicher, dass mögliche Bedrohungen nicht vergessen werden. 

Zugewinn an Sicherheit

Auf diese Weise werden die Systeme zukünftig sicherer im Sinne der IT-Sicherheit, wodurch diese letztlich auch im Sinne der Betriebssicherheit sicherer werden. Ein weiterer Vorteil der automatisierten Generierung typischer Bedrohungen im Zusammenhang mit OPC UA liegt darin, dass alle Unternehmen, welche keine eigene Abteilung für IT-Sicherheitsexperten haben, in die Lage versetzt werden, mögliche Schwachstellen für ihr System direkt unkompliziert angezeigt zu bekommen.

Die direkte Verwendung des Templates ist nur eine Möglichkeit, von dem bereitgestellten Wissen zu profitieren. Weitere Möglichkeiten sind, dieses Template als Ausgangsbasis für ein eigenes Template zu nutzen oder bei bereits bestehenden Templates das Wissen um die OPC-UA-spezifischen Bedrohungen zu ergänzen und weiterzuentwickeln. Denn gerade die Weiterentwicklung trägt zur Verbesserung der folgenden Bedrohungsanalysen bei, was wiederum im Sinne der Prozessverbesserung nach IEC 62443 ist.

Durch die weitere Verbreitung von Bedrohungsanalysen und das Aufzeigen möglicher Gegenmaßnahmen – wie beispielsweise den Einsatz von Authentifizierung oder sicherer Konfigurationen frühzeitig im Entwicklungsprozess, können diese Gegenmaßnahmen rechtzeitig eingeplant und realisiert werden. Eine nachträgliche Korrektur bei Bekanntwerden einer Schwachstelle im Produkt ist in vielen Fällen hingegen nur mit sehr hohem Aufwand und damit Kosten verbunden. Um dies zu verhindern, stellt dieses Template die OPC-UA-spezifischen Bedrohungen für die automatische Generierung in der Bedrohungsanalyse zur Verfügung und stellt damit die kosteneffektive Umsetzung von Gegenmaßnahmen sicher. Somit können zukünftige OPC-UA-fähige Produkte sicherer gestaltet werden, was letztlich auch der Sicherstellung der Betriebssicherheit dient.

Autoren: 
Dr. Matthias Meyer ist Abteilungsleiter Software­technik und IT-Sicherheit beim Fraunhofer IEM;
Dr. Uwe Pohlmann ist wissenschaftlicher itarbeiter beim Fraunhofer IEM;
Sven Merschjohann ist wissenschaftlicher Mitarbeiter beim Fraunhofer IEM.