Professional Articles

IoT-Ansätze sind deshalb so erfolgreich, weil offene Standards und offene Protokolle es ermöglichen, eingebettete, handelsübliche Komponenten in vergleichsweise loser Form miteinander zu verbinden. Dieser Grad der Modularität spiegelt sich auch in den Zertifizierungsstandards wider. In diesem Artikel zeigen wir, wo und wie ein komponentenbasiertes Softwaredesign die Erfüllung von Zertifizierungsanforderungen deutlich erleichtern kann.

Im Internet der Dinge wird die klassische IT-Sicherheit zunehmend auf eingebettete Komponenten ausgeweitet. Ein Merkmal der Sicherheitsanforderungen, das viele IoT-Systeme gemeinsam haben, ist, dass Integrität und Verfügbarkeit wesentliche Schwerpunkte sind. Dies lässt sich auch an den Zertifizierungsstandards ablesen: Die klassischen Common Criteria for Information Technology Security (ISO 15408) werden ergänzt durch domänenspezifische Sicherheitsstandards wie IEC 62443 für Industrial Control Systems, EDSA (Embedded Device Security Analysis) oder J3061 im Automotive-Bereich, die alle einen starken Fokus auf "Security for Safety" haben.

Das Internet der Dinge (IoT) ist extrem vielfältig, hochdynamisch und immer verfügbar - und damit immer anfällig für Angriffe. Das IoT besteht aus IoT-Komponenten als modularen Elementen (siehe auch I. Yaqoob, E. Ahmed, I. Hashem, A. Ahmed, A. Gani, M. Imran und M. Guizani, "Internet of Things Architecture: Recent Advances, Taxonomy, Requirements, and Open Challenges").

Abbildung 1: Vereinfachte Darstellung eines Sicherheitsmodells nach Common Criteria und IEC 62443

Abbildung 2: Sicherheitsmodell CC und IEC 62443 mit zwei Assets

Abbildung 3: Die beiden Anlagen aus dem in Abb. 2 gezeigten Beispiel auf einem MILS-System

Auch die Sicherheit ist tendenziell modular

Abbildung 1 zeigt das Sicherheitsmodell nach Teil 1 der Common Criteria (CC) (Abschnitt 7.1) (PDF), das auch explizit in der IEC 62443-1-1 (Abschnitt 5.1) enthalten ist. Diese Abbildung zeigt alle Assets, Bedrohungen und Gegenmaßnahmen als einzelne Kästchen. Nach unserer Erfahrung zeigt sich jedoch bei näherer Betrachtung, dass die Situation oft eher der in Abbildung 2 dargestellten entspricht. Die folgende Tabelle zeigt ein Beispiel für eine mögliche Aufteilung mit zwei Assets:

In dem oben gezeigten Beispiel sind die Werte und deren Bedrohungen von sehr unterschiedlicher Kritikalität. Die spezifische Zuordnung in Abbildung 2 macht auch deutlich, dass eine zusätzliche Bedrohung besteht, nämlich dass der Angreifer versuchen könnte, die Gegenmaßnahmen zu umgehen ("will try to bypass"), z. B. könnte der Ethernet-Zugriff auf den Leistungslogger missbraucht werden, um die Motorsteuerung anzugreifen. Eine Möglichkeit, komplexe IT-Systeme und insbesondere IoT-Komponenten mit unterschiedlichem Kritikalitätsgrad auf einer angemessenen Abstraktionsebene zu regeln, besteht darin, sie in Sicherheitsdomänen zu unterteilen ("Teile und herrsche"). Eine Sicherheitsdomäne ist eine Zone, in der alle Objekte der gleichen Sicherheitsrichtlinie unterliegen. Die Grenzen von Sicherheitsdomänen werden auch als "Vertrauensgrenzen" bezeichnet.

Aufbau einer Sicherheitsarchitektur für die Common Criteria Zertifizierung

Bei den Common Criteria for Information Technology Security Evaluation (CC) arbeitet ein Hersteller mit einer Prüfstelle zusammen, um ein vom Hersteller vorgelegtes IT-Produkt zu bewerten. Das Produkt kann aus Software oder sowohl Software als auch aus Hardware bestehen und schließt damit explizit IoT-Komponenten ein. Ist die Bewertung erfolgreich, stellt die Zertifizierungsstelle, in Deutschland das Bundesamt für Informationstechnik (BSI), ein Zertifikat aus.

Die Common Criteria verlangt vom Entwickler als zentralen Bestandteil der bei der prüfenden Stelle einzureichenden Dokumentation eine Entwurfsdokumentation, in der das Produkt je nach gewünschter Evaluierungsstufe in Teilsysteme (einstufig) oder Teilsysteme und Module (zweistufig) aufgeschlüsselt werden muss. Die Eigenschaften von Teilsystemen und Modulen und ihre Wechselwirkungen müssen beschrieben werden. In der Entwurfsdokumentation wird auch beschrieben, inwieweit die Schnittstellen der Subsysteme und Module für Angreifer direkt oder indirekt zugänglich sind.

Eine Sicherheitsarchitektur ist ein Mittel zur Analyse und Dokumentation der Sicherheitseigenschaften eines Systems im Hinblick auf seine Sicherheitsdomänen.

Eine Sicherheitsarchitektur (ADV_ARC) nach den Common Criteria gibt Aufschluss über die folgenden Punkte:

• Über welche Sicherheitsdomänen verfügt das System? Inwieweit sind diese Sicherheitsdomänen vollständig voneinander getrennt, oder können sie (kontrolliert) miteinander kommunizieren? In unserem Beispiel waren der Leistungslogger und die Motorsteuerung unterschiedliche Domänen.
• Wie wird das System initialisiert?
• Wie schützt sich das System selbst gegen Angriffsversuche von Angreifern?
• Wie schützt das System vor Versuchen, es zu umgehen (in unserem Beispiel: Der Web-Zugriff auf den Leistungsprotokollierer kann die Motorsteuerung nicht umgehen)?

Sicherheitsarchitektur nach IEC 62443

IEC 62443 ist eine Norm für die Sicherheit von industriellen Steuerungssystemen als Ganzes (insbesondere Teile 3-1 bis 3-3) und deren Komponenten (insbesondere Teile 4-1 und 4-2). Die IEC 62443 wird von der Sicherheitsnorm IEC 61508 für die IT-Sicherheit referenziert (IEC 61508 Teil 1-1 Abschnitt 7.5.2.2: "Wenn IT-Sicherheitsbedrohungen identifiziert worden sind, muss eine Schwachstellenanalyse durchgeführt werden, um die Sicherheitsanforderungen zu ermitteln. Anmerkung: Eine Anleitung dazu ist in der Reihe 62443 enthalten"). Die IEC 62443 befindet sich zu einem großen Teil noch in der (fortgeschrittenen) Entwicklung durch IsaSecure.

In der IEC 62443 werden die IT-Sicherheitsdomänen als "Zonen" bezeichnet, und das System sollte die Partitionierung in Zonen unterstützen (IEC 62443 Teil 3-3 Abschnitt SR 5.4) und ein Ressourcenmanagement betreiben, das gut gegen Angreifer geschützt ist (IEC 62443 Teil 3-3 Abschnitte SR 7.1 und SR 7.2 und IEC Teil 4-2 Abschnitte CR 7.1 und CR 7.2), einschließlich des Schutzes gegen z. B. Denial-of-Service-Angriffe.

Im Hinblick auf den Entwicklungsprozess verlangt IEC 62443 Teil 4-1 SR-2 die Erstellung eines Bedrohungsmodells mit Vertrauensgrenzen, das auch regelt, wie Informationen über diese Vertrauensgrenzen hinweg fließen. Es wird ein Defense-in-Depth-Design empfohlen (IEC 62443 Teil 4-2 SD-2). IEC 62443 Teil 4-1 SD-6 fordert außerdem, dass eines der Entwurfsziele des Systems die Minimierung der Angriffsfläche sein muss.

Sicherheitsarchitektur in Übereinstimmung mit IsaSecure EDSA/SDLA/SSA

Mit den Standards SDLA (Prozesse), EDSA (funktionale Systeme für Komponenten) und SSA (funktionale Anforderungen für Gesamtsysteme) hat IsaSecure ein präzises Zertifizierungsschema für die IEC 62443-Serie entwickelt, das auch Anregungen aus NIST 800-53 enthält. So enthält EDSA-311 die in der nachstehenden Tabelle aufgeführten Anforderungen an die funktionale Ebene:

IACS = Integrated Administration and Control System (Integriertes Verwaltungs- und Kontrollsystem)

Genau wie in IEC 62443 Teil 4-1 erfordert SDLA-312 einen modularen Aufbau auf Prozessebene (SDLA-DSD-1.*) und eine klare Identifizierung von Vertrauensgrenzen und Angriffsflächen (SDLA-SAD-*).

Sicherheitsarchitektur in J3061

Die von der SAE veröffentlichte Norm J3061 ist die jüngste der von uns berücksichtigten Normen, und die Version, auf die wir uns beziehen, ist der im Jahr 2016 veröffentlichte Entwurf. In dieser Norm beginnt die Erstellung der Softwarearchitektur mit der "Verfeinerung des funktionalen Cybersicherheitskonzepts in ein technisches Cybersicherheitskonzept" (Abschnitt 8.4.3), und dabei ist wiederum die Isolierung bestimmter Funktionen wichtig. Als Beispiel wird folgendes angeführt: "Isolierung/Partitionierung von Systemen, die von außen zugänglich sind (z. B. Wi-Fi, Bluetooth, OBD), von sicherheitskritischen Systemen und Systemen, die wichtige Auswirkungen auf den Betrieb des Fahrzeugs haben können." Die Softwarearchitektur wird dann einer Bedrohungsanalyse hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit unterzogen (Abschnitt 8.6.3) und auf Schwachstellen und Bedrohungen untersucht. In Abschnitt 8.6.4 werden STRIDE, ASF und DREAD als mögliche Werkzeuge zur Unterstützung bei der Bedrohungskategorisierung genannt.

Gemeinsame Merkmale und Ausblick

Bei der Betrachtung der Anforderungen an die Softwarearchitektur haben wir uns in erster Linie auf die Sicherheitsarchitektur auf dem linken Ast des V-Modells beschränkt. Es liegt auf der Hand, dass die Einhaltung dieser Anforderungen nicht nur den Entwurfsprozess, sondern auch das Testen und die Schwachstellenanalyse vereinfacht.

Wir haben festgestellt, dass alle von uns untersuchten Normen, die für das IoT relevant sind (Common Criteria/ISO 15408, IEC 62443, EDSA/SDLA/SSA und J3061), eine Sicherheitsarchitektur erfordern, die Isolierung, Ressourcenmanagement und Informationsflusskontrolle zwischen Sicherheitsdomänen (auch als "Zonen" oder "Partitionen" bezeichnet) bietet.

Unter Berücksichtigung des Materialverbrauchs (z.B. eine Kontrolleinheit pro Sicherheitsdomäne) erscheint eine solche Architektur mit klarer, umgehungssicherer Aufgabentrennung auf den ersten Blick aufwendiger. Der Materialverbrauch kann jedoch durch Virtualisierung wie folgt gesteuert werden:

• Im Hinblick auf die Netzwerkvirtualisierung sind vor allem Neuentwicklungen bei lastverteilten Echtzeitnetzwerkstandards interessant (z.B. TSN, IEEE 802.1 Qbu/Qbv), da diese eine sichere Trennung der Verkabelung ermöglichen.
• Im Bereich der CPU-Virtualisierung hat sich in den letzten Jahren das aus dem sicherheits- und materialsensitiven Avionikbereich stammende MILS-Konzept zunehmend durchgesetzt.

In einem MILS-System würde das eingangs in Abbildung 2 gezeigte Beispiel wie in Abbildung 3 dargestellt aussehen.

Bei der Implementierung eines MILS-Systems, wie in Abbildung 3 dargestellt, werden die Isolierung, die Ressourcenverwaltung und die Kontrolle des Informationsflusses, wie sie von den Common Criteria, IEC 62443, EDSA und J3061 gefordert werden, von einem Separationskernel bereitgestellt. Die von einem Separationskernel geschaffenen Partitionen bilden die Grundlage für IT-Sicherheitsdomänen in IoT-Geräten, die eine MILS-Architektur verwenden.