Bundesamt für Sicherheit in der Informationstechnik

M 4.485 Sicheres Betriebssystem für eingebettete Systeme

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Planer, Beschaffer, Entwickler

Für eingebettete Systeme gibt es sehr viele verschiedene Betriebssysteme. Einige hochspezialisierte Systeme benötigen gar kein Betriebssystem, andere sind eingebettete Betriebssysteme, die aus Mehrzweckbetriebssystemen heraus entwickelt wurden, z. B. Embedded Linux Varianten oder Windows CE. Dazwischen existieren zahlreiche unter verschiedensten Aspekten für eingebettete Systeme spezialisierte (Echtzeit) Betriebssysteme, wie z. B. RTOS oder VxWorks.

Auf der einen Seite wird von den Merkmalen eines Mehrzweckbetriebssystems in der Regel nur ein Teil benötigt, z. B.

  • sind Adressraumdeskriptoren nur notwendig im Falle von Systemen, die eine Adressraumisolation erfordern,
  • spielen Dateisystem und Dateienverwaltung bei einigen Einsatzbereichen keine Rolle,
  • benötigen ROM-basierte Systeme auf denen lediglich automatisiert ein einziges Programm abläuft keine prozessbezogene Benutzerrechteverwaltung,
  • kann auf eine aufwändige Verwaltung von Prozesszuständen verzichtet werden wenn der Ablaufplan für die Prozesse vorab festgelegt wird und sich nicht mehr ändert,
  • wird eine Ereignisverwaltung nur bei ereignisgesteuerten und/oder präemptiven Systemen benötigt.

Auf der anderen Seite können für eingebettete Systeme Anforderungen vorliegen, die mit Mehrzweckbetriebssystemen nicht oder schwierig umzusetzen sind, z. B.

  • harte Echtzeit-Zusicherungen,
  • weitergehende Mechanismen zur Fehlererkennung und -behandlung,
  • Zwang, ressourcenschonend zu arbeiten.

Wird ein eingebettetes System konzipiert oder beschafft, ist daher darauf zu achten, dass das Betriebssystem und seine Konfiguration für den vorgesehenen Betrieb unter den vorgegebenen Bedingungen, einschließlich der Sicherheitsanforderungen, geeignet sind. Das Betriebssystem ist gemäß den spezifischen Sicherheitsanforderungen des Gesamtsystems zu konfigurieren. Die Sicherheitsanforderungen sollten in der Sicherheitsrichtlinie und im Software-Entwicklungsprozess dokumentiert sein. Grundsätzlich sollte das Betriebssystem nur die für die vorgesehene Aufgabe notwendigen Dienste, Funktionen und Eigenschaften aufweisen. Es dürfen nur Treiber genutzter Schnittstellen eingebunden werden.

Sicherheitsaspekte eines Betriebssystems sollten in unterschiedlichen Bereichen und Betriebsphasen berücksichtigt werden. Das System sollte in einem sicheren planvollen Prozess entwickelt werden. Die Systemarchitektur sollte den Kernel von Paketen wie Middleware, Netz-Protokollen und Applikationen trennen. Es sollte möglich sein, diese Komponenten zu ergänzen und zu verändern, ohne dass der Kernel geändert werden muss. Das kann mit einem sogenannten Mikrokern erreicht werden. Ein Mikrokern (englisch: Microkernel) verfügt im Gegensatz zu einem monolithischen Kernel nur über grundlegende Funktionen zur Speicher- und Prozessverwaltung und zur Synchronisation und Kommunikation. Er ist somit weniger angreifbar und auch absturzsicherer.

Wie in M 4.489 Abgesicherter und authentisierter Bootprozess bei eingebetteten Systemen und M 4.483 Einsatz kryptographischer Prozessoren bzw. Koprozessoren (Trusted Platform Module) bei eingebetteten Systemen sowie M 4.78 Sorgfältige Durchführung von Konfigurationsänderungen und M 4.177 Sicherstellung der Integrität und Authentizität von Softwarepaketen empfohlen, muss das Betriebssystem Mechanismen zum sicheren Booten und zur sicheren Programmausführung bereitstellen. Dazu muss es in der Lage sein, ein Trusted Plattform Module ( TPM ) zu integrieren und zu nutzen.

Während des laufenden Betriebs sollte das System Angriffe abwehren können. Dies kann auch dadurch erreicht werden, dass zusätzliche Sicherheitsprodukte installiert und genutzt werden. Im Ruhezustand darf es für einen Angreifer nicht möglich sein auf Daten zuzugreifen.

Ein Chipkartenbetriebssystem sollte insbesondere folgende Mechanismen und Dienste bereitstellen:

  • Benutzeridentifizierung und Authentikation mittels PIN , PUK oder biometrischen Verfahren
  • Zugriffskontrolle mit Rechteverwaltung
  • Gegenseitige Authentisierung von Chipkarten und anderen Rechnern
  • Sichere Datenübertragung ("Secure Messaging") gegen Ausforschung und Manipulation
  • Bereitstellung von Signier- und Verschlüsselungsfunktionen im gesicherten Zusammenwirken mit Kryptoterminals
  • I/O -Kontrolle aller Schnittstellen durch das Betriebssystem gegen unerlaubte Zugriffe
  • Gewährleistung der Interferenzfreiheit einzelner Anwendungen: verschiedene Anwendungen dürfen sich nicht gegenseitig beeinflussen
  • Möglichkeit die Chipkarte zu deaktivieren

Für Systeme mit hohem oder sehr hohem Schutzbedarf ist zu prüfen, ob es erforderlich ist das Betriebssystem zu evaluieren, z. B. nach ISO 15408. Statt ein ganzes Betriebssystem komplett zu evaluieren, ist es ratsam, das BSI -Schutzprofil "Operating System Protection Profile (OSPP)" zu beachten.

Prüffragen:

  • Wurden bei der Konzeption oder zur Beschaffungsplanung des eingebetteten Systems die Anforderungen an das Betriebssystem analysiert?

  • Ist die Funktionalität des Betriebssystems auch im Hinblick auf Sicherheitsmechanismen für die vorgesehene Aufgabe ausreichend?

  • Sind nur die benötigten Dienste und Funktionen vorhanden bzw. aktiviert?

  • Unterstützt es das Betriebssystem, ein Trusted Plattform Module zu nutzen?

  • Ist das Betriebssystem hinsichtlich eines anerkannten Standards auf einer angemessenen Stufe evaluiert?

Stand: 15. EL Stand 2016