Zur Sicherheit softwarebasierter Produkte

Die Sicherheit softwarebasierter Produkte hat sehr viele Facetten. Entsprechend groß ist auch die Angriffsfläche. Um diesen Themenkomplex aus möglichst vielen Richtungen zu beleuchten, hat der Arbeitskreis Qualitätsmanagement im Branchenverband Bitkom eine Gruppe von Experten zu den unterschiedlichsten Teilbereichen befragt. Entstanden ist ein Leitfaden, der – neben dem Status quo und einem Ausblick – auch eine Sammlung von FAQ enthält.

2016 erstmals aufgelegt, gelang es 2020 einer weitgehend neuen Autorengruppe, diesen Leitfaden gemeinsam zu überarbeiten und neue Aspekte hinzuzufügen. An dieser Stelle möchte ich Ihnen ausgewählte Beiträge aus dem neuen Ratgeber vorstellen und Sie zu einer intensiveren Beschäftigung mit dem Thema motivieren.

Version 2.0 des Bitkom-Leitfadens zur Sicherheit softwarebasierter Produkte

Wenn Software Fehler aufweist

Wenn ein hoher Aufwand betrieben wird, um grundsätzlich sichere Software herzustellen, und durch Updates und Patches Anpassungen an veränderte Gegebenheiten vorgenommen werden, stellt sich die Frage, warum Software denn trotzdem nie fehlerfrei ist. Grundsätzlich sind bei der Betrachtung von Softwarefehlern folgende Fälle zu unterscheiden:

  • Softwarefehler Typ 1: Die Software weicht von einer spezifizierten Eigenschaft ab, liefert beispielsweise ein anderes Ergebnis oder verhält sich anders als explizit beschrieben. Mit anderen Worten liegt die Abweichung gegenüber einer expliziten Anforderung vor.
  • Softwarefehler Typ 2: Ein Ergebnis oder das Verhalten der Software entspricht nicht den Erwartungen eines Nutzers. In diesem Fall liegt die Abweichung gegenüber einer impliziten Anforderung vor.

Auf die Entwicklungsmethodik kommt es an

Fehler des ersten Typs lassen sich mit Hilfe einer geeigneten Entwicklungsmethodik deutlich reduzieren. Dabei werden zunächst detaillierte Konzepte erstellt und noch vor ihrer Implementierung gründlich überprüft. Die Konzepte dienen den Entwicklern als zuverlässige Vorlage und ermöglichen ihnen erste Tests. Nachgelagert der Entwicklung kann die Software vor ihrer Nutzung daraufhin getestet werden, dass Verhalten und Ergebnisse mit den Konzepten übereinstimmen. Die Anzahl von Fehlern des ersten Typs (Abweichungen von expliziten Anforderungen) kann deutlich reduziert werden, was jedoch zusätzlichen Aufwand und Zeit erfordert.

Gestern noch akzeptabel – heute schon kritischer Error

Während Abweichungen von expliziten, dokumentierten Anforderungen zweifelsfrei als Fehler festgestellt werden können, ist dies schwieriger, wenn Erwartungen der Nutzer als Maßstab dienen. Dabei gibt es viele Anforderungen an eine Software, bei denen sich alle Nutzer einig sind:

  • Falsche Eingaben sollen nicht zu einem Absturz führen
  • Berechnungen sollen kein falsches Ergebnis ergeben
  • Personenbezogene Daten sollen nur den im Rahmen der vorgesehenen Anwendungsfälle autorisierten Nutzern zugänglich sein

Demgegenüber gibt es jedoch auch Erwartungen, die von Nutzer zu Nutzer unterschiedlich sein können:

  • Die Zeit bis zur wahrgenommenen Reaktion auf eigene Aktionen
  • Die Anordnung von Eingabe-Elementen auf einer Maske
  • Das Verhalten und mögliche Hilfestellungen bei falschen Eingaben
  • Die Dauer bis zu einem erzwungenen Passwortwechsel

Fehler dieses Typs sind nutzerspezifisch, d.h., was für einen Nutzer ein schwerer Fehler ist, sieht ein anderer Nutzer als noch akzeptabel an. Außerdem kann sich die Wahrnehmung mit der Zeit ändern – was gestern noch akzeptabel erschien, wird vielleicht heute als kritischer Fehler empfunden.

Zeit bleibt der größte Engpass

Verhindern lassen sich Fehler des zweiten Typs dadurch, dass alle Eigenschaften einer Software und ihres Verhaltens möglichst genau spezifiziert werden. Außerdem sollte exakt nach der Spezifikation entwickelt und die Einhaltung derer durch Tests überprüft werden. Gleichzeitig dürfen die (frühzeitig einbezogenen) Nutzer nicht mehr erwarten, als in der Spezifikation des Produkts beschrieben ist. Die Anzahl von Fehlern könnte mit Methoden der analytischen Qualitätssicherung (z.B. Tests), einem entsprechenden Budget und vor allem Zeit-Kontingent signifikant gemindert werden. Oft stellt sich dabei Zeit als größter Engpass dar.

Softwareentwicklung ist ein vergleichsweise junger Industriezweig. Qualitativ hochwertige, fehlerarme Software erfordert (noch) einen hohen Entwicklungsaufwand. Ein noch größeres Problem ist dabei jedoch die Zeit, die zur Entwicklung benötigt wird. In vielen Fällen wird Software entwickelt, weil man damit eine innovative Idee umsetzen und schneller als eventuelle Mitbewerber an den Markt bringen möchte. Manchmal geht es auch darum, auf Veränderungen des Marktes schneller zu reagieren als die Konkurrenz. Eventuell müssen auch gesetzliche Änderungen fristgemäß umgesetzt werden. Alle diese Fälle haben eines gemeinsam: Zeitdruck. Die Hersteller von Softwareprodukten werden also meist abwägen, ob sie für einen kurzfristigen Wettbewerbsvorteil und die schnelle Verfügbarkeit einer Software mögliche Fehler und Sicherheitslücken hinnehmen, oder ob sie in die Qualität ihrer Softwareprodukte investieren – mit anderen Worten, in welchem Maße überhaupt Konzepte erstellt und Tests durchgeführt werden sollen.

Mein Fazit

Selbstverständlich ist es eine vereinfachte Darstellung, dass bei der Softwareentwicklung entweder Fehlerfreiheit oder eine schnelle Markteinführung angestrebt werden kann. Es gibt vielversprechende Entwicklungen in Richtung neuer Programmiersprachen und -paradigmen, Standardisierung, Automatisierung und selbstverständlich auch einer optimalen Einbindung des Menschen in den Entwicklungsprozess, die sowohl die Produktivität des Entwicklungsprozesses als auch die Qualität der Softwareprodukte stetig verbessern werden.

Soweit mein erster Auszug aus dem Leitfaden. Wie ist Ihre Meinungen? Finden Sie, dass Softwarefehler zugunsten einer schnellen Verfügbarkeit von Features akzeptiert werden können?

 

Bild: Shutterstock

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.