Software-Entwicklung

Keine Safety ohne Security

18. April 2017, 10:42 Uhr | Von Dan Smith und Andrew Girson

Den Unterschied zwischen Safety und Security zu kennen ist die erste Voraussetzung für ein effektives Embedded-Systems-Design in einer vernetzten Welt. Beide Aspekte der Sicherheit sind eng miteinander verknüpft. Tipps für die Entwicklung vernetzter Systeme.

Beim Design guter Embedded Software wurden Safety- und Security-Aspekte schon immer beachtet. Die Vernetzung hat jedoch dazu geführt, dass in Safety-kritischen Anwendungen wie zum Beispiel Medizintechnik, autonomen Fahrzeugen und Internet-of-Things-Geräten inakzeptable Sicherheitslücken entstanden sind. Die enge Verflechtung von Safety und Security hat im Verbund mit dem gesteigerten Bedrohungsgrad zur Folge, dass Entwickler den Unterschied zwischen Safety und Security grundlegend verstehen und mit bewährten Verfahren sicherstellen müssen, dass beide beim Design eines Produkts von Anfang an berücksichtigt werden (Bild 1).

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Das IoT macht Systeme anfällig gegen Aktionen aus der Distanz. Ein vor einiger Zeit bekannt gewordener Fall betraf vernetzte Überwachungskameras von Sony, bei denen Backdoor Accounts gefunden wurden [1]. Hacker konnten die Systeme über diese Ports mit Botnet-Malware infizieren und weitere Attacken starten. Ein danach von Sony entwickelter Firmware Patch kann von Anwendern heruntergeladen werden, um diese Hintertür zu verschließen. Viele andere Fälle von Programmier- oder Designfehlern sind dagegen nicht behebbar und möglicherweise katas-trophaler Natur.

Um dies zu belegen, hackten zwei Sicherheitsforscher ein fahrendes Auto. Sie konnten dabei die Kontrolle sowohl über die Armaturentafel als auch über Lenkung, Getriebe und Bremsen übernehmen [2]. Dieser Hack erfolgte nicht in böser Absicht, sondern mit Einwilligung des Fahrers. Die Forscher wollten lediglich demonstrieren, wie einfach sich die Netzwerkverbindung kapern ließ. Gleichwohl hatte dieser Hack den Rückruf von 1,4 Millionen Fahrzeugen zur Folge.

Kleine Fehler, große Wirkung

Natürlich müssen Systeme keine Internetverbindung besitzen, um anfällig und unsicher zu sein. Mangelhaft geschriebener Embedded-Code und falsche Designentscheidungen haben schon früher ihren Tribut gefordert. Ein Beispiel ist das 1983 zur Krebsbekämpfung eingeführte Strahlentherapiegerät Therac-25, das mittlerweile zu einem anerkannten Fallbeispiel dafür geworden ist, was man beim Systemdesign nicht tun sollte. Software-Fehler führten zusammen mit fehlenden Hardware-Schaltsperren und allgemein falschen Designentscheidungen dazu, dass tödliche Strahlendosen verabreicht wurden. Als Haupt-Übeltäter im Fall Therac-25 wurden ermittelt:

ein unausgereifter und unzureichender Software-Entwicklungs-Prozess (nicht prüfbare Software),
unvollständige Zuverlässigkeits-Modellierung und Ausfallarten-Analyse,
keine (unabhängige) Prüfung kritischer Software,
unkorrekte Wiederverwendung von Software aus älteren Modellen.

Zu den Haupt-Ausfallarten gehörte ein 1-Byte-Zähler in einer Prüfroutine, der häufig überlief. Machte ein Bediener während eines solchen Überlaufs manuelle Eingaben am System, versagte die Software-basierte Schaltsperre des Systems.
Im Juni 1996 wich Flug 501 der Ariane-5-Rakete von ihrem vorgesehenen Kurs ab und zerstörte sich daraufhin selbst. Der Grund: Überlaufprüfungen waren aus Effizienzgründen weggelassen worden. Kam es bei einer Variablen, die die Horizontalgeschwindigkeit enthielt, zu einem Überlauf, gab es keine Möglichkeit, diese zu erfassen und entsprechend zu reagieren.

Immer noch kommt es vor, dass kritischer Code und Sicherheitslücken ungeprüft bleiben. Die „Embedded Systems Safety and Security Survey“ 2016 der Barr Group ergab folgende Erkenntnisse über Ingenieure mit Projekten, die mit dem Internet verbunden sind und bei einem Hacker-Angriff tödlich sein können:

50 % wandten keine Codierstandards an
17 % nahmen niemals Codeprüfungen vor
24 % nahmen vielleicht Codeprüfungen vor
Mehr als ein Drittel nutzten keine statische Analyse

Definition von Safety und Security

Die beiden Begriffe Safety und Security werden häufig vermengt. Viele Entwickler glauben auch fälschlicherweise, guter Code sei sowohl ‚safe‘ als auch ‚secure‘. ‚Safe‘ ist ein System dann, wenn von ihm im normalen Betrieb keine Gefahren für den Benutzer oder andere Personen ausgeht. Ein ‚Safety-kritisches‘ System ist somit eines, das bei einer Fehlfunktion Menschen verletzen oder töten kann. Dem Designer obliegt es hier, so weit wie möglich sicherzustellen, dass es im System zu keinen Fehlfunktionen oder Ausfällen kommt.

Security hat dagegen in erster Linie mit der Fähigkeit eines Produkts zu tun, seine Ressourcen autorisierten Benutzern zur Verfügung zu stellen und jegliche unberechtigte Nutzung (beispielsweise durch Hacker) zu verhindern. Mit Ressourcen sind hier im Fluss befindliche oder dynamische Daten, Code, Intellectual Property (IP), Prozessoren, Systemsteuerungs-Zentralen, Kommunikations-Ports, Speicher und Massenspeicher mit statischen Daten gemeint.

Hier sollte langsam klar werden, dass ein System, das ‚secure‘ ist, nicht unbedingt auch ‚safe‘ sein muss. Ein gefährlich konstruiertes System kann genau so secure sein wie ein safe entwickeltes System. Dagegen ist ein System, das nicht secure ist, auch niemals safe. Selbst wenn es zunächst funktionssicher, also safe ist, kann es wegen seiner Anfälligkeit gegen unbefugten Zugriff jederzeit unsafe werden.