Wie realisiert man vernetzte sicherheitskritische Systeme?

Ob Analyse von Prozessdaten oder effiziente Umsetzung von Software-Updates im Feld: Das IoT-Zeitalter verspricht eine bessere Nutzung von Steuergeräten, erfordert aber auch die Öffnung einst abgeschotteter sicherheitskritischer Systeme. Wie lässt sich ein sicherheitsbezogenes, vernetztes unter Einhaltung relevanten Security- & Safety-Standards realisieren?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

MHP Management- und IT-Beratung GmbH

Parasoft® Deutschland GmbH

Assystem GmbH

In der Automatisierungstechnik vollzieht sich seit einigen Jahren ein Wandel hin zu modularen, vernetzten Systemen. Im Zuge dessen wird Cybersicherheit zur unabdingbaren Voraussetzung für funktional sicherheitskritische Systeme. Erst Anfang des Jahres 2018 zeigte der Triton-Malware-Angriff auf eine Industrieanlage im Nahen Osten, wie verwundbar aktuelle sicherheitskritische, industrielle Steuerungssysteme sind.

Bild 1 zeigt das Anwendungsbeispiel eines vernetzten E-Antrieb-Controllers, der unter anderem in Wasserkraftwerken und leistungsstarken Maschinen eingesetzt wird.

Bildergalerie

Bildergalerie mit 9 Bildern

Das zu betrachtende System (SuC) des Anwendungsbeispiels regelt die Steuerung eines E-Motors und ist mit einer Backend-/Cloud-Infrastruktur vernetzt. Dies ermöglicht einerseits die Überwachung des Steuerungsprozesses und andererseits auch Updates nicht funktional sicherheitsbezogener Software-Anteile.

Die zentrale Safety-Funktion für den Antrieb ist die sogenannte Safe-Torque-Off-Funktion (STO), die in Bezug auf Cybersicherheit besonders geschützt werden muss. Weitere zu schützende Funktionen sind beispielsweise die E-Motor-Regelung, der Maschinenstatus, die Diagnose, das Software-Update und die Analyse der Prozessdaten. Relevante Standards in diesem Umfeld sind vor allem IEC62443, IEC61508, ISO13849, EN62061 und IEC61800-5.

Safety & Security Prozess

Bild 2 zeigt den von Assystem für das Anwendungsbeispiel angewendeten Lifecycle Prozess für sicherheitskritische Systeme.

Das Mapping des Prozesses für den Top-Down-Entwurf nach IEC62443-3-2 ist in Bild 3 und des Prozesses „Security Lifecycle“ nach NIST Standard in Bild 4 dargestellt. Damit ergibt sich ein generischer Entwicklungs- und Wartungsprozess, der sowohl zu relevanten Safety-Standards als auch zu den relevanten Security-Standards kompatibel ist.

Die Entwicklungsphase des Lifecycle Prozesses (Bild 2) ist in den Bereiche „Design“, „Realisierung“ und „Admin“ gegliedert. Der Bereich „Betrieb“ stellt die operative Phase dar. Für jeden Block sind entsprechende Input-/Output Artefakte, Verantwortlichkeiten bzw. Rollen und Aktivitäten beschrieben.

Entscheidend ist, dass die Safety-bezogene Systementwicklung von der Security-bezogenen Systementwicklung ab Phase P4.1 durch geeignete Systempartitionierung unabhängig erfolgen kann.

Security-Risikoanalyse – Methodik & Normen am Beispiel

Nach Definition des „System under Consideration“ (SuC) wird eine High Level Risikoanalyse für wesentliche Schützgüter (Assets) des SuC durchgeführt unter Berücksichtigung der physischen Schnittstellen, Stakeholder und der Use-Cases in der geplanten Systemumgebung (vgl. Tabelle 1).

Dabei werden potentielle Bedrohungen, Schwachstellen und Auswirkungen im Falle eines Exploits je Assetgruppe analysiert. Bedrohungen und Schwachstellen wird zunächst qualitativ eine Wahrscheinlichkeit zugeordnet. Der potentielle Schaden (Auswirkung) wird ebenfalls qualitativ abgeschätzt. Die qualitativen Werte der Wahrscheinlichkeit und des Schadens müssen vor Erstellung der Risikoanalyse definiert werden (vgl. Rationale in Bild 5). Beispielsweise wird eine Manipulation der Safety-Funktion als katastrophal eingestuft und die Bestimmung der Wahrscheinlichkeit wird in Relation zur Anzahl der Controller im Feld und einer Zeitspanne gesetzt.

Daraus ergibt sich im ersten Schritt ein qualitatives Risiko je Assetgruppe. Je Assetgruppe werden dann Foundational Requirements (FRs) festgelegt zur Risikoreduktion. Den Foundational Requirements wird ein sogenannter Ziel-Security-Level (SL-T) zugeordnet gemäß Definition in Tabelle 2.

Safety-Konzept und Architektur

Die zentrale Safety-Funktion des Antriebscontrollers ist die sogenannte Safe-Torque-Off-(STO)-Funktion, die eine sichere Abschaltung des Drehmoments gewährleistet.

Bild 6 zeigt die zweikanalige Architektur der STO-Funktion vom Eingang bis zum Ausgang. Dadurch erfüllt die STO die Anforderungen der ISO13849 für PLe und der Normen IEC61508, IEC61800-5 für SIL3. Für den Sicherheitsnachweis wird der Diagnosepfad zur Überwachung der STO-Hardware-Pfade separat betrachtet. Dabei wurde die Diagnose der STO-Hardware-Pfade einen SI Level niedriger eingestuft als die eigentliche STO-Funktion und erfüllt die Anforderungen nach IEC61508 für den SIL 2.

Da der FPGA-Hersteller keine quantitativen Fehleranalysen zur Verfügung stellt, wurde die Diagnosefunktion durch zwei unabhängige Pfade im FPGA realisiert. Durch zusätzliche Maßnahmen zur Erkennung bzw. Vermeidung von Common-Cause-Fehlern wie zu hohe oder zu niedrige Umgebungstemperatur, Versorgungsspannung, Taktung und EMV, können Einzelfehler im FPGA nicht zum Ausfall der Diagnosefunktion führen. Zusätzlich wird eine quantitativ nachweisbare hohe Safe Failure Fraction (SFF nach IEC61508) möglich.

Security-Konzept, Anforderungen und Architektur

Ergebnis der High-Level-Risikoanalyse auf Systemebene ist die Ableitung von Foundational Requirements (FRs) je Asset anhand der Bedrohungsszenarios. Für die einzelnen Foundational Requirements auf Systemebene wird dabei ein Ziel-Security-Level (SL-T) entsprechend dem erforderlichen Sicherheitsniveau festgelegt (vgl. Tabelle 1).

Anschließend wird eine Systemarchitektur für das zu betrachtende System (SuC) durch Anwendung des „Defense in Depth“-Prinzips entworfen. Dabei wird das System in sogenannte Sicherheitszonen und Conduits aufgeteilt. Die Aufteilung in Zonen und Conduits kann sowohl physisch als auch logisch (in Software) erfolgen und die Gruppierung erfolgt beispielsweise anhand der Kritikalität der Assets, der Funktion, des physischen / logischen Ablageorts oder der Zugangsberechtigung (vgl. IEC62443-3-2).

Durch den Prozess der strukturierten Risikoanalyse und Top Down Designs (vgl. Bild 3) erhält man für das Gesamtsystem (SuC) durch Anwendung des „Defense in Depth“-Prinzips eine Aufteilung in physische und logische Sicherheitszonen (Bild 7 und Bild 8).

Jede Zone beinhaltet ein oder mehrere Systeme, die wiederum aus elementaren Komponenten bestehen. Zonen wird dabei ein bestimmter Security oder Trust Level inklusive der Foundational Requirements zugeordnet und jede Zone stellt nur die wirklich relevanten Schnittstellen nach Außen, d.h. für andere Zonen zur Verfügung. Zwischen den Zonen erfolgt in der Regel eine Authentifizierung, Verschlüsselung und Begrenzung des Datenflusses. Eingangsdaten sollten vor interner Verwendung immer validiert und Ausgangsdaten vor Ausgabe nach Möglichkeit bereinigt werden, so dass keine kritischen Informationen nach Außen preisgegeben werden.

Zusammenfassung und Ausblick

Zusammenfassend ergeben sich durch die dargestellte methodische Vorgehensweise für unser Anwendungsbeispiel zahlreiche Vorteile für Systemintegratoren und Anlagenbetreiber. Der Controller kann durch den damit erreichten hohen Sicherheitslevel und der Zertifizierung in eine Vielzahl von Anwendungen zur Ansteuerung leistungsstarker E-Motoren integriert werden. Die sichere Cloud-/Backend-Anbindung ermöglicht die Vernetzung der Steuerung zur Prozessdatenanalyse sowie einfache und sichere Updates im Feld für Non-Safety-Funktionen. Zusätzlich kann der Controller durch das modulare Design für den jeweiligen Bedarf skaliert werden.

Systemarchitekturen für sicherheitskritische Systeme

7 Security-Grundlagen für vernetzte und autonome Fahrzeuge

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

Der Autor

* Markus Maier verfügt über langjährige Erfahrung in der Entwicklung funktional sicherheitskritischer Systeme in der Automobil- und Industrie-Branche und beschäftigt sich seit einigen Jahren intensiv mit dem Thema Cyber-Sicherheit, insbesondere mit der Härtung von Embedded Systemen und industriellen Steuerungen.

(ID:45824644)