Separation-Kernel-Technik auch für industrielle Anwendungen

Angriffe auf Industrieinfrastrukturen aus dem Netz nehmen immer mehr zu. So benutzten Hacker etwa im November 2011 gestohlene Passwörter, um auf das SCADA-System (Supervisory Control And Data Acquisition) einer Wasserversorgung  zuzugreifen. Eine Pumpe, die tausende Haushalte einer Stadt im US-Bundesstaat Illinois mit Wasser versorgt, wurde dadurch zerstört, dass sie in kurzen Abständen an- und wieder abgeschaltet wurde.

Ende 2014 wurde ein deutsches Stahlwerk Opfer einer ähnlichen Cyber-Attacke, als Hacker erfolgreich ein SCADA-Softwaresystem übernahmen und dem Standort erheblichen Schaden zufügten. Die Angreifer hackten sich erst in das Bürosoftwarenetzwerk des Industriebetriebs ein und nutzten dies dann, um zur Produktionsmanagement-Software des Stahlwerks vorzudringen. Von dort aus übernahmen sie fast alle Steuerungssysteme, um dann systematisch Mensch-Maschine-Schnittstellen (HMI-Komponenten) zu zerstören. Erfolgreich verhinderten sie, dass ein Hochofen seine Sicherheitseinstellungen rechtzeitig änderte und verursachten dadurch schwere Schäden an der Infrastruktur.

Anderenorts scheinen Cyber-Angriffe eher politisch motiviert zu sein. Am 23. Dezember 2015 fand ein Angriff auf ein ukrainisches SCADA-System statt, um 17 Umspannwerke vom Strom abzuschalten und auch die Telefonleitungen des Unternehmens so zu behindern, dass diese die Stromversorgung nur mit Verzögerung wiederherstellen konnten. Schon Monate vor der Stromabschaltung hatten die Angreifer Phishing-Mails an Stromversorgungsunternehmen in der Ukraine geschickt. Einmal geöffnet, war die Malware installiert. Firewalls wurden daraufhin entwickelt, um die befallenen Computer von den Steuerungssystemen zu separieren. Doch erlaubte die Malware – bekannt als BlackEnergy 3 – den Hackern, Zugangsdaten anzusammeln, mit denen sie das eigentliche SCADA-System selbst angreifen konnten.

Diese Beispiele für Cyber-Angriffe auf sicherheitskritische Infrastrukturen haben alle eines gemeinsam: einen nicht ausreichend geschützten Zugangsweg vom Internet zu einer sicherheitskritischen Domain.

Interoperabilität mit Safety und Security

Nun ist es nicht so, dass die Hersteller solcher Systeme nicht in der Lage wären, ein prinzipiell interoperables, betriebs- und angriffssicheres Netz im industriellen Bereich zu entwickeln und einzusetzen. Vor allem das Industrial Internet Consortium (IIC) und die Arbeitsgruppe Industrie 4.0, haben mit der Industrial Internet Reference Architecture (IIRA) beziehungsweise dem Reference Architectural Model for Industrie 4.0 (RAMI 4.0) entsprechende Richtlinien und Empfehlungen erarbeitet. Angesichts der Ähnlichkeit dieser zweier Rahmenwerke gibt es natürlich Gemeinsamkeiten und Überlappungen. Diese zeigen sich auch in den derzeitigen lebhaften Diskussionen zur Kooperation zwischen den beiden Organisationen. So hat das IIC erst kürzlich das Industrial Internet Security Framework (IISF) vorgestellt, das dafür als Orientierungshilfe dienen soll.

Bild 1: Das Referenzarchitekturmodell für Industrie 4.0 (RAMI 4.0). Lynx

Was die Sicherheit herausfordert, lässt sich anhand einer fiktiven Produktionsanlage mit vielen Ansprüchen an die Infrastrukturen ihrer diversen Systeme erläutern. Sensoren können dort fast in Echtzeit Daten hinsichtlich Standort, Position, Geschwindigkeit, Temperatur, Druck, Sperrstatus und Vibration bereitstellen. Selbst bei einem höheren Sicherheitsniveau lassen sich noch die Einstellungen der Anlage und sogar die Firmware aus der Ferne aktualisieren. Bild 1 zeigt, wie RAMI 4.0 solche Überlegungen in eine dreidimensionale Matrix aus Schichten, einem „Life Cycle & Value Stream“ und Hierarchieebenen abstrahiert. Dies ähnelt auffällig den „Functional Domains“ und „Viewpoints“ des IIC-IIRA-Modells (Bild 2).

Bild 2: Darstellung der sogenannten Functional Domains und Viewpoints laut den Vorgaben des Industrial Internet Consortium (IIC). Lynx

Um zu verstehen, wie eine gesicherte Basis für das eine wie das andere Konzept am besten bereitgestellt werden kann, ist es hilfreich sich zu vergegenwärtigen, dass beide Konzepte ein Zusammengehen zweier bislang meist getrennter Welten darstellen: die Informationstechnik (IT) und die Operationstechnik (OT). Traditionelle OT beinhaltet Sicherheit quasi eingebaut durch Isolierung. IT fokussiert Sicherheit auf den Schutz von Unternehmens-Assets. Die Verbindung beider Welten stellt ihre Sicherheit auf den Prüfstand, da sie jeweils neue Angriffsflächen schafft.

Daher ist klar, dass – ungeachtet der Unterschiede und Gemeinsamkeiten zwischen beiden Architekturen – die Isolierung einer Domäne von der anderen ein Schlüsselkriterium für den Schutz vor Hackern ist. Vor allem bei die Separierung der Daten kommt es darauf an, dass jeweils nur Befugte Zugriff haben.

Damit die unterschiedlichen Datenquellen nicht beeinträchtigt werden, muss die zugrundeliegende Basis des Industrial Internet of Things (IIoT) einerseits dafür sorgen, dass die OT ihr bestehendes Niveau hinsichtlich Betriebssicherheit, Belastbarkeit und Zuverlässigkeit beibehält, andererseits aber auch den Grad an Datenschutz und Datensicherheit erhöht, um die IT-Komponente zu schützen. Umgekehrt wird die IT-Seite – zusätzlich zu ihrer vorbildlichen Leistung in Sachen Datenschutz, Datensicherheit und Zuverlässigkeit – für eine bessere Belastbarkeit und Betriebssicherheit sorgen müssen.

All dies wäre erreichbar, würden die miteinander verbundenen Systeme von Anfang an in Hinblick auf Konnektivität konzipiert. Das ist aber ganz eindeutig nicht praktikabel. Der bessere Vorschlag ist also, die eigentlichen Endpunkte selbst zu schützen. Und zwar mithilfe eines Gateways, der auf einem Separation Kernel basiert.

Separation Kernel

Auch wenn ein solcher Ansatz auf Prinzipien beruht, die dem industriellen Sektor vielleicht neu sein mögen – andernorts gelten sie längst. Separation Kernels schützen beispielsweise seit fast einem Jahrzehnt Verschlusssachen in staatlichen Kommunikationssystemen. Es lohnt sich also durchaus, sich die angewandten akademischen Prinzipien anzusehen, die dem Separation Kernel zu einem solchen Erfolg verholfen haben.

Das Konzept eines Separation Kernels wurde erstmals 1981 von John Rushby  diskutiert, der eine Kombination aus Hardware und Software vorschlug, welche die Ausführung mehrerer Funktionen auf einer gemeinsamen physischen Plattform erlaubt ohne sich gegenseitig zu behindern. Diese Argumentation bildet die Grundlage der Initiative „Multiple Independent Levels of Security“ (MILS). MILS forciert den Zusammenschluss von Komponenten und Subsystemen zu Einheiten, die klein genug sind, um einer genauen Prüfung unterzogen werden zu können.

Ebenfalls führten bereits vor 30 Jahren Saltzer und Schroeder  aus, dass „jedes Programm und jeder Benutzer nur die Rechte erhält, die zur Erfüllung der jeweiligen Aufgaben absolut erforderlich sind”. Dieser simple und vernünftige Ansatz der geringstmöglichen Privilegien (Least Privilege) wird dringend notwendig, wenn Anwendungen unterschiedlicher Kritikalität in unmittelbarer Nähe zueinander ausgeführt werden.

Die Konzepte von Separation Kernel und Least Privilege konzentrieren sich daher beide auf die Vorzüge der Modularisierung, wobei ersteres auf die Ressourcen und letzteres auf die Systemfunktionen gerichtet ist – ein Punkt, der den Autoren Levin, Irvine und Nguyen in ihrer Schrift „Least Privilege in Separation Kernels“ nicht entgangen ist, in der sie eine Mischung beider Konzepte vorschlugen.

Bild 3: Die Überlagerung der Separation-Kernel-Blöcke mit Least-Privilege-Prinzipien ergibt eine feinere Granularität pro Subject (ausführbare Einheit). Lynx

Bild 3 zeigt die „Subjects“ (aktive, ausführbare Einheiten) mit den wenigsten/ geringsten Rechten und „Ressources“, die über die Separation-Kernel-Blocks gelegt sind. Wo der Separation Kernel die Granularität der Flusskontrolle je Subjekt und je Ressource unterstützt, werden weit weniger unerwünschte Kontrollflüsse zugelassen, als wenn die Flusskontrolle jeweils per Block verwaltet werden würde.

Hardware-Virtualisierung

Auch wenn die Prinzipien von Separation Kernel und Least Privilege inzwischen längst etabliert sind, beruhten frühe Implementierungsversuche auf einer Software-Virtualisierungsschicht mit generell fragwürdiger Leistung, weswegen Echtzeitanwendungen nicht unterstützt werden konnten.

Der überwältigende Erfolg der Virtualisierung auf Unternehmensebene ist zu verdanken, dass Halbleiterhersteller die Anzahl der Cores pro CPU immer weiter erhöhten und ihre Hardware mit ausgeklügelter Virtualisierungsunterstützung versahen. So wurde aus der theoretischen Idee eines Separation Kernel eine auch in der Praxis nutzbare Option.

Auf dem Markt sind mehrere Embedded-Hypervisoren auf Basis einer modifizierten Betriebssystemarchitektur erhältlich, die ähnliche Ziele erreichen wollen. Doch damit ein Separation Kernel optimale Sicherheitsreferenzen aufweisen kann, muss er Least-Privilege-Prinzipien anwenden, um die Angriffsfläche zu minimieren.

Praxistauglichkeit eines Separation Kernels

Bild 4: Vereinfachtes Schema einer praktischen Separation-Kernel-Anwendung. Lynx

Ein konkretes Beispiel ist in Bild 4 beschrieben. Dort ist eine Drehmaschine abgebildet, die Produktionsdaten generiert. Diese Daten wiederum sollen aber über die Cloud geteilt werden, beispielsweise auf Abruf durch einen Betriebsingenieur.

Die der Cloud zugewandte Komponente in diesem Beispiel kann auf einem Allzweckbetriebssystem wie Windows oder Linux basieren. Bei solchen Systemen werden immer wieder Sicherheitslücken entdeckt. Wichtig ist, dass Hacker nicht auf die der Betriebsstätte zugewandten Komponente auf Basis eines Echtzeitbetriebssystem oder einer Bare-Metal-Anwendung zugreifen kann, selbst wenn die in Richtung Cloud gerichtete Komponente beeinträchtigt wird.

Ein Separation Kernel, der im Einklang mit Least Privilege-Prinzipien implementiert ist, wird folgende Schlüsseleigenschaften aufweisen, die für ein solches Szenario optimal sind:

• Schnell: Um bestmögliche Performance zu erreichen, darf der Separation Kernel so wenig Overhead wie möglich mit sich bringen und sollte so effizient wie möglich auf die hardwareunterstützten Virtualisierungsfunktionen zurückgreifen.
• Klein: Wenn Betriebssystemfunktionen wie Treiber, Ein-/Ausgänge sowie Prozessverwaltung durch andere Komponenten gehandhabt werden, wird der Separation Kernel selbst sehr viel kleiner ausfallen und dadurch weniger Angriffsfläche bieten.
• Praktisch: Der Separation Kernel unterstützt die Wiederverwendung bestehender Software, indem er ein „virtuelles Motherboard“ präsentiert, auf dem sich die einzelnen Subjects installieren und ausführen lassen, als befänden sie sich in einer nativen Installation.
• Sicher: Statische Konfiguration sorgt dafür, dass der Separation Kernel, einmal entwickelt und implementiert, unveränderlich ist und über eine kleinstmögliche Angriffsoberfläche verfügt.

Verbesserte Verteidigungsstrategien

Die bekannte Stuxnet-Attacke zeigt anschaulich, wie sich Separation-Kernel-Technologie in einer kritischen Infrastruktur einsetzen lässt. Die Ziele von Stuxnet waren erst Infektion und dann Manipulation des Siemens Programmable Logic Controllers (PLCs) – ein Embedded-Computer-Systems, das die Geschwindigkeit der Turbinen, welche Uran durch eine unglaublich hohe Drehzahl anreichern, steuert und überwacht. Diese Computersysteme waren jedoch nicht direkt an das Internet angeschlossen. So wurde ein ausgeklügelter Malware-Infektionsprozess in Gang gebracht.

Einschlägige Technologien wie infizierte USB-Sticks oder Rückmeldungsaufforderungen sollten das vermeintlich sichere Netzwerk infiltrieren und ausforschen, bis die PLCs gefunden waren, die die Turbinen steuerten. Dann wurde in diese PLCs ein Virus geladen, der die Geschwindigkeit der Zentrifugen manipulierte, bis sie stehenblieben.

Ein Separation Kernel hätte der Ausbreitung der Infektion auf der Suche nach ihrem Ziel Einhalt gebieten können. In diesem Fall hätte der Computer mit der Schnittstelle zu den Siemens PLC-Endpunkten das höchstmögliche Schutzniveau erhalten, einschließlich der Deaktivierung sämtlicher Ports (wie USB), die Schaddateien den Zugang zu dieser Domäne hätten ermöglichen können.

Beide Referenzarchitekturmodelle – sowohl die Industrial Internet Reference Architecture (IIRA) als auch das Reference Architectural Model for Industrie 4.0 (RAMI 4.0) – unterstreichen, dass Verwundbarkeiten auf einer unharmonischen Verbindung der traditionell unterschiedlichen Welten der Informationstechnologie (IT) und der operativen Bedientechnik (OT) beruhen. Der strategische Einsatz von Separation-Kernel-Technologie ermöglicht es, anfällige Schnittstellen streng zu kontrollieren und erweist sich so als wirkungsvolle Waffe zur Verteidigung gegen Cyberangriffe.

(ku)