OPC UA

Systeme von Beginn an absichern

6. September 2018, 0:00 Uhr | Dr. Matthias Meyer, Dr. Uwe Pohlmann, Sven Merschjohann

Fortsetzung des Artikels von Teil 2

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). 

Anbieter zum Thema

zu Matchmaker+
Datenflussdiagramm, Fraunhofer
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. 


  1. Systeme von Beginn an absichern
  2. Klar definierte Vorgehensweisen
  3. Die ‚Stride‘-Methodik
  4. Gefahren bei der OPC-UA-Kommunikation
  5. Zugewinn an Sicherheit

Verwandte Artikel

Fraunhofer IEM Institut für Entwurfstechnik Mechatronik, OPC Foundation

Safety & Security

TSN & OPC UA