Suchen

Software-Architekturen MILS – Multiple Independent Levels of „Sicherheit“

| Autor/ Redakteur: Jacques Brygier * / Franz Graser

Eine Betriebssystem-basierte Sicherheitsarchitektur bei Embedded-Systems für sichere und vertrauenswürdige Systeme bringt verschiedene Sicherheitsanforderungen unter einen Hut.

Firmen zum Thema

Bild 1: Komplexe Anwendungen im Flugzeug sind nach dem MILS-Konzept aufgebaut, um Sicherheit zu gewährleisten. Dabei laufen kritische und weniger kritische Anwendungen auf derselben Plattform.
Bild 1: Komplexe Anwendungen im Flugzeug sind nach dem MILS-Konzept aufgebaut, um Sicherheit zu gewährleisten. Dabei laufen kritische und weniger kritische Anwendungen auf derselben Plattform.
(Bild: Sysgo)

Vernetzte Embedded Systems brauchen mehr als Virenscanner oder Kryptographie, um funktionale Sicherheit und Vertrauenswürdigkeit zu garantieren. Der Aufbau einer Sicherheitsarchitektur durch strikte Trennung der Anwendungen und Kontrolle der Kommunikation auf Betriebssystemebene ermöglicht die Komposition sicherer, komplexer Systeme in der Avionik, im Auto, im Smart Grid und vielen weiteren Industrien, die sich anschicken, ihre Systeme zu vernetzen.

Embedded Systems wachsen zusammen zu komplexen Systemen, zu ganzen Infrastrukturen in einer vernetzten Welt. Wurden sie früher klein und isoliert für Mess- und Regelaufgaben eingesetzt, so führen sie heute hochverdichtete, von einander abhängige Funktionen in Maschinen und Geräten aus. Mikroprozessoren und immer mehr Software übernehmen von einfachen Handgriffen bis hin zu komplexen Entscheidungen vernunftbegabte Handlungen von Menschen.

Dabei wachsen zwei Welten zusammen, deren Unterschiedlichkeit noch nicht ausreichend bedacht wird: Embedded Systems und IT. Der Aspekt der Sicherheit ist hier eine ganz zentrale Frage, die Entwickler von Embedded Systems als Problem der korrekten Funktion und Vermeidung von Fehlern im System betrachten (Safety). Für IT-Entwickler stehen vor allem Angriffe von außen, Viren, Würmer oder feindliche Attacken auf das System im Vordergrund (Security). Vernetzte Systeme, die auf die physikalische Welt einwirken, benötigen beides, Safety und Security.

Zusätzlich können und müssen die Entwickler unterschiedliche Ebenen von Sicherheit unterschiedlich behandeln. Offene Informationen können ohne Prüfung weitergegeben werden, geschützte Daten nur nach Prüfung der Berechtigung des Empfängers. Eine eilige Durchsage des Piloten im Flugzeug ist somit kritischer als das Abspielen von Musik oder Video in der Kabine für die Passagiere.

Unterschiedliche Kritikalität

Cyber-physikalische Systeme kombinieren immer mehr Software-Applikationen auf standardisierter, leistungsfähiger Hardware. Das geschieht, um Platz, Gewicht und Verkabelung zu sparen (wie im Auto oder Flugzeug) oder zur intelligenten Nutzung der Ressourcen. Dabei entstehen komplexe Systeme mit gemischten Sicherheitsanforderungen oder Multiple Level Security/Safety (MLS), die als monolithische Einheit nur schwer auf funktionale Sicherheit und Vertrauenswürdigkeit geprüft werden können. Seit den 1980er Jahren und verstärkt zu Beginn der 2000er Jahre wurde primär in den USA nach Lösungen für die Sicherheitsprobleme von Software mit unterschiedlicher Kritikalität geforscht.

Software ist nur so sicher, wie das Fundament, auf dem sie aufbaut. Erfolgreiche Attacken auf die Systemsoftware können alle weiteren Sicherheitsmaßnahmen nutzlos machen. Welche Bedrohungen sind das?

  • Bypass: Bösartige Software umgeht die Sicherheitselemente des Systems;
  • Kompromittieren: Bösartige Software liest geschützte Daten (etwa Passwörter);
  • Fälschen: Bösartige Software ändert geschützte Daten;
  • Fehler setzen sich fort: Ein Fehler in einer Anwendung bringt andere Anwendungen zum Absturz;
  • Verdeckte Kanäle: Bösartige Software gewinnt Informationen durch Überwachung von Seiteneffekten, wie Zeitverhalten;
  • Viren: Bösartige Software gewinnt Rechte für die Nutzung des privilegierten Modus, um alle Anwendungen zu infizieren;
  • Subversion: Bösartige Software wird vom Nutzer als glaubwürdig legitimiert.

Schutzmaßnahmen für MLS-Systeme müssen daher auf der Ebene der Software-Architektur ansetzen und durch Separierung von Anwendungen in Partitionen und Kontrolle der Kommunikation zwischen ihnen grundsätzliche Bedrohungen abwenden. Daraus wurde das Konzept von Multiple Independent Levels of Security/Safety (MILS) als Architektur für Vertrauenswürdigkeit und funktionale Sicherheit entwickelt.

Die Multiple-Level-Sicherheitsarchitektur

Das MILS-Konzept kommt ursprünglich aus dem militärischen Bereich, wo man mit monolithischen Kernen für sichere Anwendungen scheiterte, weil die Systeme wegen ihrer Größe und Komplexität nicht mehr zertifiziert werden konnten. Seit den 1990er Jahren wird die MILS-Idee auch für die Avionik im Standard ARINC 653 verwendet, um Systemsoftware von Anwendungssoftware zu trennen. Nach MILS werden Systeme in drei horizontale Ebenen mit unterschiedlichen Rechten und Stufen der Vertrauenswürdigkeit getrennt.

Bild 2: Die MILS Architektur unterscheidet drei Sicherheitszonen.
Bild 2: Die MILS Architektur unterscheidet drei Sicherheitszonen.
(Bild: Sysgo)

Die unterste Ebene bildet die Hardware mit weiteren Plattform- und Security-Modulen. Auf Level 2 befindet sich der Separation Kernel, der die gesamte Kommunikation im System kontrolliert und Rechenzeit und Speicherzugriffe an die einzelnen Anwendungen zuteilt. Nur er ist für Hardwarezugriffe privilegiert und gilt hinsichtlich der Security als vertrauenswürdig. Ebenfalls vertrauenswürdig, jedoch nicht für Hardwarezugriffe privilegiert sind alle weiteren Module der Systemsoftware der zweiten Ebene. Mit ihnen wird das Gesamtsystem konfiguriert, organisiert und seine Funktionsfähigkeit überwacht. Alle Applikationen mit ggf. benötigten Betriebssystemschnittstellen, die alle als nicht vertrauenswürdig gelten und im User Mode laufen, sind der dritten Ebene zugeordnet.

Das MILS-Konzept formuliert für den Separation-Kernel die konsequente und einheitliche Durchsetzung mehrerer Sicherheitspolitiken, um die Vertrauenswürdigkeit des Systems zu sichern und zu erhalten. Diese Sicherheitspolitiken des Separation Kernels werden durch Sicherheitsfunktionen durchgesetzt, deren Implementierung auf ein absolutes Minimum reduziert ist, damit ihre Evaluierung und Zertifizierung möglich bleibt. Sie umfassen unter anderem:

  • Informationsfluss: Der Separation Kernel muss den Informationsfluss zwischen Hardware, Systemsoftware und Applikationen ermöglichen und stets kontrollieren;
  • Datenisolierung: Der Separation Kernel sorgt für eine Isolierung der Speicherbereiche und Ressourcen, die für die einzelnen Anwendungen vorgesehen sind;
  • Säubern der CPU-Register: Der Separation Kernel löscht alle Einträge in den CPU Registern, bevor eine andere Anwendung die CPU nutzen darf;
  • Schadensbegrenzung: Der Separation Kernel begrenzt Fehlfunktionen einer Applikation auf ihre Partition. Alle anderen Applikationen, die Systemsoftware und der Separation Kernel selbst werden nicht beeinträchtigt.

Aus diesen Sicherheitsfunktionen ergeben sich für den Separation Kernel eine Reihe von Merkmalen, die im Englischen mit der Formel NEAT sehr griffig zusammengefasst sind:

  • Non-bypassable: Der Separation Kernel muss die gesamte Kommunikation kontrollieren und darf unter keinen Umständen umgangen werden (können);
  • Evaluatable: Die Sicherheitsfunktionen müssen einfach und der Umfang des Codes gering sein, damit sie bewertet und nach Common Criteria oder nationalen Richtlinien formal verifizier- bzw. zertifizierbar sind;
  • Always Invoked: Die Sicherheitsfunktionen müssen immer aktiv sein;
  • Tamperproof: Sicherheitsfunktionen dürfen unter keinen Umständen von bösartigen Code verändert werden, so dass Ressourcen wie z.B. Buffer erschöpft werden und Fehler auslösen.

Sichere Architekturen in der Praxis

Abb. 3: Beispielhafte PikeOS-Systemarchitektur für Automotive
Abb. 3: Beispielhafte PikeOS-Systemarchitektur für Automotive
(Grafik: Sysgo)

Blickt man auf die Bedrohungen für cyber-physikalische Systeme, dann wird deutlich, dass nach dem MILS-Konzept implementierte Separationskernel Sicherheit auf Architekturebene bieten, indem sie die Subsysteme nach Vertrauenswürdigkeit trennen und einheitliche Sicherheitspolitiken erlauben, die nicht umgangen werden können.

Die Märkte Avionik und Automotive sind Treiber für die Verwendung MILS-konformer Architekturen. Aber auch in anderen Branchen werden sichere Architekturen immer wichtiger:

  • Flugzeuge haben generell einen sehr hohen Anspruch an die funktionale Sicherheit. Die Einbindung in globale Luftverkehrs-Netzwerke und die Nutzung von elektronischen Geräten durch die Passagiere machen weitere Investitionen in den Schutz der Flugzeugsysteme erforderlich.
  • Speziell in hochpreisigen Automobilen werden Fahrerassistenz-, Infotainment- und Entertainmentsysteme verbaut. Über Car-to-Car Netzwerke wird nachgedacht und geforscht, autonomes Fahren ist in Sichtweite. Die funktionale Sicherheit wird neuerdings von der ISO 26262 erfasst. Weitere Schutzmaßnahmen (gegen Manipulation, feindliche Attacken, Diebstahl u.a.) werden hier ebenfalls erforderlich.
  • In bildgebenden Verfahren in der Medizintechnik müssen große Datenmengen in Echtzeit übertragen werden. Zugleich sollen private Patientendaten geschützt sein.
  • Die vertikale Integration der Kommunikation in alle Unternehmensbereichen, die sogenannte Industrie 4.0, erfordert eine klare Trennung kritischer und unkritischer Unternehmensdaten.
  • In der Industrieautomatisierung wird mit der neu entstehenden Norm ISA 62443 „Security for Industrial Automation and Control Systems“ eine Antwort auf die IT-Sicherheitsherausforderungen vieler Industriesteuerungen gegeben, die im Betrieb oder indirekt (z.B. bei Wartungsarbeiten) Daten mit anderen Systemen austauschen.
  • Das Bundesamt für Sicherheit in der Informationstechnologie (BSI) hat 2013 ein Schutzprofil für Gateways für Smart Meter erstellt, um den Datenschutz bei der Bereitstellung, Verwendung und Abrechnung von Elektrizität zu gewährleisten.

Cyber-physikalische Systeme werden zu kritischen Infrastrukturen, die einen wirksamen Schutz gegen feindliche Angriffe, Manipulation oder Spionage brauchen. Das MILS-Konzept berücksichtigt sowohl die funktionale Sicherheit als auch die Vertrauenswürdigkeit der Systeme, erlaubt die separate Analyse, Zertifizierung und Wiederverwendung einzelner Elemente und dämmt so die Kosten für sichere Systeme ein.

* Jacques Brygier ist Vice President Marketing beim Mainzer Echtzeitbetriebssystem-Spezialisten Sysgo.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 42251939)