Software-Sicherheit, Teil 1 Die drei Gesichter der Sicherheit von Embedded-Software-Systemen
Anbieter zum Thema
Sicherheit von Software-Systemen umfasst mehr als nur die Betriebssicherheit. Im ersten Teil dieser Serie zum Thema Software-Sicherheit stellen wir Ihnen drei besonders wichtige Regeln vor.

Elektroautos sind derzeit in aller Munde, was sich auch in der näheren Zukunft nicht ändern wird. Woran aber kaum jemand denkt: Ein Elektroauto bezieht seine Energie aus einer gezähmten Brandbombe. Auch sonst handelt es sich um ein System mit erheblichem elektrischen Gefahrenpotenzial. Die Betriebssicherheit (Safety) wird vor diesem Hintergrund vor große und neue Herausforderungen gestellt. Das gilt im besonderen Maß für die Software der Steuergeräte dieser Fahrzeuge.
Software-Sicherheit nach der Norm IEC 61508
Der Aspekt Sicherheit reicht bei Zukunftstechnologien dieser Tragweite weit über die Betriebssicherheit hinaus. Neben Safety spielen Software-Security, also der Schutz vor unbefugten Zugriffen, beispielsweise durch Hacker, und die Zukunftssicherheit eine entscheidende Rolle. Auf dem Embedded Software Engineering Kongress 2011 wurden verschiedene Aspekte um diesen Themenkomplex beleuchtet.
Mit diesem ersten Beitrag fassen wir in einer Rückschau wichtige Aussagen der damaligen Referenten rund um die Betriebssicherheit zusammen. Sicherheit hat viele Gesichter. Laut Definition in der Norm IEC 61508 ist Sicherheit die Bezeichnung eines Zustands, der frei von unvertretbaren Risiken der Beeinträchtigung und mithin als gefahrenfrei anzusehen ist.
Vermeintlich sichere Embedded-Software-Systeme ?
Doch wie zeigt sich, ob beispielsweise ein technisches System, das auf Embedded Software beruht, hinreichend sicher ist? Immerhin erweisen sich vermeintlich sichere Systeme leider immer wieder als unsicher oder gar gefährlich.
Die Aussage über das Elektroauto wird übrigens sinngemäß einem Chefentwickler aus der Automobilindustrie zugesprochen. Doch das Potenzial an Gefährdungen ist schwer zu übersehen. Zumal wenn Gefahrenquellen vorab noch gar nicht bekannt sind oder wenn nicht klar ist, in welchen Situationen ein System sich zu bewähren hat.
Weil man im Vorfeld kaum sagen kann, wo später im Betrieb eines Systems die Quellen einer Gefährdung oder Fehlfunktion liegen werden, ist es von größter Bedeutung, nach dem Stand der Wissenschaft und Technik zu entwickeln. Die notwendige Sicherheit ist mit den derzeit verfügbaren Mitteln zu realisieren.
Drei Regeln, die Softwarequalität zu verbessern
Mit welchen Möglichkeiten lässt sich die Betriebssicherheit von Software-Systemen schon in der Entwicklung verbessern? Im Grunde besteht die Anforderung darin, gewisse Regeln umzusetzen. Drei wichtige Regeln hat Karl Nieratschker, freiberuflicher Trainer bei MicroConsult in seinem Vortrag auf dem ESE Kongress herausgehoben.
Es gibt verschiedene Möglichkeiten, um die Softwarequalität zu verbessern. Einerseits besteht ein wichtiger Teil der Kunst darin, sich zu beschränken. Meint nichts anderes als auf gefährliche Konstrukte entweder zu verzichten oder sie nicht zuzulassen.
Vereinfachte Syntax als Lösung für weniger Fehler?
Zum anderen leistet eine vereinfachte Syntax einen wertvollen Beitrag. Dadurch lassen sich Programme leichter schreiben und lesen. Ein einfaches und wirksames Mittel, dessen Wichtigkeit häufig unterschätzt wird. Das Potenzial der Syntaxvereinfachung besteht darin, Fehler durch gute Übersicht gar nicht erst entstehen zu lassen.
Zu guter Letzt sollten zusammengehörende Dinge bei der Entwicklung zusammengefasst werden. Das sorgt für ein leichteres Verständnis und besseren Überblick.
Vorgenannte Regeln gelten ganz allgemein in der Softwareentwicklung, die objektorientierten Programmiersprachen sind bereits mit Bordmitteln ausgestattet. So unterstützt C++ beispielsweise die Umsetzung der Regel, dass zusammengehörende Dinge bei der Entwicklung zusammengefasst werden sollen, Aufzählungstypen können beispielsweise innerhalb einer Strukturdefinition angelegt werden, ohne dass dies Speicherplatz kostet.
Aber C++ bietet ganz pragmatische Verbesserungen in Bezug auf die Betriebssicherheit der Software im praktischen Einsatz. So können Pointer, die häufig Fehler in der Codeerstellung mit sich bringen, oft durch Referenzen ersetzt werden, was zur Syntaxvereinfachung beiträgt und sogar Sicherheitsabfragen überflüssig machen kann.
Artikelfiles und Artikellinks
Link: Dossier Softwaresicherheit, Teil 2: Software-Security in Embedded-Systemen
Link: Dossier Softwaresicherheit, Teil 3: Zukunftssicherheit von Software
Link: Microconsult: Qualität und Sicherheit in Software
Link: Fachwissen: ISO 26262 – konforme Komponenten ohne Laufzeitfehler
Link: Video: ISO 26262 – Fluch oder Segen?
Link: ESE Kongress: Deutschlands größter Kongress für Embedded Software Engineering
(ID:31147360)