Kategorien

Safety und Security, aber wo ist der Unterschied?

Den genauen einen Unterschied zwischen Safety und Security zu kennen ist die erste Voraussetzung für ein effektives Embedded-Systems-Design in einer vernetzten Welt des heutigen Alltags. Beide Aspekte der Sicherheit sind eng miteinander verknüpft.
 
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. Ausfiltern von Defekten. Gutes Hard- und Software-Design setzt voraus, dass während des gesamten Designprozesses mehrere Qualitätssicherungs-, Absicherungs- und Schutzmaßnahmen angewandt werden.
 
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. 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 katastrophaler 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. 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.
 
Natürlich müssen hierbei 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:
 
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.
Günstige Software Angebote finden Sie bei uns im Online-Shop.
Bitte geben Sie die Zahlenfolge in das nachfolgende Textfeld ein

Die mit einem * markierten Felder sind Pflichtfelder.