Sicherheit darf kein Zufall sein

10 goldene Regeln für sichere Embedded-Systeme

Zertifizierungen und Zulassungen müssen integraler Bestandteil des gesamten Projektes sein, egal ob FDA-Zulassung bei Medizingeräten, EN5012x-Anforderungen in der Bahntechnik, ISO26262 im Automotive-Bereich oder andere nach IEC61508 SIL-Level einzustufende Systeme entwickelt werden. Hersteller müssen dabei mehr als die rein technischen Herausforderungen berücksichtigen.
Soll ein Produkt bestimmten Sicherheitsanforderungen entsprechen, gilt es Rahmenbedingungen, Prozesse und die gesamte Kultur innerhalb der Organisation zu kennen. Zehn fundamentale Regeln können Entwicklern bei der Umsetzung helfen.

1. Sicherheitskultur

Entwickler müssen nicht nur die Anforderungen an das Produkt berücksichtigen: Unternehmen müssen eine firmenweite Sicherheitskultur etablieren. Alle Projektbeteiligten sollten bei jeder Entscheidung an die Auswirkung auf die Sicherheitsanforderungen denken. Beispielsweise beim Implementieren eines Nachrichtenaustauschs nach einer bestimmten Methode gilt es u.a. abzuwägen, wie Performance und Zuverlässigkeit zusammenspielen sollen.

2. Experten

Hierzu bedarf es Experten, die beraten und definieren, was ein sicheres System wann tun muss und wie es sich verifizieren lässt. Dies erfordert viel Erfahrung. Sichere Systeme müssen einfach sein. Um Komplexität zu verringern gilt es zunächst, Anforderungen festzulegen, ein passendes Design-Pattern auswählen, dann das System zu bauen und zu validieren.

3. Prozesse

Hierbei müssen Unternehmen und Mitarbeiter in Prozessen denken. Darum geht es u.a. im IEC62304 für Software in medizinischen Geräten. Ohne klar definierte Prozesse lässt sich nicht nachweisen, dass ein System seine Sicherheitsanforderungen erfüllt. Prozesse gelten hierbei als messbarer Vertreter für etwas, das weitgehend unmessbar ist. So ist relativ einfach überprüfbar, ob ein Prozess eingehalten wurde. Hingegen die Qualität des Designs und des Quellcodes zu beurteilen, erweist sich als deutlich schwerer. Sauber definierte Prozesse garantieren zwar kein gutes Produkt, aber unklare Prozesse führen selten zu einem hochwertigen Produkt. Prozesse bilden daher den Rahmen für die Bestimmung von Entwicklungsparametern, z.B. erlaubt ein klarer Testprozess statistische Aussagen über die Testabdeckung. Zugleich bilden Pozesse eine Struktur, die die Beweisführungskette für den Sicherheitsnachweis aufzeigt. Ohne Prozesse müssten kostenintensive Nachweise für die Sicherheit gegebenfalls nachträglich generiert werden. Sinnvollerweise sollten Entwickler daher Prozesse definieren, die während des gesamten Projektzyklus bereits hilfreiche Nachweisdokumente generieren.

4. Explizite Aussagen

Aussagen zur Sicherheit müssen die Verlässlichkeit explizit definieren. Ebenso sind die Bedingungen, unter denen diese Aussagen gelten, explizit auszudrücken. Die FDA sagt z.B. bezüglich medizinischer Geräte, dass „Prozessdaten, die zeigen, dass Design und Produktionsabläufe solide sind“, alleine nicht nachweisen können, dass eine Software sicher ist und dass zusätzlich „Nachweismethoden erforderlich sind, die sich auf die produktspezifische Gerätesicherheit fokussieren“. Die Verlässlichkeit eines Systems beschreibt die Fähigkeit, so lange wie nötig innerhalb einer bestimmten Zeitspanne korrekt auf Ereignisse zu reagieren. Es ist somit eine Kombination aus Verfügbarkeit – als zeitlicher Begriff – und Zuverlässigkeit – Korrektheit der Reaktionen. Im Kern jedes Sicherheitsnachweises stehen Aussagen wie „Dieses System wird seine Aufgabe A mit einer Verlässlichkeit von B erfüllen, so lange die Bedingungen C gegeben sind. Falls A nicht erledigt werden kann, wird das System in seinen Design Safe State gehen, die Wahrscheinlichkeit dafür ist P“. Die Bedingungen, unter denen die Aussagen zur Verlässlichkeit gelten, sind ebenso wichtig. Beispielsweise soll eine Flugsteuerung die Anforderungen nach IEC61508 für 20 Stunden Dauerbetrieb erfüllen. Danach wird sie zurückgesetzt. Wird sie nur in Flugzeugen eingesetzt, die nie über 20 Stunden in Betrieb sind, ist diese zeitliche Limitierung irrelevant. Entwickler sollten nun also an einer Steigerung der Verlässlichkeit für diese 20 Stunden, anstatt an einer Verlängerung der möglichen Betriebsstunden arbeiten.

5. Systemausfälle

Da sich Fehler nie ganz verhindern lassen, muss ein sicher laufendes System sie erkennen und abfangen können oder sich in einen sicheren Zustand versetzen. Hierzu existieren Definitionen von Fehler, Störung und Ausfall: Bei einem Fehler handelt es sich um Programmcode, der zu unerwünschtem Verhalten führen kann. Dies führt zu einer Störung. Ein Ausfall bzw. ein Systemversagen entsteht aufgrund einer nicht abgefangenen oder korrigierten Störung. EN50128 für Railway-Applikation beschreibt, was Entwickler sicherheitskritischer Systeme leidvoll lernen mussten: „Bei einem komplexen Software-System ist es unmöglich zu beweisen, dass es völlig fehlerfrei ist“. Man kann lediglich „Nachweise erbringen, welche glaubhaft machen, dass das System so verlässlich ist wie behauptet“. Ein sicheres System muss also mehrere Verteidigungslinien enthalten: – Isolierung von sicherheitskritischen Prozessen: Sicherheitskritische Komponenten dürfen nicht von anderen Komponenten beeinflusst werden können. – Systemstörungen verhindern: Das Systemdesign muss vorsehen, dass Fehler abgefangen werden können, ehe sie zu Störungen im Betrieb führen. – Eine Störung darf keinen Ausfall verursachen: Replikation und Diversifikation sind für Software vielleicht weniger geeignet als für Hardware, aber dennoch sind sie, richtig eingesetzt, sinnvoll. – Erkennung und Wiederherstellung nach Ausfällen: Bei vielen Systemen ist es ausreichend, in einen als sicher definierten Zustand zu gehen, die Wiederherstellung obliegt dann einer höheren Systemebene (z.B. dem Anwender). Bei anderen Systemen ist das nicht praktikabel, hier müssen Recovery-Mechanismen greifen. Bei ungünstigen Rahmenbedingungen kann ein Crash mit schnellem Neustart jedoch sicherer sein.

6. Validierung

Zum Nachweis der Verlässlichkeit ist Testen allein nicht ausreichend, weitere Maßnahmen sind gefordert wie formales Design, statistische Analyse und nachträgliche Design-Validierung. Testen findet indirekt Fehler im Design oder in der Implementierung, da es die Störungen und Ausfälle aufdeckt, die durch Fehler verursacht werden. Tests sind die wichtigste Methode zum Entdecken und Beheben sogenannter Bohrbugs: Bugs, die reproduzierbar sind und auch beim Debuggen noch auftreten. Bei ‚Heisenbugs‘ aber stoßen Entwickler schnell an Grenzen, denn derselbe Fehler führt zu unterschiedlichsten Störungen. Für den Nachweis von Sicherheitsaussagen helfen Methoden wie die statische Analyse. Dieses Vorgehen empfehlen u.a. Organisationen wie die FDA, inklusive Syntaxüberprüfungen gegen Code-Standards, Fehlerwahrscheinlichkeitsabschätzungen, Überprüfung der Korrektheit durch Assertions im Quellcode sowie symbolische Ausführung. Daten zur Betriebsbewährtheit informieren über den gesamten Lebenszyklus über Betriebsstunden der Software und während dieser Zeit aufgetretene Fehler. Bei der Fehlereinstreuung bauen Testingenieure absichtlich Fehler ein, die helfen sollen, die Fehlererkennung zu testen und mittels statistischer Auswertung die Zahl der noch verbliebenen echten Fehler einzuschätzen. Die formale und semi-formale Entwurfsverifikation erfolgt normalerweise schon vor der Implementierung, kann aber auch nachträglich vorgenommen werden.

7. Cots und Soup

Alles selbst zu entwickeln birgt oft mehr Risiken als ausgewählte kommerzielle oder Commercial Off-The-Shelf-Komponenten (Cots) zu verwenden. Und auch die Verwendung von Software Of Uncertain Provenance (Soup), also Software unbestimmter Herkunft, ist zulässig, sofern für diese Komponenten ausreichende Daten für den Sicherheitsnachweis des Systems zur Verfügung stehen. Die Implementierung von Betriebssystemen, Netzwerkprotokollen oder Datenbanken erfordert spezialisiertes Know-how und eine Cots-Lösung hat häufig den Vorteil mehrerer Millionen nachgewiesener Betriebsstunden. Cots-Software ist aus der Sicht eines Entwicklers meist auch Soup. Die Standards IEC61508 und IEC62304 gehen davon aus, dass Soup verwendet wird. Für Systeme, die SIL3 oder SIL4 benötigen, fordert EN50128, dass „eine Strategie entwickelt werden muss, wie man Fehler in der Cots-Software aufspüren und das System vor diesen Fehlern schützen kann“. Es müssen ausreichend dokumentierte Nachweise vorliegen, um die Auswirkungen von Soup auf die Sicherheitsanforderungen des Systems quantifizieren zu können, also belastbare Daten zur Betriebsbewährtheit, Fehlerhistorie und andere historische Daten. Man sollte zudem den Quellcode und die Testpläne anfordern, um die Software mit Werkzeugen zur statischen Codeanalyse zu prüfen. Auch wichtig sind detaillierte Einblicke in die Prozesse, die der Hersteller bei der Erstellung der Software angewendet hat. Alternativ kann ein externer Auditor bestätigen, dass die verwendeten Prozesse für die Sicherheitsanforderungen des Gerätes angemessen sind.

8. Zertifizierte Komponenten und ihre Hersteller

Auch die Verwendung von Komponenten, die bereits Sicherheitszertifizierungen vorweisen, können die Entwicklung und Validierung zwar beschleunigen und die Zulassung erleichtern. Doch Organisationen wie die FDA, MHRA und ihre Entsprechungen für andere Bereiche vergeben prinzipiell nur für fertige Geräte Zulassungen, nicht für Einzelkomponenten. Trotzdem können bereits zertifizierte Komponenten, z.B. der QNX Safe-Kernel zertifiziert nach IEC61508, den Zulassungsprozess massiv vereinfachen. Um diese Zertifizierungen zu bekommen, mussten diese Komponenten a) in einer Umgebung mit adäquaten Prozessen und Qualitätsmanagement entwickelt werden und b) sachgemäßen Tests und Validierungen unterzogen werden und c) muss der Hersteller die notwendigen Unterlagen zur Verfügung stellen, die wiederum die Zulassung des Gesamtproduktes unterstützen.

9. Auditoren

Auditoren kennen sich mit den notwendigen Prozessen aus und können helfen, den Sicherheitsnachweis zu strukturieren. Je eher Unternehmen Auditoren am Projekt beteiligen, desto weniger ist das Produkt später zu überarbeiten. Es erweist sich als sinnvoll, die für den Sicherheitsnachweis angedachte Struktur mit den Auditoren zu besprechen, ehe man beginnt, konkrete Nachweise zu führen.

10. Der Produkt-Release ist nicht das Ende

Doch die Verantwortung für ein sicheres System endet nicht mit dem Produkt-Release. Sie besteht so lange, bis das letzte Gerät außer Betrieb genommen wird. Besonders Updates können die Integrität von Software gefährden: In einer Studie hat die FDA festgestellt, dass 242 von 3.140 Rückrufaktionen zwischen 1992 und 1998 durch Softwarefehler ausgelöst wurden. Von diesen wurden 192, nahezu 80%, durch Fehler verursacht, die durch Wartung ins System eingebracht wurden. Die Fehler kamen also erst nach der Markteinführung in die Geräte. Prozesse müssen deshalb den gesamten Lebenszyklus der Geräte abdecken, inklusive Updates und Bugfixes. Eine sicherheitsorientierte Produktentwicklungsphilosophie ist daher wichtig, garantiert aber noch nicht, dass die entwickelte Software alle Verlässlichkeitsanforderungen erfüllt. Doch wenn in einem Unternehmen jeder Mitarbeiter die zehn goldenen Regeln befolgt, vereinfachen sich Zertifizierungs- und Marktzulassungsprozesse.

Hinreichende Verlässlichkeit

Kein System ist absolut zuverlässig. Daher muss zunächst festgelegt werden, was eine für das System ‚hinreichende Verlässlichkeit‘ wäre. Dies reduziert Entwicklungskosten und liefert Vorgaben, gegen die Entwickler die Sicherheitsaussagen validieren können. Ist unklar, welche Verlässlichkeit hinreichend ist, entsteht möglicherweise ein viel zu komplexes System, das sich gerade deshalb als fehlerhaft und anfällig erweist. Messehinweis: embedded world: Halle