PikeOS von Sysgo Betriebssystem für Safety und Security

Die Entwicklung von Saferty und Betriebssystem - ein schwerer Zusammenschluß.
In der Luftfahrt sind die Sicherheitsstandards am höchsten. Nicht nur dort wird neben Safety zunehmend auch nach Security gefragt.

Die Entwicklung des Safety-Betriebssystems PikeOS hätte Sysgo fast in den Ruin getrieben. Jetzt, wo das Thema Safety abgedeckt ist, fragen die Kunden nach Security. Ein Gespräch darüber, warum es so schwer ist, beides zusammenzubringen.

PikeOS war zwar vor zehn Jahren eines der ersten sicherheitsgerichteten Betriebssysteme für Multicore-Prozessoren. Mit dem Einsatz von Virtualisierungstechnik im Embedded-Umfeld stand Sysgo technisch an vorderster Front. Aber um diese Technik marktreif zu machen, waren hohe Vorab-Investitionen nötig – so hoch, dass Firmengründer Knut Degen immer wieder händeringend auf der Suche nach Investoren war. Hinzu kommt, dass sich Sysgo in den Branchen Rüstung, Luftfahrt und Automobil in einem Umfeld mit langen Entscheidungswegen und Innovationszyklen bewegt. Mit dem Aufkauf Sysgos durch die französische Thales-Gruppe Ende 2012 hat sich die finanzielle Situation aber entspannt.

Die technischen Herausforderungen nehmen aber nicht ab: In vielen Industriezweigen hat man gemerkt, dass man nicht nur Safety, sondern auch Security braucht. Das bedeutet zusätzlichen Aufwand. Kann ein Betriebssystem, das für Safety-Anforderungen entwickelt wurde, so erweitert werden, dass es auch Security-Anforderungen erfüllt? Darüber sprach Joachim Kroll, Elektronik, mit Sysgo-Firmengründer und CEO Knut Degen und Franz Walkembach, Vice President Marketing & Product Strategy bei Sysgo.

Elektronik: Es gibt inzwischen eine ganze Reihe von sicherheitsgerichteten Betriebssystemen mit Virtualisierung und Speicher-Partitionierung. Kann sich PikeOS da überhaupt noch von den Wettbewerbern unterscheiden?

Franz Walkembach: Die Bedeutung der ganzen Einzel-Features lässt immer mehr nach. Entscheidend ist das Gesamtpaket, das ein Anbieter hat und mit dem er sich vom Wettbewerb unterscheidet. Bei uns zählen dazu Zertifizierungserfahrung aus Avionics, schnelles Booten, ein Hypervisor zur Virtualisierung, der Open Source mit Echtzeit verbindet, aber auch externe Faktoren wie der Langzeit-Support oder die Frage: Welche Anforderungen habe ich an meine Software hinsichtlich Export-Beschränkungen?

Knut Degen: Einen guten Hypervisor zu entwickeln, das kann man mit einem Team von zehn Leuten innerhalb von zwei Jahren. Und Vieles gibt es auch als Open Source. Aber die spannende Frage ist doch: Wer bringt das alles zusammen? Wer zertifiziert das? Wer passt das an die Hardware an? Wer macht das marktfähig? Wer kann dafür langfristige Lieferverträge anbieten? Wer garantiert, dass das auch in zehn Jahren noch unterstützt wird?

Wir haben eine gute Technologie. Aber um die geht es nicht allein. Hinter uns steht auch eine Firma, die uns garantiert, dass wir das auch in zehn Jahren noch unterstützen können. Wir haben das ganze Zertifizierungs-Know-how im Haus. Wir haben selbst zertifiziert und nicht zertifizieren lassen. Und schließlich sind wir unabhängig von amerikanischen Exportbeschränkungen – unser Produkt ist eine rein europäische Lösung. Dieses Gesamtpaket ist das, was unsere Stärke ausmacht.

Elektronik: Jeder Industriezweig hat seine eigenen Standards, nach denen funktionale Sicherheit zertifiziert wird. Ist das nicht ein riesiger und unnötiger Aufwand?

Knut Degen: Die Mutter aller dieser Standards ist die DO-178. Davon ist die IEC 61508 abgeleitet, die wiederum die Basisnorm für die verschiedenen branchenspezifischen Standards ist: IEC 50128 für den Bahnsektor, ISO 26262 für Automotive usw. Bei diesen unterschiedlichen Ausprägungen sind 90 Prozent wiederverwendbar, das haben wir alles drauf.

Elektronik: Können Sie auch nach Security-Standards wie Common Criteria zertifizieren?

Knut Degen: Wir haben derzeit ein Projekt mit dem BSI laufen, unser System nach Common Criteria EAL 5 zertifizieren zu lassen. Ehrlich gesagt, das haben wir uns einfacher vorgestellt. Im Rahmen eines Horizon-2020-Projekts der EU haben wir versucht, möglichst Vieles vom Safety-Bereich auf den Security-Bereich zu übertragen. D.h., wir haben ein Dokument erstellt, in dem steht: Diese und jene Forderung aus Common Criteria ist abgedeckt durch eine andere Forderung aus unserem Safety Manual. Es gibt viele Sachen, die identisch sind. Trotzdem war das kein voller Erfolg. Es ist ein großer Aufwand, zwischen beiden Welten zu übersetzen. Es würde zwar funktionieren, macht aber so viel Arbeit, dass es nicht effektiv ist. Und es kommen technisch ein paar zusätzliche Anforderungen dazu wie Penetration Tests oder Vulnerability-Analyse. Aber mit Hilfe des erwähnten BSI-Projekts werden wir bis Ende dieses Jahres EAL 3+ erreichen und konnten ein Folgeprojekt gewinnen, das uns bis 2018 auf EAL 5 bringen wird.

Elektronik: Ein Wettbewerber ist nach EAL 6+ zertifiziert …

Franz Walkembach: Dann muss man dazu aber auch die Frage stellen: Wo? Denn oberhalb von EAL 4 gibt es nur noch nationale Standards. Deshalb versucht die Industrie auf diesem Level zu bleiben, denn nur so kann das europaweit anerkannt werden. Ansonsten gibt es im Bereich Zertifizierung ja eine Art Krieg zwischen Industrien und Regionen. Jedes Land und jede Region hat eigene Anforderungen an die Security-Zertifizierung, die sich auch immer wieder ändern. Manche Regionen sind noch in der Findungsphase und die Industrie hält mit ihren eigenen, weltweiten Standards dagegen. Es bleibt spannend, wer oder was sich da durchsetzen wird.

Knut Degen: Bei Safety haben wir globale Standards. Wenn es um Security geht, haben wir ab einer bestimmten Ebene nur noch nationale Standards. Da reden nicht mal mehr die Franzosen mit den Deutschen. Das ist ein ganz großes Problem. Das hängt damit zusammen, dass die ganzen Security-Standards traditionell aus den Bereichen von Militär und Geheimdiensten kommen. Es ist ein ungelöstes Problem, dass es ab Level 5 keinen europäischen Security-Standard gibt.