Sieben Fragen zu mehr Software-Sicherheit und -Qualität

Anbieter zum Thema

MES Electronic Connect GmbH & Co. KG

ISH Ingenieursozietät GmbH

IBR Leiterplatten GmbH & Co. KG

Ein weiteres Thema sind OpenSource Programme. Auch hier wäre eine Zertifizierung des gesamten Codes notwendig. Weiterhin geht man damit ein Risiko ein, da dieser Programmierer aller Wahrscheinlichkeit nach keine Kenntnisse im sicherheitskritischen Umfeld vorweisen kann. Das ist jedoch laut Norm erforderlich und auch externe Mitarbeiter müssen entsprechend bewertet und angeleitet werden.

Wie können Softwareentwicklungsprozesse um sicherheitskritische Aspekte erweitert werden?

Zunächst einmal sollten Entwicklungsprozesse definiert sein. In der Softwareentwicklung ist das strukturierte Vorgehen der Entwicklung essentiell. Der Anfang liegt in der Spezifikation (Stichwort Requirements). Natürlich ist das jedem bekannt, oft auch beschrieben aber viele Software- Ingenieure kennen in der Praxis die Entwicklung auf Zuruf. Damit verwaltet der Entwickler letztlich die Anforderungen im Quelltext oder bestenfalls im Software- Lastenheft.

Die Abstimmung erfolgt dann am Prototypen, Änderungen sind entsprechend schwer einzupflegen. Ich habe schon oft Diskussionen über Produkteigenschaften am Prototyp verfolgt, wo es um elementare Eigenschaften ging. Darauf folgen dann diverse ad-hoc Änderungen, die sich im terminlich engen Rahmen befinden. Dieses Vorgehen sorgt für ein hohes Fehlerpotential, das sich durch die gesamte Entwicklung zieht. Letztlich kann ja auch nur richtig getestet werden, was ordentlich spezifiziert wurde.

An diesem Punkt setzen Prozessnormen an. Prozesse definieren, Abläufe strukturieren und die Entwicklung transparent und wiederholbar(er) zu gestalten. Hier möchte die IEC61508 einen Beitrag leisten, Normen und Richtlinien wie CMM oder ISO/IEC 15504 gehen noch einen Schritt weiter. Es muss klar sein, das diese Forderungen an Softwareentwicklungsprozesse das gesamte Unternehmen betreffen, nicht nur den Entwickler selber.

Die Herausforderung im Unternehmen liegt darin, verschiedene Prozessanforderungen zu harmonisieren. Das kann ISO9001, SPICE und IEC 61508 sein. Dazu können ähnliche Branchenanforderungen kommen (Beispiel Medizintechnik). Wichtig ist, dass die Prozesse so in das Unternehmen zu integrieren, dass sie unterstützend wirken und die Arbeit nicht behindern.

Wie lässt sich die Sicherheit von Software verbessern?

Was sicherheitsgerichtete Software ist, lässt sich schwer greifen. Es ist wesentlich mehr, als die Codierung nach bestimmten Richtlinien. Eine Software „sicher“ zu entwerfen und zu programmieren ist sehr projektbezogen. Es gibt jedoch einige Ansätze, die sich in vielen Projekten ähneln.

Funktionen, welche die Sicherheit unmittelbar oder mittelbar beeinflussen, sollten identifiziert und analysiert werden. Ist eine Funktion als sicherheitskritisch erkannt, werden Maßnahmen zur Fehlervermeidung und Fehlererkennung aufgezeigt. Dies muss nachvollziehbar und systematisch erfolgen und dokumentiert sein. Dafür bieten sich Methoden, wie eine Software- FMEA oder Fehlerbaumanalyse an.

Software kann prinzipiell nur Entwurfsfehler (systematische Fehler im Kontext der IEC61508) haben, sie kann nicht „zufällig“ ausfallen (wie beispielsweise Bauteile der Hardware). Diese werden durch strukturierte Entwicklung und geforderte Tests minimiert. Da jedoch Software in der Regel immer Restfehler beinhaltet, müssen weitere Maßnahmen zur Erkennung dieser Fehler im Betrieb implementiert werden.

Je nach geforderter Sicherheitsstufe sind Konzepte wie Redundanz, Diversität und Vergleich einzeln oder in Kombination sinnvoll. Sicherheitskritische Funktionen oder Berechnungen werden beispielsweise mit unterschiedlichen Ansätzen durch mehrere Funktionen (Diversität) auf mehreren Rechnern oder in unterschiedlichen Routinen (Redundanz) ausgeführt. Die Ergebnisse und Zwischenergebnisse werden verglichen.

(ID:320645)