Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Wie realisiert man vernetzte sicherheitskritische Systeme?

Autor: Markus Maier, Assystem Germany

Beitrag - Embedded Software Engineering Kongress 2018

 

Ob Analyse von Prozessdaten oder einfach nur die effiziente Umsetzung von Software-Updates im Feld: Neue Geschäftsmodelle erfordern zunehmend die Öffnung einst abgeschotteter sicherheitskritischer Steuerungssysteme. Assystem zeigt einen systematischen Weg der Entwicklung sicherheitsbezogener vernetzter Systeme am Beispiel einer Antriebssteuerung unter Einhaltung der für den Anwendungsfall relevanten Security- & Safety-Standards.

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.

Abbildung 1 (s. PDF) zeigt unser Anwendungsbeispiel eines vernetzten E-Antrieb-Controllers, der unter anderem in Wasserkraftwerken und leistungsstarken Maschinen eingesetzt wird.

Das zu betrachtende System (SuC) unseres 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 SW-Update und die Analyse der Prozessdaten. Relevante Standards in diesem Umfeld sind vor allem IEC62443,  IEC61508,  ISO13849, EN62061 und IEC61800-5.

Safety & Security Prozess

Figure 2 (s. PDF) 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 Figure 3 (s. PDF) und des Prozesses "Security Lifecycle" nach NIST-Standard ist in Figure 4 (s. s. PDF) 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 Figure 2 (s. PDF) 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 HighLevel 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. Table 1, s. PDF).

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 Figure 5, s. PDF). 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 Table 2 (s. PDF).

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.

Figure 6 (s. PDF) 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. Table 1, PDF).

Anschließend wird eine Systemarchitektur für das zu betrachtende Systems (SuC) durch Anwendung des "Defense in Depth" Prinzips entworfen. Dabei wird das System in sogenannte Sicherheits-Zonen 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 Ablage-Orts oder der Zugangsberechtigung (vgl. IEC62443-3-2).

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

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.

 

Quellen

z.B. Stuxnet, Triton Malware oder Ähnliches

Autor

Markus Maier ist Team- und Projektmanager bei der Assystem Germany GmbH. Er 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.

 

Beitrag als PDF-Datei herunterladen

Architektur & Design - MicroConsult Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Architektur & Design /Embedded- und Echtzeit-Softwareentwicklung.

 

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.


Architektur & Design - Fachwissen

Wertvolles Fachwissen zum Thema Architektur & Design /Embedded- und Echtzeit-Softwareentwicklung steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.

Ob Analyse von Prozessdaten oder einfach nur die effiziente Umsetzung von Software Updates im Feld: Neue Geschäftsmodelle erfordern zunehmend die Öffnung einst abgeschotteter sicherheitskritischer Steuerungssysteme. Assystem zeigt einen systematischen Weg der Entwicklung sicherheitsbezogener vernetzter Systeme am Beispiel einer Antriebssteuerung unter Einhaltung der für den Anwendungsfall relevanten Security- & Safety-Standards.

 

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.

 

Abbildung 1 zeigt unser Anwendungsbeispiel eines vernetzten E-Antrieb Controllers, der unter Anderem in Wasserkraftwerken und leistungsstarken Maschinen eingesetzt wird.

 

Figure 1 - Anwendungsbeispiel: vernetzter E-Antrieb Controller

 

Das zu betrachtende System (SuC) unseres 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 SW Update und die Analyse der Prozessdaten. Relevante Standards in diesem Umfeld sind vor allem IEC62443,  IEC61508,  ISO13849, EN62061 und IEC61800-5.

 

 

Safety & Security Prozess

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

 

 

 

Figure 2 - Safety & Security Lifecycle Prozess

 

 

 

Figure 3 - Prozess Risk Assessment & Top Down Design nach IEC62443-3-2

 

 

Figure 4 - Security Lifecycle nach NIST Standard

 

Das Mapping des Prozesses für den Top Down Entwurf  nach IEC62443-3-2 ist in Figure 3 und des Prozesses „Security Lifecycle“ nach NIST Standard ist in Figure 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 Figure 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. Table 1).

 

 

Table 1 - Beispiel einer High Level Risiko Analyse

 

 

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

 

 

Figure 5 - Risikoeinstufung

 

 

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 Table 2.