Wie anfällig die Gerätelandschaft des Internet of Things ist, zeigte das Mirai-Botnetz im vergangenen Jahr. Bei Mirai handelt es sich um eine ausführbare Linux-Datei des Formats ELF (Executable and Linking Format). Diese hat es vor allem auf DVRs (Digital Video Recorder), Router, Web-IP-Kameras, Linux-Server und andere Geräte abgesehen, auf denen Busybox läuft, das bei Embedded-Geräten im IoT-Umfeld häufig zum Einsatz kommt. Das Botnetz wurde beispielsweise für die Durchführung von DDoS-Attacken genutzt. Der ‚Vorteil‘: IoT-Geräte sind im Normalfall 24 Stunden online.

Weiter erhöhen lässt sich die Sicherheit durch die Integration von Tools, die die Ausnutzung von Schwachstellen erschweren – dazu gehören auch Lücken, die bei einem wenig sicheren Design System-immanent sind. Beispiele hierfür wären Grsecurity, Hardened Gentoo, Atlix, Yanux und wieder Astra Linux sowie AppArmor. Noch vor einigen Jahren bestanden sogenannte ‚Sicherheitsgarantien‘ darin, dass die Software auf vorhandene Fehler und Schwachstellen gescannt und ihre Integrität mit Hilfe von Prüfsummenvergleichen getestet wurde.

Mit den aufgeführten Maßnahmen mögen zwar konventionelle Betriebssysteme etwas sicherer geworden sein; allerdings lassen sich damit keine speziellen Anforderungen von Systemen umsetzen, die Teil einer kritischen Infrastruktur sind. Selbst Betriebssysteme, die von Anfang an als besonders sicher konzipiert werden, können nicht immer die Umsetzung spezieller Sicherheitsrichtlinien garantieren. Denn für ein relativ flexibles IT-Produkt, wie ein Betriebssystem, lassen sich gezielte Sicherheitsanforderungen nur dann exakt spezifizieren, wenn es für bestimmte Zwecke auf einer mehr oder weniger genau festgelegten Hardware betrieben wird, auf der nur bestimmte Software unter genau definierten Betriebsszenarien läuft. In diesem Fall lässt sich auch ein Bedrohungsmodell zur Beschreibung möglicher Gefahren erstellen, das eine bestimmte Menge von Anforderungen an die Sicherheit und Vertrauenswürdigkeit beschreibt. Beispiele hierfür sind spezialisierte Embedded-Systeme auf der Basis von LynuxWorks, Wind River oder Green Hills.

Die gleichen Garantien mittels eines  konventionellen Betriebssystem zu bieten ist ungleich schwieriger, da viel mehr Szenarien für die sichere Ausführung von Programmen abzudecken sind. Hinzu kommen in der Regel der Aufwand für die Erstellung von Richtlinien zu verschiedenen Arten der Zugriffskontrolle (willkürlich, verbindlich oder rollenbasiert), die üblichen Authentifizierungsmechanismen und andere Schutzmaßnahmen, deren Management keine speziellen Kenntnisse erfordert. In Summe sind also eher universelle Schutzmechanismen zu implementieren. Vorausgesetzt das Betriebssystem läuft auf einer festgelegten Hardware-Plattform, die normalerweise vom selben Hersteller stammt, kann die Regelkonformität dieser Mechanismen in Bezug auf bestimmte Standards oder ein bestimmtes Sicherheitsprofil zuverlässig gewährleistet werden. Auch hierfür finden sich Beispiele, etwa Oracle Solaris mit Trusted Extensions, XTS-400 und OpenVMS, AS/400.

Die größten Gefahren für industrielle Rechner im zweiten Halbjahr 2016: Internetverbindungen, Wechseldatenträger und E-Mail-Clients.

© Kaspb

Ein weiterer Aspekt, der nicht zu vernachlässigen ist: In einem klassischen Betriebssystem wird leicht etwas übersehen. Dies liegt daran, dass viele Software-Module weit über die Begrenzungen hinausgehen, denen sie eigentlich unterliegen müssten. Vermeiden lässt sich dies mit dem bereits erwähnten Whitelisting-Ansatz, bei dem Programme im System nur das tun dürfen, wofür sie entwickelt wurden. Ein  weiterer Vorteil dieses Ansatzes: Sollte etwas unter den Tisch gefallen sein, kann dies schlimmstenfalls dazu führen, dass ein Programm nicht läuft – ein Schaden am Gesamtsystem kann dadurch nicht hervorgerufen werden.

Diese strengen Vorgaben, welche Aktionen zugelassen sind, erhöhen einerseits die Sicherheit und erleichtern andererseits den Entwicklern das Leben; denn hier werden IT-Sicherheitsrichtlinien (Policy) und Anwendungsprogrammierung voneinander getrennt.
Somit können diese beiden Bestandteile einer sicheren Software-Anwendung auch separat entwickelt werden und Policy sowie Code sind unabhängig voneinander modifizierbar. Auch das Prüfen beziehungsweise die Verifizierung und das Testen des Anwendungscodes wird dadurch vereinfacht.

Microkernel-Architektur erhöht Modularität

Vor diesem Hintergrund und dem Bewusstsein für die Mankos bisheriger Ansätze hat Kaspersky Lab nun selbst ein Betriebssystem von Grund auf nach Security-Prinzipien entwickelt. Der dahinterstehende Ansatz basiert auf einem modularen System vertrauenswürdiger Komponenten, die sehr klein sind beziehungsweise aus nur wenigen Code-Zeilen bestehen, und standardisierte Software-Schnittstellen, beispielsweise zu einem Gastbetriebssystem, besitzen. Die Architektur eines so aufgebauten sicheren Systems ermöglicht die Portierung von schlankem Software-Code auf unterschiedliche Hardware-Plattformen. Ergebnis ist: Nur dieser Code muss dort verifiziert werden, während die ‚Top-Level-Module‘ so gehalten sind, dass sie einfach wiederverwendbar sind. Ein erster Schritt in Richtung eines derart modularen Betriebssystems ist eine Architektur, die auf einem eigenen Microkernel basiert. Er allein bestimmt Interaktion und Datenaustausch und hat die volle Zugriffskontrolle.

Doch auch damit lassen sich noch keine Eigenschaften abbilden, die das System zur Unterstützung bestimmter Sicherheitsrichtlinien braucht. KasperskyOS – so der Name des neuen Betriebssystems – trennt daher zugriffsrelevante Entscheidungen auf Basis der Sicherheitsrichtlinien von jenen, die durch die Zugriffskontrolle im Microkernel vorgegeben werden. Die Implementierung von Sicherheitsrichtlinien basierend auf Compliance-Vorgaben wird mit einer eigenen Komponente realisiert, dem Security Server. Das bekannteste Beispiel für eine solche Architektur ist Flux Advanced Security Kernel (FLASK). Mit Hilfe der FLASK-Architektur wurde bereits eine ganze Reihe von Betriebssystemen realisiert, etwa SELinux oder SEBSD; doch haben diese Systeme einen großen monolithischen Kernel.

KasperskyOS bildet die FLASK-Architektur zwar nicht in Gänze ab, nutzt aber deren Konzepte für mehr Sicherheit und Flexibilität bei der Nutzung in Zielsystemen. So werden bei FLASK die Schnittstellen und Beschreibungen für zwei Hauptkomponenten vorgegeben: für den Security Server, der die sicherheitsrelevanten Entscheidungen trifft, und den Object Manager, der dann für den eigentlichen Zugriff auf Basis dieser Entscheidungen sorgt. So können vertrauenswürdige Entscheidungen korrekt berechnet und angewendet werden. Komplexere Regeln, die mit Hilfe einer eigenen Konfigurationssprache formuliert werden, bündeln dabei einzelne Basis-Sicherheitsrichtlinien.

Umgesetzt werden die Regeln in einer Komponente, die sich zwischen dem Security Server und dem Microkernel befindet. Die Berechnung der sicherheitsrelevanten Entscheidungen kann so die gewünschte Funktionslogik abbilden. Auf diese Weise wird die Konfiguration umfassender Parameter für Sicherheitsrichtlinien (systemweite Konfiguration auf der Ebene des Security Server) und die Anwendung von Zugriffsregeln bei sämtlichen Operationen in allen Systemkomponenten (durch die Konfiguration von Regeln zur Berechnung entsprechender Entscheidungen) ermöglicht.

Mit Hilfe dieser Konfiguration entsteht letztendlich vertrauenswürdiger Code, der die Anwendungen mit dem Sicherheitsmodell des Systems verknüpft; denn es ist genau festgelegt, welche Operationen ein Programm unter Anwendung welcher Sicherheitsrichtlinien ausführen darf. Wichtig dabei ist: Im Code selbst ist diese Information nicht hinterlegt, es wird lediglich darauf verwiesen.

Zugegeben: Eine solche FLASK-ähnliche Architektur mit Microkernel ist keine Erfindung der Entwickler von KasperskyOS. Es gibt bereits erfolgreiche Beispiele solcher Microkernels (seL4, PikeOS, Feniks/Febos) und einige haben auch formal verifizierte Sicherheitseigenschaften. Damit lassen sich Betriebssysteme entwickeln, die eine Security Domain Isolation gewährleisten – eine Architektur, die auch unter dem Namen Multiple Independent Domains of Safety/Security (MILS) bekannt ist.

Eine derartige Architektur bedarf aber nicht nur der Entwicklung des Microkernels, sondern auch eines voll funktionalen Betriebssystems, das Security-Domains trennt und Informationsprozessumgebungen abschottet. Zudem muss es in allen Domains die Einhaltung der Sicherheitsrichtlinien kontrollieren. Wichtig ist dabei, dass sowohl der Microkernel als auch die Infrastruktur des darauf basierenden Betriebssystems und die Sicherheitsrichtlinien vom selben Anbieter kommen. Eine Nutzung von Komponenten von Drittanbietern würde unabhängig von deren Qualität immer Einschränkungen nach sich ziehen.

Das größte Manko von Betriebssystemen, die von Grund auf neu entwickelt werden, bleibt allerdings die mangelnde Unterstützung bestehender Anwendungen. Ist das Betriebssystem kompatibel mit gängigen Programmier-Schnittstellen, lässt sich dieses Manko teilweise ausgleichen, wie das bekannte Beispiel POSIX zeigt. Auch mit einer Virtualisierung ist dieser Nachteil behebbar. Kann nämlich in der Umgebung des sicheren Betriebssystems ein Hypervisor für die Virtualisierung eines gängigen Betriebssystems gestartet werden, dann sind dessen Anwendungen auch in der sicheren Umgebung ausführbar. KasperskyOS in Verbindung mit Kaspersky Secure Hypervisor bietet genau diese Möglichkeit. Unter bestimmten Umständen erbt dann ein gängiges, unsicheres System die sicheren Eigenschaften des auf dem Host laufenden Systems.

Die möglichen Einsatzbereiche

Einsatzbereiche für ein solches, per Design sicheres Betriebssystem gibt es viele – unter anderem bei ­diversen Industrieanwendungen beziehungsweise in Anlagen, die zur Kontrolle technologischer Prozesse eingesetzt werden. Solche Systeme benötigen nicht viele verschiedene Programme und jeder Netz­werk-Knoten hat seinen Zweck und spezifische ­Funktionen.

Eine der Kernkomponenten von KasperskyOS – Kaspersky Security System – sorgt im industriellen Umfeld bereits für die Absicherung von Speicherprogrammierbaren Steuerungen. Konkret hat Kaspersky Lab gemeinsam mit dem Unternehmen BE.services eine Implementierung entwickelt (Embedded Security Shield), die den bei der Codesys-Technologie verwendeten Hauptkommunikationskanal, den Codesys-Gateway, schützt.

Auch zu den Anforderungen im Bereich Connected Cars passt der geschilderte Ansatz ideal. Automobil- und Teilehersteller können so (mit dem Internet) verbundene und cybergesicherte Elektronik-Einheiten entwerfen und entwickeln. Der bereits erwähnte Kaspersky Secure Hypervisor ermöglicht dabei das Ausführen von Applikationen unter der strikten Kontrolle ihres Kommunikationsverhaltens. Diese Lösung lässt sich zum Beispiel für das ‚In-Vehicle Infotainment‘ nutzen, indem über eine Domain die kritische Software läuft (zum Beispiel CAN-Bus-Systeme, über die sämtliche Steuergeräte im Fahrzeug miteinander verbunden sind) und über eine andere die Unterhaltungs-Software. Die beiden virtuellen Umgebungen sind komplett unabhängig und isoliert von­einander auf­gebaut. Gemeinsame ­Hardware-Einheiten (Netzwerk-Karten, GSM oder WLAN) können ebenfalls ein­gebunden werden. Ein Update der Infotainment-Software hat dabei keinerlei (gefährliche) Auswirkungen auf kritische Komponenten im Auto.

Autor:
Holger Suhl ist General Manager DACH bei Kaspersky Lab.