Professional Articles

Die Digitalisierung und Vernetzung hat mittlerweile auch Safety-kritische Bereiche der Operational Technology (OT) wie den Eisenbahnsektor erreicht, bei der Hard- und Software physikalische Geräte überwachen und steuern. So überwachen und steuern in der Leit- und Sicherungstechnik sogenannte Object Controller, die im Feld befindlichen Weichen, Signale oder Achszähler.

Die bisher eingesetzten geschlossenen und Herstellerspezifischen Systeme, typischerweise charakterisiert durch proprietäre, monolithische und teure Systeme, werden vermehrt durch Standard-Hard- und Softwaretechnologien, COTS (Commercial-Off-The-Shelf) und IP-basierte Kommunikation ersetzt. Dadurch steigern sich Wirtschaftlichkeit, Rentabilität und Wartungsfreundlichkeit und es werden neue Kundendienstleistungen in Form von digitalen Diensten ermöglicht. Jedoch steigt dadurch auch das Risiko von IT-Angriffen. Es ist nicht mehr ausreichend, ausschließlich die funktionale Sicherheit (Safety) von OT-Systemen zu betrachten (vgl. DIN EN 5012 [11), sondern es muss gleichermaßen die Cybersicherheit (Security) betrachtet werden. Die gemeinsame Betrachtung von Safety und Security wird mittlerweile auch in Standards [2, 3] gefordert.

Jedoch ist die Integration von Security-Mechanismen in ein Safety-zertifiziertes OT-System eine große Herausforderung. [9] So verlangt die Eisenbahnsicherheitsnorm EN 50128 [4], dass alle Softwarekomponenten nach dem höchsten Safety-lntegritätslevel (SIL) zu zertifizieren sind, es sei denn, ein Nachweis der Rückwirkungsfreiheit kann erbracht werden. IT-Sicherheitsfunktionen werden meist mit Open Source-Lösungen (zum Beispiel OpenSSL) realisiert, welche mit möglicherweise weniger strengen Entwicklungs- und Verifikationsmethoden entwickelt wurden als hoch Safety-kritische Softwarekomponenten (die zum Beispiel SIL4 zertifiziert sind). Dadurch lassen sich diese nicht ohne Weiteres nach den höchsten SIL-Stufen zertifizieren. Security Mechanismen haben zudem einen anderen Lebenszyklus, da neu gefundene Schwachstellen gepatcht werden müssen. Dies muss unabhängig von den Safety-Komponenten erfolgen, um eine kostspielige Rezertifizierung zu vermeiden. Weiterhin müssen die Systeme gegen Manipulationen geschützt werden. So könnte beispielsweise ein Angreifer mit Zugriff auf das System versuchen, die Firmware zu manipulieren.

Dieser Artikel gibt einen Überblick über die im Forschungsprojekt HASELNUSS (Hardwarebasierte Sicherheitsplattform für Eisenbahn-Leit- und Sicherungstechnik) [5] entwickelte IT-Sicherheitsarchitektur, die an OT-Systeme der Bahn angepasst ist. Basierend auf einem Hardware-Sicherheitsanker und speziellen Software-Komponenten können Safety und Security-Maßnahmen auf einer Hardware-Plattform realisiert werden.

Sicherheitsanforderungen

Mit der DIN-Vornorm VDE V 0831-104131 wurde erstmals ein Standard entwickelt, der Empfehlungen zur Definition von IT-Sicherheitsanforderungen für elektrische Bahnanlagen gibt. Dabei wurden die Ansätze der IEC 62443 für industrielle Kommunikationsnetze übernommen. Basierend auf dieser Vornorm wurden zur Entwicklung der HASELNUSS-Architektur 14 IT-Sicherheitsanforderungen identifiziert. [6] Hierbei wurden die folgenden Anforderungen als besonders relevant angesehen: sichere Speicherung von kryptographischen Geheimnissen, Sicherstellung der Systemintegrität und Erkennung von Manipulationen, sichere Software Update-Mechanismen, Erkennung von Angriffsversuchen über das Netzwerk, sichere Kommunikation zwischen Endpunkten sowie die Möglichkeit, sowohl Safety- als auch Security-Anwendungen gemeinsam auf einem System zu betreiben, sodass diese sich nicht gegenseitig beeinflussen.

HASELNUSS-Architektur

In diesem Abschnitt wird die HASELNUSS-Architektur beschrieben. I8I Zunächst wird das grundlegende Konzept beschrieben und wie darin die zuvor beschriebenen Sicherheitsanforderungen erfüllt werden. Anschließend werden in den darauffolgenden Abschnitten die einzelnen Komponenten im Detail erläutert.

Grundlegendes Konzept

Die HASELNUSS-Architektur ermöglicht es, Security-Maßnahmen auf Safety OT-Systemen wie beispielsweise Object Controllern zu betreiben und ist in Abbildung 1 dargestellt. Sie lässt sich jedoch auf andere Safety-kritische Systeme übertragen. Sie besteht aus drei wesentlichen Bestandteilen: einer Hardware-Plattform mit einem Hardware-Sicherheitsmodul in Form eines Trusted Platform Modules (TPM) 2.0, einem MILS (Multiple Independent Levels of Safety and Security) Betriebssystem und verschiedenen Security-Anwendungen.

Das TPM dient als Security-Anker und ermöglicht unter anderem die sichere Speicherung kryptographischer Schlüssel (zum Beispiel zur Absicherung von Kommunikationsverbindungen), Measured Boot zur Erkennung von Manipulationen der Systemsoftware oder Remote Attestation zur Erkennung von Manipulationen durch autorisierte externe Parteien. Der Start des MILS-Betriebssystems wird mittels Measured Boot überwacht und ermöglicht dann den gemeinsamen Betrieb von Safety und Security-Anwendungen. Security-Anwendungen sind beispielsweise Anomalieerkennungsverfahren, die Angriffe über das Netzwerk erkennen, sichere Software-
Update Protokolle oder eine klassische Firewall. Parallel zu den Security-Anwendungen können rückwirkungsfrei zertifizierte Safety-Anwendungen laufen, beispielsweise ein Object Controller, welcher über das RaSTA (Rail Safe Transport Application) Protokoll [7] mit Bahnstellwerken kommuniziert. Nachfolgend werden die einzelnen Schichten der Architektur im Detail beschrieben.

MILS Plattform

Die MILS (Multiple Independent Levels of Security) Plattform ermöglicht eine Zertifizierung von Systemen mit unterschiedlicher Kritikalität. [10] Softwarepartitionen werden strikt räumlich und zeitlich getrennt und jegliche Kommunikation zwischen Partitionen wird kontrolliert. Neben Hardware-Komponenten wie CPU (Central Processing Unit), MMU (Memory Management Unit) oder 1/0 MMU ist die zentrale Software-Komponente der Separation Kernel (SK). Dieser stellt getrennte Sicherheitsdomänen (so genannte Partitionen) bereit, verwaltet die Hardware und setzt Sicherheitsrichtlinien (Policies) für Informationsfluss, Zugriffskontrolle und Ressourcenverfügbarkeit durch. Anwendungen können in verschiedenen Partitionen isoliert werden, sodass es keine gegenseitigen Abhängigkeiten gibt. Bei Bedarf können jedoch streng kontrollierte Kommunikations-kanäle konfiguriert werden. Die Trenn- und Kontrollmechanismen des SK sind unumgehbar und so klein und einfach implementiert, dass die Korrektheit des Codes einfach überprüft werden kann.

Abbildung 1: HASELNUSS-Architektur

In der HASELNUSS-Architektur werden Safety- und Security-Anwendungen einzelnen Partitionen zugeordnet. Der SK stellt die Trennung der Partitionen sicher und verteilt die verfügbaren Ressourcen auf die einzelnen Partitionen. Die Einhaltung von Echtzeitanforderungen für Safety-Anwendungen kann dementsprechend konfiguriert werden. Konkret wird als SIL4 zertifizierte Safety-Anwendung die Funktionalität eines Object Controllers umgesetzt die gemeinsam mit nicht zertifizierten Security-Anwendungen auf einer Hardware-Plattform läuft. Um neben den Safety-Anwendungen noch genügend Ressourcen für Security-Anwendungen zu haben, muss die verwendete Hardware-Plattform ausreichend schnell sein. Bestehende Safety-Zertifizierungen der Safety-Anwendung können so bestehen bleiben, auch wenn Security-Anwendungen aktualisiert werden.

Der SK stellt den „Single Point of Failure" in der MILS-Architektur dar und muss entsprechend EN 50128 [4] die höchste für das System erforderliche Safety-Stufe gewährleisten. Der in der HASELNUSS-Architektur verwendete SKl111 ist nach SIL4 zertifiziert.

Hardware-Plattform

Die Hardware-Plattform der in Abbildung 1 dargestellten HASELNUSS-Architektur besteht aus der CPU, dem Hauptspeicher, einem TPM und Schnittstellen zu Ethernet und Feldelementen, wie Signalen, Bahnschranken, etc. Das TPM stellt dabei den Security-Anker dar, mit dem der Boot-Vorgang der Plattform nachvollziehbar und fälschungssicher protokolliert wird und später verifizierbar ist. Dieser Vorgang nennt sich Measured Boot. Dabei werden alle Komponenten „gemessen", einschließlich des SK und den Partitionen. „Messen" bedeutet, dass ein kryptografischer Hashwert, ähnlich einer Prüfsumme, von jeder Komponente erstellt wird. Eine Komponente „misst" dabei jeweils die nächste Komponente in der Boot-Sequenz, speichert den Messwert sicher im TPM und startet daraufhin die nächste Komponente. Die gespeicherten Messwerte können dann mit Referenzwerten verglichen werden, um Manipulationen zu erkennen.

Ein TPM 2.0-Treiber für PikeOS dient als Schnittstelle für alle Partitionen, um mit dem TPM zu kommunizieren. Der TPM 2.0 Software Stack (TSS 2.0) wird als Middleware von Anwendungen eingesetzt, um mit dem TPM mit Hilfe des TPM-Treibers zu kommunizieren.

Abbildung 2: Exemplarische Implementierung der HASELNUSS-Architektur auf einer Hardware-Plattform mit drei CPUs

Um die HASELNUSS-Architektur SIL4 zertifiziert umzusetzen, muss die Ausfallsicherheit über redundante Hardware sichergestellt werden. Abbildung 2 zeigt eine beispielhafte Umsetzung mit drei CPUs. Zwei Safe Computing Units mit jeweils einer CPUs führen ausschließlich Safety-Anwendungen aus. Beide führen die exakt gleichen Berechnungen aus. Die beiden HW Safety Monitore synchronisieren die beiden CPUs und vergleichen die Ergebnisse der Berechnungen. Im Falle einer Abweichung der berechneten Ergebnisse wird das System in den „Failure Mode" gesetzt und wird damit inaktiv. Die 1/0 CPU und das TPM sind Teil der Peripherals und für die Security-Anwendungen verantwortlich. Nur die 1/0 CPU hat 1/0-Zugriff und kann mit der restlichen Hardware im System kommunizieren. Das TPM benötigt 1/0 und besitzt ein eindeutiges Geheimnis, aus dem die initialen Schlüssel abgeleitet werden. Des Weiteren besitzt der TPM einen echten Zufallszahlengenerator, mit Hilfe dessen weitere sichere Schlüssel erzeugt werden können. Zwei verschiedene TPMs erzeugen aus diesem Grund auch immer zwei unterschiedliche Schlüssel. Deshalb kann das TPM nicht redundant ausgelegt werden und ist direkt an die 1/0 CPU angeschlossen.

Anomalieerkennung

In den letzten Jahren konnten zunehmend Angriffe auf kritische Infrastrukturen beobachtet werden, die detailliertes Wissen des Angreifers über den Aufbau und das Verhalten des attackierten Systems voraussetzen. Solche als semantische Angriffe bezeichnete Vorfälle nutzen systemspezifische Protokolle aus, um gefährliche Zustände im gesteuerten System zu provozieren und Schaden herbeizuführen.

Semantische Angriffe auf die Eisenbahn-Signaltechnik sind das Umstellen besetzter Weichen, das Freimelden besetzter Gleisabschnitte oder das Stellen von schützenden Signalen auf Fahrt. Aus Sicht der IT-Sicherheit bieten sich für den Angreifer zahlreiche Möglichkeiten, in einer digitalisierten und vernetzten Signaltechnik solche Angriffe in die Tat umzusetzen, sollte die Infrastruktur nicht über entsprechende Schutzmaßnahmen verfügen. Die Besonderheit bei semantischen Angriffen liegt darin, dass der Angreifer Kommandos in die signaltechnische Kommunikation einschleust, die für sich betrachtet nicht ohne Weiteres von legitimen Kommandos zu unterscheiden sind. Daher versagen herkömmliche Firewalls und Transportschicht-orientierte Intrusion Detection-Systeme bei der Erkennung eines solchen Angriffs.

Eine effektive Schutzmaßnahme können allerdings Anomalieerkennungssysteme sein, die die Semantik des gesteuerten cyber-physischen Systems (hier die Signaltechnik) verstehen und so jedes Kommando in den aktuellen Kontext setzen können. Durch Berücksichtigung der komplexen Zusammenhänge in der Infrastruktur ist die Anomalieerkennung in der Lage vom Angreifer eingeschleuste, gefährliche Kommunikation zu erkennen und zu filtern. In der HASELNUSS-Architektur sind zwei Modelle integriert, um die Signaltechnik für die Anomalieerkennung abzubilden.

Das erste Modell nutzt Künstliche Neuronale Netze (KNN), die Anhand eines Trainingsdatensatzes das typische Verhalten der Infrastruktur (zum Beispiel Signale, Weichen, Gleisfreimeldung) in einem Bahnhof erlernen und darauf basierend das zukünftige Verhalten vorhersagen. Stimmt das vorhergesagte Verhalten nicht mit dem tatsächlich Beobachteten überein, kann von einer Anomalie, also einem semantischen Angriff, ausgegangen werden. Durch die Festlegung des Sehwellwertes zur Unterscheidung von Normalität und Anomalie können die Fehlerraten des Systems den jeweiligen Anforderungen angepasst werden.

Im Gegensatz zu KNN, deren Lernprozess gewissem Zufall unterworfen ist, basiert das zweite Modell auf einem deterministischen, regelbasierten Ansatz. Die Abhängigkeiten der Feldelemente aus der Stellwerkslogik werden in einem verteilten System auf den 0bject Controllern der Feldelemente abgebildet. Durch die Nutzung zusätzlicher Kommunikationskanäle zwischen den Feldelementen werden diese in die Lage versetzt, für jeden eingehenden Stellbefehl zu beurteilen, ob es sich um einen semantischen Angriff handelt.

Remote Attestation

Remote Attestation wird verwendet, um die Integrität von 0bject Controllern zu verifizieren. Dabei werden die vom Measured Boot erstellten Ereignisprotokolle über gestartete Komponenten und SK-Partitionen und der Integritätsanker im TPM mit einem nur dem TPM bekannten privaten kryptographischen Schlüssel digital signiert und zu einem Verifizierer übertragen. Dieser befindet sich in der Stellwerkeschicht, dem Maintenance and Data Management (MDM). Der Verifizierer wertet die Ereignisprotokolle aus, indem er die digitalen Signaturen des TPMs (mit dem öffentlichen Schlüssel) überprüft und die gemessenen Komponenten mit bekannten Referenzmesswerten aus einer Whitelist vergleicht. Sind die Signaturen gültig und kennt der Verifizierer alle Komponenten, dann kann davon ausgegangen werden, dass sich das Zielsystem, der Object Controller, in einem integren Zustand befindet.

Weitere Security-Anwendungen

Darüber hinaus können in den Partitionen weitere Security-Anwendungen umgesetzt werden. Dazu zählt zum Beispiel eine Firewall, die den Netzwerkverkehr auf Transportebene überwacht und gegebenenfalls auf IP-Adressen und Ports filtern kann. Außerdem kann eine Partition auch die Terminierung eines VPN-Tunnels übernehmen, sodass keine zusätzliche Hardware für solche Funktionalität aufgestellt werden muss.

Eine wesentliche Security-Anwendung dient sicheren Software-Updates. Der genutzte SK bietet die Möglichkeit, Partitionen zur Laufzeit durch andere zu ersetzen. In der HASELNUSS-Architektur basiert der sichere Update Prozess auf dem TPM. Updates werden vom MDM verschlüsselt und integritätsgeschützt, sodass nur das TPM mit den darin gespeicherten Schlüsseln die Integrität überprüfen und das Update entschlüsseln kann. Das Update wird in einer neuen Partition installiert und der Partition Loader beendet die alte und aktiviert die neue Partition, sodass bei Updates kein Neustart notwendig ist.

Authoren

• Christoph Krauß, Head of Department
• Maria Zhdanova, Research Assistant
• Michael Eckei, Research Associate, all Cyber-Physical Systems Security, Fraunhofer Institute for Secure Information Technology SIT, Darmstadt
• Stefan Katzenbeisser, Chair of Computer Engineering, University of Passau
• Markus Heinrich, Research Associate, Security Engineering, TU Darmstadt
• Don Kuzhiyelil, Research Engineer, SYSGO GmbH, Klein-Winternheim
• Jasmin Cosic, IT Security for Operational Technology and Processes
• Matthias Drodt, Head of IT Security for Operational Technology and Processes LST/TK/ATO, both DB Netz AG, Frankfurt am Main

Quellen und Literatur

[1] DIN EN 50129: Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme – Sicherheitsbezogene elektronische Systeme für Signaltechnik, 2019.

[2] CENELEC. PD CLC/TS 50701 Railway Applications - Cybersecurity, 18.09.2020.

[3] DIN VDE V 0831-104: Elektrische Bahn-Signalanlagen – Teil 104: Leitfaden für die IT-Sicherheit auf Grundlage IEC 62443.

[4] E DIN EN 50128/A1 VDE 0831-128/A1:2019-09, Bahnanwendungen, Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und Überwachungssysteme.

[5] HASELNUSS Projekt Webseite: haselnuss-projekt.de

[6] M. Heinrich, T. Vateva-Gurova, T. Arul, S. Katzenbeisser, N. Suri, H. Birkholz, A. Fuchs, C. Krauß, M. Zhdanova, D. Kuzhiyelil , S. Tverdyshev, C. Schlehuber. (2019). Security Requirements Engineering in Safety-Critical Railway Signalling Networks. Security and Communication Networks, vol. 2019, Article ID 8348925, 14 pages. doi.org/10.1155/2019/8348925

[7] DIN VDE V 0831 -200: Elektrische Bahn-Signalanlagen – Teil 200: Sicheres Übertragungsprotokoll RaSTA nach DIN EN 501 59 (VDE 0831-159).

[8] H. Birkholz, C. Krauß, M. Zhdanova, D. Kuzhiyelil, T. Arul, M. Heinrich, S. Katzenbeisser, N. Suri, T. Vateva-Gurova, C. Schlehuber. (2018). A Reference Architecture for lntegrating Safety and Security Applications on Railway Command and Control Systems. Zenodo. doi.org/10.5281/zenodo.1314095

[9] C. Schlehuber, M. Heinrich, T. Vateva-Gurova, S. Katzenbeisser, N. Suri. (2017). Challenges and approaches in securing safety-relevant railway signalling. IEEE European Symposium on Security and Privacy Workshops (EuroS&PW).

[10] S. Tverdyshev, H. Blasum, B. Langenstein et al., ,,MILS Architecture," EURO-MILS, 2013.

[11] SYSGO. Pike05 Separation Kernel. www.sysgo.com

Copyright

All Rights reserved. Copyright Bahn Fachverlag GmbH

Deine Bahn 12/2020