Startseite > Embedded > Software > Wenn Safety und Security kollidieren

Anwendungsfall Medizinelektronik

Wenn Safety und Security kollidieren

3. November 2015, 11:12 Uhr | Manne Kreuzer

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Separation Kernel

Im Zentrum steht hier die MILS-Spezifizierung (Multiple Independent Levels of Security). Das Herz von MILS ist der Separation Kernel, der es mehreren Softwarefunktionen aus verschiedenen Entwicklungs- und Verifikationsquellen erlaubt, gemeinsame Ressourcen wie die CPU zu teilen, ohne sich zu stören. Muss eine sicherheitskritische Anwendung zugreifbar sein, eventuell über das Internet, bietet ein Least Privilege Separation Kernel nach dem Prinzip der geringstmöglichen Privilegien einen sinnvollen Ansatz, der gewährleistet, dass ein solcher Zugriff nicht die Angriffssicherheit und damit die funktionale Sicherheit des Systems beeinträchtigt.

Ein herkömmlicher Separation Kernel ist dafür ausgelegt, dafür zu sorgen, dass die verschiedenen Blöcke eines partitionierten Systems für andere Blöcke nicht sichtbar sind. Eine Ausnahme können bestimmte spezifizierte und streng kontrollierte Informationsflüsse sein. Das Least-Privilege-Modell der geringstmöglichen Privilegien erweitert dieses ursprüngliche Prinzip durch die Unterteilung der jeweiligen Blockinhalte. Dies minimiert die Sichtbarkeit noch mehr und sorgt dafür, dass nur der absolut notwendige Zugriff gewährt wird. »Wird eine solche Konfiguration auch noch mit Software betrieben, die gemäß den funktionalen Sicherheitsnormen geschrieben wurde, dann kommen vorbildliche Verfahren - Best Practice - aus beiden Welten zur Anwendung«, ergänzt Pitchford.

Das Beispiel der Abbildung 1 ist eine sicherheitskritische Anwendung mit Überwachungsmöglichkeiten über das Internet. Ziel ist es hier, Sicherheit für sicherheitskritische Anwendungen derart bereitzustellen, dass sie in einem RTOS ausgeführt werden können, oder aber als Bare-Metal-Applikation wie die »Trusted App« in der Abbildung. Anwendungen wie das gezeigte Windows-Betriebssystem können frei mit dem Internet interagieren, weil die Partitionierung zwischen ihm und der Trusted App bedeutet, dass kein erfolgreicher Angriff auf Windows Auswirkungen auf die Trusted App haben kann.

Natürlich bedarf es etwas Kommunikation zwischen den zwei Partitionen, damit diese Konfiguration von Nutzen ist. Doch die Natur eines Least Privilege Separation Kernels stellt sicher, dass diese Kommunikation stark reguliert und das Sicherheitsrisiko deswegen minimiert ist. Dieser Ansatz wird ergänzt durch volle Virtualisierung innerhalb der Partitionen – nicht des Kernels –, wodurch ein potenzieller Angriffszugangspunkt vermieden wird.
Diese Herangehensweise minimiert auch die Größe des Separation Kernels selbst. Die Unabhängigkeit der Gerätetreiber vom Kernel bedeutet, dass der Separation Kernel winzig sein darf – 25.000 Codezeilen können ausreichen. Je kleiner der Speicherverbrauch, desto geringer die Anzahl des gemeinsamen Codes und Datenraums zwischen den Partitionen, folglich weniger potenzielle Angriffsmöglichkeiten.

Auf einen konkreten Anwendungsfall übertragen, wie in Abbildung 2 gezeigt, bedeutet dies in der Praxis, dass der Separation Kernel die Kommunikationspfade zwischen der Betriebstechnik (OT) auf der Fabrikseite und der Informationstechnologie (IT) auf der Internetseite genau regelt. Wenn in diesem Beispiel ein erfolgreicher DoS-Angriff auf die Windows-Partition zum Internet hin erfolgt, könnte dem External Operator durchaus der Zugriff auf die gesuchten Informationen verwehrt werden. Doch wird die sicherheitskritische Steuerung dieser Einrichtung durch den Separation Kernel geschützt und wird daher weiterhin normal funktionieren.

»Kurz gesagt, wird die funktionale Sicherheit durch den Einsatz einer sicherheitsfokussierten Best-Practise-Entwicklung erfüllt. Es ist irrelevant, ob ein Gerät aufgrund einer Safety- oder Security-Schwachstelle ausfällt. Wir brauchen Systeme, die angriffs- und betriebssicher zugleich sind, bei denen das gleiche Augenmerk auf beiden Elementen liegt«, betont Pitchford. »Erfreulicherweise können von den Best Practices, unterstützt durch Safety-fokussierte Prozessstandards wie IEC 61508/EN 61508 und IEC 62304/EN 62304, die Security-Aspekte dieser Art Anwendungen nur profitieren.«

Im Gegenzug greift man, gestützt auf beste Entwicklungspraktiken mit Fokus auf Sicherheit, weitere Probleme der funktionalen Sicherheit auf und geht sie an. Durch die Anwendung der Least-Privilege-Separation-Kernel-Technologie lassen sich die, selbst bei gut geschriebenem Code, verbliebenen Softwareschwachstellen minimieren. So können Anforderungen an die Safety einschließlich der Security-betreffenden Forderungen erfüllt werden.

Die Aktivitäten des Barnaby Jack haben gezeigt, dass jede Art von Angriffsschwachstelle real auch ein Problem für die funktionale Sicherheit darstellt. Die derzeitigen FDA-Richtlinien der USA besagen, dass bei Anträgen für neue Geräte vor der Markteinführung eine Beschreibung der Sicherheitsmaßnahmen mitgeliefert werde muss, um eine Zulassung zu erhalten.