Den Drachen bändigen – Sichere Software von Anfang an (Teil 1)

Entwickler unter Zeitdruck

So wie in alten Mythen Drachen die Menschen plagten und ihr Leben bedrohten, stellen heute technisch unsichere Systeme eine Gefahrenquelle dar. Der entscheidende Unterschied: Während die Drachen in das Reich der Fabeln gehören, sind technische Systeme als potentielle Gefahrenquellen Teil unseres Alltags.

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 so genannten 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.

In vielen Firmen ist das Ziel der Software immer noch, dass sie einfach nur läuft – und das ist viel zu wenig. Das ist so, als würde man sagen: Hauptsache, das Auto fährt, und es ist mir egal, ob die Bremsen funktionieren oder der Scheibenwischer korrekt arbeitet. 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, wie beispielsweise 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 eine 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. Sicherheit kommt dadurch zustande, dass man in der Lage ist, 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. Ingenieure wie Elektrotechniker, Maschinenbauer oder Physiker sind fachlich meistens gut, aber bei der Software-Entwicklung 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 Entwickler-Ebene 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. Oft fehlt es den Projektbeteiligten an Überblick und Sensibilität.

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.

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. 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. 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.

Der zweite Teil der Beitragsreihe wird detailliert darauf eingehen, dass Sicherheit und Qualität keine Zufallsprodukte sind, sondern das Ergebnis gezielter Maßnahmen während des gesamten Entwicklungsprozesses. Im dritten Teil geben Embedded-Experten Ratschläge und Statements zu Qualität und Sicherheit.

Mehr lesen

Den Drachen bändigen – Sichere Software von Anfang an:
Teil 2 „Alle Projektbeteiligten qualifizieren und informieren“

Den Drachen bändigen – Sichere Software von Anfang an:
Teil 3 „Ratschläge und Statements zu Qualität und Sicherheit“

Weiterführende Informationen

MicroConsult Training & Coaching zum Thema Qualität, Safety & Security

MicroConsult Fachwissen zum Thema Qualität, Safety & Security

Peter Siwon: Systemisches Projektmanagement

Veröffentlicht von

Peter Siwon

Peter Siwon

Dipl.-Ing. Peter Siwon ist freier Mitarbeiter bei MicroConsult. Er lernte die Projektarbeit im Laufe seiner beruflichen Entwicklung aus vielen Perspektiven kennen: Forschung, Entwicklung, Projektleitung, Vertrieb, Marketing und Geschäftsführung. Seit 2008 gibt er sein Wissen und seine Erfahrungen als Trainer, Coach, Lehrbeauftragter und Autor von Vorträgen, Kolumnen, Fachartikeln und Büchern weiter. Seine Vorträge und Seminare wurden bereits mehrfach ausgezeichnet. Sein Themenspektrum umfasst klassische, agile und systemische Projektmanagement-Ansätze, Kommunikation, Führung, Teamentwicklung und Konfliktlösung im Projektumfeld. Die vielen Fallbeispiele aus der Praxis seiner Kundinnen und Kunden sowie seine aktive Mitwirkung in Projekten liefern ihm immer wieder neue Impulse und Erkenntnisse für seine Tätigkeit. Darüber hinaus erweitert Peter Siwon sein Wissen durch regelmäßige Aus- und Weiterbildung - gerne blickt er dabei über den Tellerrand. Aus der Überzeugung heraus, dass die Projektarbeit maßgeblich durch menschliche Faktoren beeinflusst wird, gilt sein besonderes Interesse der menschlichen Seite des Projekterfolgs. Mehr Informationen zu Peter Siwon und Kundenmeinungen zu seiner Arbeit finden Sie unter www.systemisches-projektmanagement.info.