Safety + Security – Softwareprüfung für „sichere“ Systeme

Sowohl Safety, die Betriebssicherheit, und Security, die Informationssicherheit, haben eine Relevanz bei der Konzeption und Umsetzung von vernetzten sicherheitskritischen Systemen. Die Betriebssicherheit ist seit langem durch verlustreiche Unfälle im Fokus der Politik und damit unter Anderem per Dekret beim Bau von beispielsweise Kraftfahrzeugen oder Werkzeugmaschinen gefordert.

Im aufkommenden Betrieb von vernetzten Maschinen im Rahmen der Industrie 4.0 und vernetzten Fahrzeugen gewinnt die Informationssicherheit eine immer größere Rolle. Durch ein angreifbares System können vertrauliche Daten, im Sinne von Betriebsgeheimnissen und Datensätzen, die persönliche Rückschlusse erlauben, in unbefugte Hände gelangen. Sollte ein sicherheitskritisches System ausfallen oder eine Fehlfunktion haben, können Unfälle mit hohem Sach- und Personenschaden entstehen.

Im Bereich der Safety gibt es wohldefinierte Standards, beispielsweise die IEC 61508 „Functional safety of electrical/electronic/programmable electronic safety-related systems“. Darin werden für verschiedene wichtige Systemkomponenten bestimmte Sicherheitsvorkehrungen gefordert sowie akzeptable Restrisiken definiert. Während der Planungsphase sind Risikoanalysen durchzuführen mittels deduktiven Verfahren wie die Fault Tree Analysis, um die Wahrscheinlichkeiten von unerwünschten Ereignissen in der Gegenwart von zufälligen Fehlern zu bewerten. Für die Implementierung von Software kann die Programmiersprache beziehungsweise der Dialekt vorgegeben werden, beispielsweise Ada für Projekte des US-Amerikanischen Verteidigungsministeriums. Grundsätzlich bleibt die Analyse der Gefährdungen sowie die Methoden zur Eingrenzung der Folgen über den Lebenszyklus konstant, da sich an dem Wirken des Systems nichts ändert.

Für die Softwareprüfung im Rahmen der Safety gibt es verifizierende und testende Verfahren. Bei den testenden Verfahren werden Testfälle entworfen und ausgeführt, um definierte Abdeckungen zu erreichen. Diese sind im Falle von „modified condition / branch coverage“ zwei Hauptziele. Zum einen wird gefordert, dass jeder Parameter einer Methode einen Einfluss auf den Ablauf der Methode oder deren Ergebnis hat, zum anderen, dass jede Verzweigung vom Ablauf ausgeführt wurde. Dies soll sowohl zu einer adäquaten Testabdeckung führen als auch nicht benutzten Programm-Code verhindern.

Die verifizierenden Verfahren werden benutzt, um zu beweisen, dass der Programm-Code bestimmte Eigenschaften aufweist, also beispielweise im Rahmen definierter Vorbedingungen zu einem korrekten Ergebnis führt. Die Verfahren in diesem Bereich beinhalten das Argumentieren mit dem Hoare-Kalkül auf dem Quelltext. Weitere, in dieser Arbeit nicht näher erläuterte Verfahren, beinhalten Model-Checking, Software Model-Checking und Separation Logic.

Bei der Benutzung vom Hoare-Kalkül werden Tripel benutzt, bestehend aus Vorbedingung, Programm-Fragment und Nachbedingung. Beispielsweise ist das Programm-Fragment eine Methode im Quelltext zum Berechnen der Quadratwurzel, mit der Vorbedingung, dass der Methodenparameter größer Null ist, und der Nachbedingung, dass eine positive Zahl ausgegeben wird, die die Quadratwurzel des Parameters ist. Das Programm-Fragment wird auf dem Quelltext hinsichtlich der Vor- und Nachbedingungen nach den Regeln der Mathematik und Logik durchgearbeitet. Diese Hoare-Tripel können verkettet werden, sofern die Vor- und Nachbedingung der Tripel miteinander vereinbar sind. Ist dies für das gesamte Programm möglich, ist bewiesen, dass es für die erlaubten Eingaben korrekt ist.

Im Rahmen der Security gibt es keine konkreten gesetzlichen Vorgaben und das Modellieren von gezielten Falscheingaben und/oder Angriffen ist schwierig. Die Abgrenzung vom System zu Umwelt im Rahmen vernetzter Systeme, beispielsweise in der Industrie 4.0 oder mit kommunikationsfähigen Fahrzeugen, ist unscharf. Durch das stärkere Vernetzen von sicherheitskritischen Systemen, beispielsweise Steuerungsanlagen, um Metriken auslesen zu können, deren Analyse einen effizienteren Betrieb ermöglichen kann, wird ein größeres Netzwerk – oder sogar das Internet – ein Teil des Systems. In diesem Rahmen ist eine vollständige Verifikation oder Testabdeckung nicht wirtschaftlich möglich und dementsprechend werden andere Verfahren eingesetzt. Beim System-Entwurf und der Umsetzung sollte von daher beispielsweise „Defense in Depth“ praktiziert werden, eine Unterteilung der Systemkomponenten in verschiedene Teilnetzwerke und eine mehrfache Absicherung über Firewalls und Validierung ein- und ausgehender Daten.

Für das Testen von Software kann unter anderem Penetration-Testing, bei dem bekannte Schwachstellen ausprobiert werden, und Fuzzing benutzt werden. Beim Fuzzing werden zufällige Testeingaben generiert, um Eingaben zu finden, die nicht korrekt behandelt werden. Dadurch kann es zum Absturz des Programms oder tiefer greifenden Sicherheitslücken wie einem Buffer Overflow kommen. Nachdem ein vollständiges Testen aller Eingabemöglichkeiten aufgrund der großen Menge nicht möglich ist, kann das Testen in diesem Kontext keine absolute Gewissheit bringen. Eine Verifikation wie bei der Safety ist nicht ohne weiteres möglich, da eine exponierte Komponente keine Vorbedingungen für die Eingaben stellen kann.

Die Softwareprüfung für „sichere“ Systeme ist von großer Bedeutung, da dadurch Gefahren für Leben und Eigentum abgewendet werden können. Der Bereich der Safety ist etabliert und kann mit entsprechendem Aufwand auch für Software angewendet werden. Im Rahmen der Vernetzung dieser safety-kritischen Anwendungen gewinnt die Security an Bedeutung, da die physikalische Trennung aufgehoben wird und somit mögliche Angreifer an das System herankommen. Der etablierte Bereich der IT-Sicherheit für normale Endnutzer-Anwendungen ist im Kontext von Industriesteuerungen oder medizinischen Geräten nicht anwendbar, da Methoden wie Deep Packet Inspection oder Virenscanner nicht tolerierbare Verzögerungen in den Ablauf des Systems bringen können.

Zudem wurde im Vortrag erwähnt, dass ein erhöhter Preis für eine bessere Security von einem System schwer bis nicht absetzbar ist. Zudem setzen die Entwickler ein nicht gerechtfertigtes Vertrauen in proprietäre Protokolle und Schnittstellen, ohne die tatsächliche Kommunikation der Teilkomponenten sicher zu gestalten, wie von Yu et al. erwähnt wurde. Dies führt zu Fahrzeugen, die über den Debug-Port des Fahrzeugs oder sogar über die Drahtlosverbindung manipuliert werden können. Mögliche Folgen davon sind die Ermöglichung von Diebstahl und unerlaubtem Verfolgen der Fahrtroute sowie eine mögliche Beeinträchtigung der Safety. Wie von Wired berichtet wurde, kann über das Internet die Funktion diverser Komponenten beeinträchtigt werden. Diese beinhalten die Infotainment-Anlage und sicherheitskritische Teilsysteme, beispielsweise die Bremsen oder das Getriebe.

Auch in der Medizintechnik werden die Geräte zunehmend kommunikativ, was sowohl Vorteile hat als auch Risiken birgt. So kann beispielsweise ein Herzschrittmacher, ohne Eingriff am oder im Körper, während sportlicher Aktivitäten auf eine andere Frequenz eingestellt werden. Andererseits gibt es auch die Möglichkeit, diese Geräte anzugreifen, wie im Artikel der BBC erwähnt wird.

Für Safety gibt es etablierte Analyse- und Testverfahren, deren Betrachtung über den Lebenszyklus hinweg gültig bleibt, die teilweise vorgeschrieben sind und generell einen Aufpreis rechtfertigen können. Bei der Security gilt dies nicht, da alle Teile, die mit dem System interagieren, relevant sind und sich dieses Umfeld während dem Lebenszyklus ändern kann, zudem gibt es ein geringeres Bewusstsein für Security, wie man im Umfeld des Handymarktes mit veralteten Android-Versionen sehen kann. Durch die bisherige physikalische Trennung der Systeme war Security bei vielen sicherheitskritischen Systemen nicht direkt relevant. Durch die aktuelle Entwicklung, dass alles immer stärker vernetzt wird, gewinnt die Security in vielen Gebieten an Bedeutung, die allerdings aufgrund des Kostenfaktors in der Entwicklung bisher eher vernachlässigt wird.

• HOARE, Charles Antony Richard. An axiomatic basis for computer programming. Communications of the ACM, 1969, 12. Jg., No. 10, S. 576-580.
• KUIPERS, David; FABRO, Mark. Control systems cyber security: Defense in depth strategies. United States. Department of Energy, 2006.
• YU, Lu, et al. Automobile ECU design to avoid data tampering. In: Proceedings of the 10th Annual Cyber and Information Security Research Conference. ACM, 2015. S. 10.
• Hackers remotely kill a jeep on the highway. https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ Zuletzt abgerufen am 2017-03-01.
• Could hackers break my heart via my pacemaker? http://www.bbc.com/news/technology-34899713 Zuletzt abgerufen am: 2017-03-01.
• Fuzzing in the Open Web Application Security Project, https://www.owasp.org/index.php/Fuzzing , Zuletzt abgerufen am: 2017-03-01.

Dieser Beitrag entstand nach einem Vortrag im Rahmen der Ringvorlesung „Forum Software und Automatisierung“ am IAS.

Vortragsdatum: 10.11.2016
Vortragender: Dr. Thomas Liedtke, ICS AG
Vortragstitel: Softwareprüfung für „sichere“ (Safety + Security) Systeme