Risikofaktor nicht sichere Software
Unter nicht-sicherer Software verstehen wir jede Software, die in ein sicherheitsbezogenes Produkt integriert ist, selbst jedoch nicht nach einem passenden Sicherheitsstandard entwickelt worden ist. Damit ist nicht gesagt, dass diese Software fehlerhaft sein muss. Doch ein weniger strenges Design oder fehlende Dokumentation können dazu führen, dass mögliche Seiteneffekte (Ressourcenzugriff, Wartezeiten) nicht erkannt werden. Das Argument, die Komponente sei bisher ohne Probleme eingesetzt worden, reicht im Kontext funktionaler Sicherheit nicht aus. Die Lösung kann entweder sein, die vorhandene Komponente zu überarbeiten und entsprechend zu testen, oder ihre Verwendung so zu steuern, dass die sicherheitsgerichtete Software soweit wie möglich unabhängig ist. Diese Rückwirkungsfreiheit kann nur durch Planung auf Ebene der Softwarearchitektur erreicht werden. Als zusätzliche Sicherheitsmaßnahme müssen Kontrollen umgesetzt werden, die die Annahmen über die nicht-sicheren Teile prüfen und gegebenenfalls eine sichere Reaktion ausführen.
Risikofaktor Umgebung
Software wirkt nur durch die Verbindung mit Hardware auf die physische Umgebung ein. Generell darf sich eine sicherheitsgerichtete Software nie darauf verlassen, dass Hardwareelemente wie Speicher, Sensoren oder Bussysteme korrekt funktionieren. Es ist Aufgabe der Software, einen angemessenen Grad an Diagnosen durchzuführen, und eine passende Reaktion auf eventuelle Probleme zu definieren. Gleiches gilt für die ausführende Umgebung im Mikrocontroller. Hier kann es zu Problemen im zeitlichen Verhalten des Programms kommen, oder auch zu falschen Sprüngen innerhalb der Software. Sofern die Hardware nicht explizit für sicherheitsbezogene Anwendungen freigegeben und somit robust genug ist, muss auch hierfür eine Diagnose umgesetzt werden um Probleme zu erkennen und zu behandeln. In diesen Fällen ist es zwingend notwendig, dass ein entsprechender Informationsfluss an alle Abnehmer der Daten vorgesehen und gewährleistet ist. In einem entkoppelten Softwaredesign wird ein Hardwarefehler oft in einem Modul entdeckt werden, das keine Information über die Auswirkung des Problems und die angemessene Reaktion besitzt. Indem wir passende Schnittstellen und Informationsflüsse einbringen stellen wir sicher, dass die Fehlerinformation dorthin übermittelt wird, wo diese Entscheidung getroffen werden kann.
Fazit
Nach unserer Erfahrung entstehen kritische Softwarefehler am häufigsten durch unvorhergesehene Abhängigkeiten zwischen zwei verschiedenen Teilen der Implementation. Die konsequente Kapselung durch eine modulare Architektur hat sich als effektives Mittel bewährt, dieses Risiko zu vermeiden. Zusätzlich setzen wir konsequent Unittests und methodische Reviews ein, um Implementierungsfehler zu finden.
