Software - Sicherheit

Als 1996 die erste Ariane-5-Rakete nach nur 37 Sekunden über den Mangrovensümpfen von Französisch-Guyana explodierte, war ein Software-Fehler schuld: Die Raketenbauer hatten ein Modul der Ariane 4 ungeprüft übernommen. Dieses rechnete die Geschwindigkeit der Rakete von einer langen Fließkommazahl in ein kürzeres Datenformat um. Bei der Ariane 4 kein Problem, denn hier konnte die Zahl nie größer ausfallen als die Obergrenze des kurzen Formats. Bei der stärkeren Ariane 5 passierte dies schon nach einer halben Minute, und der Computer streikte. Der Schaden: über eine halbe Milliarde Euro.

Das drastische Beispiel illustriert, warum die Anforderungen an eine sichere Funktionsweise der Software immer höher werden. Doch wie überprüft man die Fehlerfreiheit? "Früher geschah dies durch Walk-through mit einem erfahrenen Kollegen", erläutert Reinhold Achatz, Leiter der Abteilung Software & Engineering bei Siemens Corporate Technology (CT). "Bei der Komplexität der Systeme müssen wir uns heute aber Alternativen überlegen, sonst würde die Software erst Jahre nach der Hardware fertig."

Software-Ingenieure schauen zunächst, ob die Regeln der verwendeten Sprache, also deren Syntax, eingehalten wurden. Bei einer sicherheitsrelevanten Anwendung erfolgt zusätzlich eine formale Verifikation der Logik des Programmablaufs. Beide Prüfmethoden wollen die Experten nun beschleunigen, denn das Testen gehört zu den größten Zeitfressern. "Bei großen Software-Projekten verschlingen Tests und ungeplante Fehlerkorrekturen bis zu 80 % des Zeitbudgets", sagt Achatz.

Teure Investitionsgüter wie Flugzeuge und Kraftwerke arbeiteten früher bei kritischen Steuersystemen mit redundanten Anlagen. Für zwei oder drei Hardware-Plattformen wurden unabhängig voneinander Codes entwickelt. Der Nachteil: Mehrere Entwicklerteams werden benötigt, und trotzdem können sich Fehler von der Konzeption bis zum Programm durchschleppen. Viel lieber wäre den Ingenieuren eine akkurate Umsetzung, wie sie die Programmierung über spezifische Modellsprachen bietet.

Wörterbuch für jedes Problem. So soll das so genannte Model Driven Development (MDD) Technik und Software näher zusammenrücken (siehe Programmierung). Eine firmenübergreifende Plattform koordiniert das Vorgehen (www.omg.org). "Ob beim Autoradio oder einer Weichensteuerung – bislang mussten sich Programmierer mit ein und derselben Sprache begnügen. MDD stellt für jedes technische Problem quasi ein eigenes Wörterbuch bereit", sagt Andrey Nechypurenko von Siemens CT. Zur Beschreibung jeder Aufgabe wird eine Modellsprache entwickelt. Die Symbole im Flussdiagramm sind aufgabenspezifisch. "Ingenieure reden nicht in Schleifen oder Aufrufen, sondern sie haben ihre eigene Sprache, um Ventile zu öffnen oder Motoren anzufahren", sagt Nechypurenko. Das eigentliche Programmieren übernehmen Software-Agenten. "Dadurch sinkt die Zahl der Fehler, weil weniger Code von Hand geschrieben werden muss", sagt Rainer Hochecker, Manager bei IBM. "Wir haben mit MDD ein 40-Monats-Projekt in 21 Monaten realisiert. Die Anzahl der Fehler sank um den Faktor 17." Noch sind weltweit erst wenige große Softwareprojekte mit MDD verwirklicht worden, denn die Entscheidung für ein neues Verfahren bedeutet immer eine langfristige Bindung. "Die ersten Erfahrungen in realen Projekten sind vielversprechend", sagt Martin Rothfelder von CT. "In ein bis zwei Jahren ist die Technik reif für den Einsatz".

Mit ähnlichen halbautomatischen Werkzeugen analysieren Sicherheitsspezialisten den Code auf mögliche Schwachstellen. Dabei jagen die Experten nicht nur den klassischen "Bug", der Computer zum Absturz bringen kann. Es geht ihnen auch um Design-Fehler, die ein verstecktes Risiko darstellen und die schon bei der Auslegung passiert sein können. So müssen Siemens-Anwendungen im Bankensektor Dutzende kreuz und quer geschaltete verschlüsselte Kommunikationslinien verwalten können, ohne dass ein möglicher Angreifer eine Chance hat, die vertraulichen Botschaften zu dechiffrieren.

Einer der Wissenschaftler, mit dem Siemens bei Sicherheits- und Zuverlässigkeits-Technologien zusammenarbeitet, ist Prof. Peter Liggesmeyer, Institutsleiter am Fraunhofer-Institut für Experimentelles Software Engineering in Kaiserslautern. Liggesmeyer beschäftigt sich vor allem mit der Sicherheit von eingebetteter Software, etwa im Auto. "Die in der Praxis verbreiteten Analysemethoden können mitunter wichtige Fragestellungen nicht beantworten". So könne etwa mit Fehlerbaumanalysen nicht entschieden werden, ob Datenverarbeitungen schnell genug vonstatten gehen. "Fehlerbäume verknüpfen Ursachen und Wirkungen, etwa beim Ausfall von Systemkomponenten – jedoch ohne Zeitaspekte zu berücksichtigen". Für solche Probleme entwickelt Liggesmeyers Forschergruppe Werkzeuge. "Zu Beginn eines Projekts ist der Aufwand bei den neuen Ansätzen höher, weil viel Energie in saubere Beschreibungen gesteckt werden muss", sagt der Lehrstuhlinhaber für Software-Engineering. "Dafür ist man später aber nicht gezwungen, mit der heißen Nadel Fehler zu reparieren". Weiterer Vorteil: Ein sorgfältig realisiertes und geprüftes Modul kann leichter wiederverwendet werden. Vorausgesetzt, das Zusammenspiel mit neuen Komponenten wird - anders als bei der Ariane 5 - entsprechend berücksichtigt.

Bernd Schöne