Embedded-Software

Microconsult / Uli Österle

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.

Seite 1 von 3123