Mehr Sicherheit durch weniger Geheimhaltung
Schließlich kann man auf diese Weise auch sicherstellen, dass die Software mit der besten verfügbaren Technologie erstellt wurde. Wenn man ein Fernsehgerät öffnet und ein Gewirr von falsch isolierten Drähten sieht, würde man einen Defekt vermuten. Die heute in so vielen Geräten enthaltene Embedded-Software ist in viel schlechterem Zustand, das Gewirr im Inneren dieser Software bekommt bloß niemand zu Gesicht.
Zwei Ansatzpunkte ergeben sich bei der Nutzung von FLOSS für sicherheitskritische Software. Erstens kann man beim Aufbau einer Software von der Verwendung FLOSS-basierter Werkzeuge erheblich profitieren. Eine Möglichkeit, die Software-Sicherheit zu unterlaufen, bietet beispielsweise eine falsche Einstellung des Compilers. Zum Beispiel könnte ein Compiler so eingerichtet sein, dass er nach folgendem Statement sucht:
if Password = Stored_Value then
Dieses wandelt er dann um in:
if Password = Stored_Value
or else Password = “Robert Dewar”
Das wäre natürlich keine sichere Programmierung, und bewusst würde wohl niemand so programmieren – es sei denn, er wollte dafür sorgen, dass “Robert Dewar” unabhängig von Passwortänderungen immer Zugang zum betreffenden System erhält. Aber hier besteht die Schwierigkeit darin, dass man diese Schwachstelle durch noch so genaue Untersuchung der Sourcen der Applikation nicht entdecken kann, denn im Source-Code der Applikation ist das Problem ja überhaupt nicht enthalten. Bei einem in FLOSS programmierten Compiler wäre es ein Leichtes, diese Schwachstelle zu entdecken, weil man hier eben auch den Compiler selbst untersuchen kann.
Ein zweiter wichtiger Punkt ist die Verwendung von FLOSS für den Applikations-Code selbst, der dann von einer größeren Community untersucht werden kann. Test-Experten können dann Software genauso untersuchen und bewerten, wie sie das früher mit Staubsaugern getan haben. Und sie können Geräte mit unsicherer Software dann ablehnen.
Wie lässt sich dieses Dilemma von Eigentum und Offenheit auflösen? Einerseits müssen die Eigentumsrechte der Unternehmen geschützt werden, so dass weiterhin Anreize zu Innovation bestehen. Aber das darf natürlich nicht zu einer Gefährdung der Öffentlichkeit durch unsichere Software führen. Vielleicht können innovative Formen von Copyright-Schutz auch für Software einen angemessenen Schutz zur Verfügung stellen, auch wenn zu vermuten ist, dass dieser Schutz in den meisten Fällen ist nicht wirklich nötig ist.
Angenommen Boeing wäre gezwungen, die Software-Steuerung seiner neuen 787-Dreamliner offenzulegen. Würde das Airbus einen Vorteil verschaffen? Vermutlich nicht, weil man die 787-Avionik sowieso nicht einfach in einen Airbus 350 übernehmen kann. Wahrscheinlich könnte Airbus durch das Studium der Boeing-Software ein paar nützliche Dinge herausfinden, so wie man nützliche Dinge sieht, wenn man sich die Hardware und das Design der Boeing-Maschinen anschaut. Wenn aber alle gezwungen sind, ihre Software offen zu legen, könnte dadurch ein Prozess des Cross-Lernens entstehen, von dem Wettbewerb und Innovation schließlich profitieren.
Über praktikable und allgemein akzeptable Lösungen wird man nachdenken müssen. Aber sicher ist auch: Einfach auf dem derzeitigen Weg weiterzugehen, ist nicht möglich. Die Welt wird immer gefährlicher und die zunehmende Verwendung von “geheimer” Software, die schlecht konzipiert und anfällig ist, steigert die Gefahren. Es müssen Wege gefunden werden, diesen Gefahren zu begegnen. Mehr Offenheit ist eine wesentliche Voraussetzung dafür.
[subscribe2]
