Den Drachen bändigen

Wenn wir auf Embedded-Systeme treffen, was jedem von uns jeden Tag unzählige Male passiert, gehen wir davon aus, dass diese Systeme sicher sind oder wir machen uns darüber schlichtweg keine Gedanken . Aber was bedeutet Sicherheit überhaupt? Wir unterscheiden grundsätzlich zwischen der sogenannten Betriebssicherheit (Safety) und der Zugangssicherheit (Security). Während Safety Menschen beim Umgang mit einem System schützen soll, ist Security der Schutz vor Menschen oder deren “Einbruchswerkzeugen”, also dem Missbrauch und unbefugtem Zugriff. Wenn man das Beispiel einer Eingangstür nimmt, wird der Unterschied schnell deutlich: Ein Klemmschutz, der Verletzungen verhindern soll, oder ein Sensor, der bei Gefahr eine Drehtür anhält, fallen in den Bereich Safety. Eine Überwachungskamera hingegen oder die Zugangsbeschränkung per Fingerprint sind eindeutig der Security zuzuordnen.

Zeitdruck zwingt Entwickler zum Pfuschen

„In vielen Firmen ist das Ziel der Software immer noch, dass sie einfach nur läuft – und das ist viel zu wenig“, erklärt Peter Siwon, Business Development Manager bei Microconsult. „Das ist so, als würde ich sagen: Hauptsache, das Auto fährt, und es ist mir egal, ob die Bremsen funktionieren oder der Scheibenwischer korrekt arbeitet.“ Dieter Volland, als Dozent für Softwareengineering ebenfalls bei Microconsult tätig, ergänzt: „Aufgrund von Zeitdruck sind Entwickler viel zu oft zum Pfuschen gezwungen.“ Um im Bild zu bleiben: Wir ziehen einen feuerspeienden Drachen auf und nehmen uns keine Zeit, ihm gute Manieren beizubringen, zum Beispiel keine Menschen anzuniesen.

Es fehlt an Wissen, wie man Sicherheitsanforderungen formuliert

Zu den größten Bedrohungen sowohl der Betriebssicherheit als auch der Security gehören ungetesteter Code, unerwünschte Wechselwirkungen in der Architektur und vor allem die mangelnde Qualifikation der Menschen, die für die Softwareentwicklung zuständig sind. Leider fehlt zu oft das Wissen, wie man Sicherheitsanforderungen formuliert und diese dann auch tatsächlich in die Software implementiert.

„Management hat die Safety oft nicht im Blick”

„Projektteams müssen frühzeitig dafür sensibilisiert werden, dass das Schreiben von Code im Grunde das Allerwenigste ist“, führt Peter Siwon aus. „Sicherheit kommt dadurch zustande, dass ich in der Lage bin, bestimmte Architekturmerkmale umzusetzen und Regeln einzuhalten, die diese Sicherheit unterstützen.“ Dieses Wissen wird in der Ausbildung oft nicht ausreichend vermittelt – und ist Quereinsteigern meistens gar nicht bekannt. Auch Frank Listing, Dozent für Softwareengineering bei Microconsult, sieht die unzureichende Ausbildung als Problem: „Ingenieure wie Elektrotechniker, Maschinenbauer oder Physiker sind fachlich meistens gut, aber bei der Softwareentwicklung gibt es oft Schwachstellen.“ Qualifikationsmängel sind auch der Grund für eine weitere Bedrohung: zugekaufte Software. Wer nicht in der Lage ist, betriebssichere Software zu entwickeln, kann auch bei zugelieferten Programmen nicht erkennen, ob die Sicherheitsanforderungen tatsächlich erfüllt werden. Dabei ist das Problem keinesfalls nur auf Entwicklerebene zu sehen. „Das Management hat die Safety oft nicht im Blick und meint, dieses als lästig empfundene Thema auf Externe abwälzen zu können“, beschreibt Dr. Günter Glöe, Experte für Softwaresicherheit, die alltägliche Praxis. „Oft fehlt es den Projektbeteiligten an Überblick und Sensibilität“, ergänzt Dieter Volland.

Lesen Sie auf der nächsten Seite, warum absolute Fehlerfreiheit illusorisch ist und Prüfarbeiten parallel zur Entwicklung laufen müssen.

Absolute Fehlerfreiheit ist illusorisch

Das mangelnde Bewusstsein für Safety ist umso erstaunlicher, wenn man die möglichen Konsequenzen bedenkt. Ein unzufriedener Kunde mag zu einem wirtschaftlichen Schaden führen. Auch das kann zu einem ernsthaften Problem werden, ist aber relativ harmlos im Vergleich zu einem Fall, bei dem aufgrund mangelnder Betriebssicherheit Menschen zu Schaden kommen. Hier muss auch der Entwickler mit drastischen Konsequenzen rechnen, wenn er Anforderungen nicht erfüllt hat. Umgekehrt macht es eine umfassende Dokumentation von Entwicklung und Test leicht, entsprechende Vorwürfe zu entkräften. „Entwicklern ist oft nicht bewusst, dass die Safety-Standards den Stand unserer Technik widerspiegeln und unsere Arbeit – wenn wir diesen Standards nicht gerecht werden – handwerklich mangelhaft ist“, erklärt Dr. Günter Glöe.

Da Normen für Entwickler schwer interpretierbar sind, ist es wichtig, die entsprechenden Auditoren frühzeitig in den Entwicklungsprozess einzubeziehen. „Sicherheitsstandards sind Kochrezepte für Elektronik und Software, die dem Stand der Technik entsprechen“, führt Günter Glöe aus. „So wie man Kochrezepte für die eigene Küche anpassen muss, muss man auch die Standards an den eigenen Bedarf anpassen.“ Und eine absolute Fehlerfreiheit ist nahezu illusorisch. „Zero Defects sind zwar wünschenswert, aber physikalisch nicht zu erreichen“, erklärt Prof. Dr. Jürgen Mottok, Scientific Head of Laboratory for Safe and Secure Systems in Regensburg. „Die Betriebssicherheit eines technischen Systems versteht sich als die Reduktion des Risikos auf ein (wirtschaftlich) vertretbares Maß. Damit verbleiben tolerierbare Restfehler in unseren technischen Systemen. Geeignete Fehlererkennung und -reaktionen müssen umgesetzt werden.“

Prüfarbeiten müssen parallel zur Entwicklung laufen

Aber wie kann man als Entwickler sichere und qualitativ gute Software entwickeln? Zunächst einmal muss man sich darüber im Klaren sein, dass Sicherheit und Qualität keine Zufallsprodukte sind – sie sind das Ergebnis gezielter Maßnahmen während des gesamten Entwicklungsprozesses. Man kann nicht am Ende des Prozesses Qualität hineintesten. Aufgrund der geforderten Sicherheitsstufe sollten in jeder Phase des Projekts (zum Beispiel Anforderungsanalyse, Design, Implementierung, Unit-Test, Integrationstest, Systemtest, Inbetriebnahme) geeignete Maßnahmen ergriffen werden, die einerseits die Erfüllung der Qualitätsanforderungen sicherstellen und andererseits durch geschickte Kombination dazu dienen, den Gesamtaufwand zu minimieren. „In fast allen Projekten ist die fehlende Verzahnung der Teststufen ein Problem“, erläutert Christian Nachreiner, Geschäftsführer Intence Automotive Electronics. „Dadurch können weiße Flecken in der Testabdeckung entstehen, die in einem Safety-Projekt nicht akzeptabel sind. Abhilfe schafft ein projektübergreifendes Testkonzept. Leider ist in vielen Unternehmen keine Rolle in der Entwicklung besetzt, welche die Tests auf allen Ebenen von der Implementierung bis zum Prüflabor betrachtet.“ Auch Dr. Günter Glöe sieht in mangelnder Planung des Testens eines der größten Probleme: „Ingenieurstätigkeiten unterscheiden sich vom Basteln auch dadurch, dass sie geplant ablaufen. Die Planung der Prüfarbeiten muss parallel mit der Entwicklung des Arbeitsproduktes laufen, gegen das geprüft wird.“

Embedded-Softwareentwicklung hinkt hinter Hardwareentwicklung her

„Sicherheit und andere Qualitätmerkmale müssen bereits Bestandteil des Systementwurfs sein“, so Peter Siwon. „Das fängt bei der Anforderungsanalyse an. Es geht weiter beim Design, wo geprüft werden muss, ob die Architektur überhaupt die Sicherheitsanforderungen abbilden kann. Es gibt Designs, bei denen man an der Struktur erkennen kann, dass die Sicherheitsanforderungen nicht erfüllbar sind.“ Auch bei der Implementierung müssen bestimmte Regeln eingehalten werden, um die Sicherheit zu garantieren. Es ist sinnvoll, in jeder Prozessphase darüber nachzudenken, wie man die Sicherheitsanforderungen erfüllbar machen kann. In vielen Fällen wird zu sehr implementierungsorientiert gedacht. Phasenorientierte Prüfschritte verzögern zwar die Implementierung, reduzieren aber gleichzeitig den Aufwand für große Korrekturschleifen, die sich durch den gesamten Entwicklungsprozess ziehen. Man sollte den Drachen nicht erst versuchen zu bändigen, wenn er bereits groß und stark ist. „In Bezug auf Sicherheit und Qualität hinkt die Softwareentwicklung noch hinter der Hardwareentwicklung her“, so Peter Siwon. „Viele Entwickler glauben, man könne in der Software schnell mal nachträglich etwas ändern, aber dafür sind viele Systeme bereits zu komplex.“

Lesen Sie auf der nächsten Seite, wie alle Projektbeiteiligten qualifiziert und informiert werden können.

Selbstbewusstsein und fachliche Sicherheit durch Workshops und Seminare

Aber die Integration in den Prozess alleine reicht auch noch nicht aus: Jeder der am Entwicklungsprozess Beteiligten muss sich seiner Rolle und seiner Verantwortung für die Systemsicherheit bewusst sein – und diese auch aktiv wahrnehmen . „Das richtige Maß an Motivation, Fachkompetenz und Verantwortungsbewusstsein ist ist dazu eine wichtige Voraussetzung “, erläutert Peter Siwon. „Und diese Kriterien lassen sich am besten durch eine professionelle Ausbildung und den regelmäßigen, offenen und auch kritischen Dialog der Schlüsselpersonen in Entwicklung und Management erfüllen.“ Spezialisten wie Microconsult bieten für alle Phasen und Rollen des Entwicklungsprozesses geeignete Maßnahmen (Seminare, Workshops, Beratung, Projektcoaching, Kongresse) an, mit denen Unternehmen die Risiken reduzieren und so Zeit und Geld sparen können. Die Verantwortlichen gewinnen dabei nicht nur an Selbstbewusstsein und fachlicher Sicherheit, sondern sind sich auch des Sinns und des Nutzens vieler Maßnahmen bewusster. Darüber hinaus haben sie die Gelegenheit, sich mit Spezialisten aus anderen Unternehmen auszutauschen. Dieser Blick über den Tellerrand bringt wertvolle Erkenntnisse und Anregungen für die eigene Projektarbeit.

Alle Projektbeteiligten qualifizieren und informieren

Die Themen Qualität und Sicherheit ziehen sich wie ein roter Faden durch den gesamten Entwicklungsprozess. In jedem Prozessschritt gibt es sinnvolle Maßnahmen, um Qualität abzusichern und Anforderungen an die Sicherheit zu überprüfen, zu validieren oder zu testen. Der erste Schritt zu sicherer und qualitativ hochwertiger Software ist die Schaffung des Bewusstseins ihrer Notwendigkeit für den nachhaltigen Projekterfolg.

Nur, wer sich der Bedeutung bewusst ist, wird sich mit der Problematik im Entwicklungsprozess auseinandersetzen und geeignete Aktivitäten starten. Eine der wichtigsten und ersten Maßnahmen besteht dabei darin, alle Projektbeteiligten ihrer Rolle und Verantwortung gemäß sinnvoll zu qualifizieren und zu informieren. Das garantiert zwar noch keine sichere Software, aber immerhin bestehen sehr gute Chancen, die Drachen so professionell zu zähmen, dass sie uns künftig viel Freude bereiten.

(jj)