7 Fragen über 11-11 beantwortet

Und jetzt, liebe Leute, juhuuu! An einem Tag wie heute kann man einfach nur jubeln. Ungefähr so: JUHUUUU!!!

Warum, fragen Sie sich?

Wir haben offiziell unser eigenes sicheres Betriebssystem für Netzwerkgeräte, industrielle Kontrollsysteme und für das IoT veröffentlicht. Die Idee für das Betriebssystem entstand ursprünglich am 11. November, darum haben wir ihm den Codenamen 11-11 verliehen. Es war sicherlich ein sehr langer Entwicklungszyklus: Wir haben insgesamt 14 Jahre lang an dem Projekt gearbeitet und sogar die Markteinführung in einem Pilotversuch unter realen Bedingungen getestet. Jetzt ist das Betriebssystem für alle Interessierten zum Gebrauch bereit für den Einsatz in verschiedensten Szenarien.

Es ist wirklich nicht Linux, wir haben keinen einzigen String unter Linux programmiert. Wir haben das System für verschiedene Anwendungen und Einsatzzwecke von Grund auf neu entwickelt.

Ich erspare Ihnen all die nerdigen Details, aber wenn Sie die Technikinfo tatsächlich haben möchten, finden Sie sie hier. Ich befasse mich lieber mit den Dingen, die wir nicht in dem anderen Beitrag erwähnen. Deshalb beantworte ich ein paar häufig gestellte Fragen und räume mit einigen Mythen über unser neues Betriebssystem auf.

Warum brauchen wir noch ein Linux?

Dies ist eine der am häufigsten gestellten Fragen. Die Antwort ist erstaunlich einfach und direkt: Das hier ist nicht Linux. Es ist wirklich nicht Linux, wir haben keinen einzigen String unter Linux programmiert. Wir haben das System für verschiedene Anwendungen und Einsatzzwecke von Grund auf neu entwickelt.

Für Linux, Windows, MacOS und dergleichen sind Kompatibilität und Universalität vorrangig. Die Entwickler geben ihr Bestes für die Verbreitung ihrer Anwendungen, indem sie App-Entwicklung und Toolsets zu stark vereinfachen. Aber wenn es sich um unser Zielpublikum (Hardwareentwickler, SCADA-Systeme, IoT, etc.) handelt, geht dieser Ansatz gar nicht. Hier ist die Sicherheit das Wichtigste.

Für eine sichere Umgebung müssen wir ein generelles Default Deny (eine Standard-Ablehnung) auf Prozessebene ermöglichen und in einem Microkernel implementieren. In einfachen Worten, das System macht nur, was es machen soll und ist unfähig, etwas Anderes zu machen. In traditionellen Betriebssystemen ist dies unmöglich.

Wenn Sicherheit garantiert werden soll, muss man etwas Neues erfinden. Etwas, das Sicherheit „by design“ verspricht.

Es ist aber möglich, Sicherheitsmechanismen in ein bereits funktionierendes System zu implementieren. Im Wesentlichen ist das unser Kerngeschäft. Was wir machen, ist ausreichend für viele Anwendungen. Für manche Anwendungen ist das kleinste Risiko eines Cyberangriffs jedoch schon eine Katastrophe. Wenn Sicherheit garantiert werden soll, muss man etwas Neues erfinden. Etwas, das Sicherheit „by design“ verspricht.

Komm schon, ein sicheres Betriebssystem ist doch nichts Neues! Na und?

Ok, wir behaupten nicht, wir hätten etwas komplett Neues erfunden. Es gab natürlich schon andere Versuche, ein sicheres System zu schaffen. Manchmal waren einzelne Projekte sogar erfolgreich, aber die Kosten ihrer Implementierung glichen denen eines Flugzeugs (seltsamerweise wurden solche Systeme tatsächlich in Flugzeugen verwendet), sodass derartige Projekte nie als weitreichend angewandte Lösungen bestimmt waren.

Andere Projekte waren hauptsächlich auf den Bereich der akademischen Forschung beschränkt. Mit anderen Worten, ein paar kluge Köpfe bauten einen Microkernel und feierten mit Champagner und Vorträgen; und beließen es dann dabei. Kein Projekt hat bisher das Stadium eines großflächigen Einsatzes oder Vermarktung erreicht. Aber ein funktionierendes Fahrzeug braucht nicht nur einen Motor; es funktioniert nicht ohne Reifen, Federung und unzählige andere wichtige Teilen.

Wir haben uns dazu entschlossen, das System so zu gestalten, dass es in verschiedenen Bereichen relevant wird. Dafür ermöglichen wir äußerst detaillierte, kundenspezifische Anpassungen je nach Anwendung. Im Grunde genommen haben wir drei Produkte geschaffen: Das Betriebssystem (KOS), einen eigenständigen, sicheren Hypervisor (KSH) und ein dediziertes System für eine sichere Interaktion zwischen Betriebssystemkomponenten (KSS). Diese können auch eigenständig verschiedene Herausforderungen in Angriff nehmen, abhängig von der jeweiligen Anwendung.

So hat zum Beispiel SYSGO, ein deutsches Unternehmen, eine Lizenz für KSS erworben, um es in ihr eigenes Betriebssystem, PikeOS, zu integrieren. Andere Anbieter sind nur an dem Hypervisor (KSH) interessiert, mit dem vorhandene Anwendungen sicher ausgeführt werden können, ohne dass Veränderungen notwendig werden. Aber für die Switches von Kraftway war dieses Integrationsniveau nicht ausreichend, weshalb sie sich für den vollständigen Einsatz des Betriebssystems entschieden.

In anderen Worten, der entscheidende Vorteil unseres Betriebssystems ist dessen praktischer und verständlicher Charakter. Es wurde zweckbestimmt und nicht für unspezifische, hypothetische Szenarien konzipiert.

Wie könnt ihr beweisen, dass das Betriebssystem nur Vorgänge auf der Whitelist zulässt?

Natürlich, gleich nachdem wir behaupteten, dass das System sicher „by design“ ist, fochten manche Leute diese Behauptung an und glaubten uns nicht. Das ist vollkommen in Ordnung. Wenn es um Internetsicherheit geht, sollte man nichts unhinterfragt lassen.

Die Architektur unseres Betriebssystems basiert auf dem Prinzip, Objekte in eine maximale Anzahl von isolierten Einheiten aufzuteilen. Kunden können den Quellcode überprüfen, um sicherzugehen, dass keine undokumentierten Kompetenzen vorhanden sind. Gemeinsam mit dem Kunden richten wir selbstverständlich für den Rest verschiedene Sicherheitsrichtlinien ein, die im wahrsten Sinne des Wortes jedes noch so kleine Detail konkretisieren.

Das System wird nur die Aktionen ausführen, die Sie ausführen wollen. Folglich können Widersacher nicht einmal einen Bug einer App ausnutzen, die für dieses System konzipiert wurde. Natürlich kann man einen langen Code mit vielen Bugs schreiben. Aber damit der Code funktioniert, muss er strenge Richtlinien einhalten, die festlegen, was der Code darf und was nicht.

Glaubt ihr wirklich, dass irgendwas auf dem System laufen wird?

Na klar, weil unser System extrem flexibel ist! Generell könnte man es soweit anpassen, dass daraus ein Massenprodukt wird. Aber das würde sehr viel Zeit und Ressourcen in Anspruch nehmen. Im Augenblick haben wir noch nicht so weit im Voraus geplant und wir sehen unsere Lösung eher als ein Nischenangebot.

Man muss auch bedenken, dass man Code von Drittanbietern in das System portieren kann. Unser Lösungsansatz beinhaltet einen sicheren Hypervisor, mit dem Kunden praktisch jedes Betriebssystem als Gastsystem und benutzerdefinierte Anwendung (wie zum Beispiel einen unter Linux laufenden Apache-Server) ausführen können.

Unser Lösungsansatz beinhaltet einen sicheren Hypervisor, mit dem Kunden praktisch jedes Betriebssystem als Gastsystem und benutzerdefinierte Anwendung (wie zum Beispiel einen unter Linux laufenden Apache-Server) ausführen können.

Ja, wenn wir Zugriff auf diesen Server hätten, ihn in viele isolierte Instanzen teilen und Richtlinien festlegen könnten, die bestimmen wie diese miteinander interagieren, würden wir ein wesentlich höheres Sicherheitsniveau erreichen. Aber das bedeutet unglaublich viel Arbeit. Andererseits ist alles möglich, wenn man genug Mumm und Geld hat. 🙂

Darum haben wir im Hypervisor benutzerdefinierte Anwendungen zugelassen. Ja, wir schaffen ein anfangs sicheres System mit zunächst unsicheren Anpassungen. Was im Rahmen der Anpassung passiert, ist unklar. Aber wir können die Interaktionen mit der Hardware, anderen Anpassungen und der Außenwelt kontrollieren. Das ist doch schon mal etwas. Mit dieser Konfigurierung ist ein Ausbruch aus der „Sandbox“ äußerst unwahrscheinlich.

Ach komm schon, es werden doch sowieso Daten gesammelt

Der Kernel überträgt nichts an niemanden; das kann man durch einen Blick auf den Quellcode (siehe oben) einfach überprüfen. Im Microkernel ist fast nichts enthalten. Alle Treiber werden voneinander isoliert. Um also Daten zu senden, müsste man ein neues Stück Code schreiben. Das würde man deutlich sehen; man muss nicht einmal auf den Quellcode schauen, um das zu sehen. All das wird in den Sicherheitsrichtlinien festgehalten. Und die Kunden sind immer in der Lage diese Richtlinien zu überprüfen, unabhängig vom Code. Wenn die Richtlinien keine Erlaubnis für das Senden von Daten enthalten, dann wird das System dies auch nicht tun.

OK, in Ordnung, aber das kostet garantiert eine Stange Geld

Ehrlich gesagt kann ich mich nicht daran erinnern, jemals etwas mit einer Stange bezahlt zu haben. Ich bin also nicht ganz auf dem Laufenden, was aktuelle Straßenpreise betrifft. Aber das ist ein fragwürdiger Vergleich. Unser Betriebssystem ist kein fertiges Produkt, es ist ein Projekt-Angebot.

Man kann alles hacken und euer System ist da keine Ausnahme!

Das Wesen der Cyber-Sicherheit besteht darin, es den Cyber-Ganoven so schwer wie möglich und Cyber-Attacken so kostspielig zu machen, dass daraus ein unrentables Geschäft wird.

Ich muss zugeben, dass keine Antwort perfekt ist, abgesehen von der Nummer 42 :). Alles ist möglich. Aber das ist kein Grund zum Aufgeben! Das Wesen der Cyber-Sicherheit besteht darin, es den Cyber-Ganoven so schwer wie möglich und Cyber-Attacken so kostspielig zu machen, dass daraus ein unrentables Geschäft wird. In dieser Hinsicht ist unser System der Konkurrenz voraus.

Das wäre alles fürs Erste. Schicken Sie mir Ihre Fragen über die sozialen Netzwerke und schauen Sie auf unserer Webseite vorbei, um mehr zu erfahren.

Kommentare lesen 0
Hinterlassen Sie eine Nachricht.