Wenn Aktivisten oder Entwickler Open Source-Software als die Lösung aller Probleme bezeichnen, so vereinfachen sie zu ihrem Nachteil. Das ist vielen von ihnen bis heute nicht bewusst oder sie wollen es nicht wahrhaben:
Software und Hardware kann man nur umfassend auf Sicherheitslücken untersuchen, wenn man vollen Zugriff auf Quellcode, Layout und Produktion/Kompilierung hat. Streng genommen sind also sämtliche Lösungen zur Verschlüsselung quatsch, bei denen der Nutzer nicht auch das Binary selbst erstellt und vorab den kompletten Quellcode geprüft hat.
Das kann natürlich heute keine Person und kein mittelständisches Unternehmen mehr leisten. Open Source-Betriebssysteme (Kernel wie Userspace) sind so komplex geworden, dass sie nicht mehr zu überblicken sind. Nehmen wir mal den Linux Kernel: Mainstream-Funktionen und insbesondere Treiber sind sicherlich sehr robust und zuverlässig, aber gerade Treiber oder gar Subsysteme für veraltete oder teure, seltene Hardware sind per se risikobehaftet.
Auch hier ist es nicht anders, als im Rest des Lebens: Dort wo die Musik spielt, schauen auch die Leute hin. Kriminalität, Betrügereien und Diebstahl treten in den „dunklen Gassen“ auf oder wenn die Leute nicht aufmerksam sind.
(Seitenhieb: Manche halten das X.509-System wegen des Trust-Modells für kaputt, aber bei Open Source ist das auch nicht anders: Ich muss den Entwicklern, Distributoren und Serverbetreibern vertrauen, auch wenn ich diese (und deren Motivation) nicht persönlich kenne!)
Es wird immer ein Wettlauf gegen „die Bösen“ bleiben, man wird niemals 100% Sicherheit schaffen können und muss laufend Lücken stopfen. Es wäre aufrichtiger und ehrlicher, dies auch bei großer Sympathie mit Open Source-Lizenzen auch so zu sagen:
In meinem Blogpost, welcher die Open Source-Aktivität der Landeshauptstadt München kritisiert, habe ich das Thema schon angeschnitten: Es reicht einfach nicht, eine closed source software/black box durch eine Open Source-Lösung zu ersetzen. Um Sicherheit zu erhalten, muss ich zumindest in der Lage sein, weite Teile des Quellcodes zu auditieren/überprüfen und auch Upstream-Änderungen zu überblicken.
Ich bin zwar selbst Entwickler und beobachten in meinem Segment hunderte Leute auf Twitter, dutzende source code repos und manchen Bugtracker, aber es ist ausgeschlossen, alles mitzubekommen. Ich maße mir aber auch nicht an, für die Sicherheit einer Sprache oder eines Betriebssystems zu garantieren, letztlich stehen wir hier auf den Schultern von Giganten und müssen hoffen, dass uns keiner ein trojanisches Pferd unterjubelt.
Um hier im großen Stil Kompetenz und Entscheidungsfreiheit aufzubauen, benötigt man folgende Dinge:
- Manpower
- Kultur/Infrastruktur/Ökosystem
- Geld
Manpower bekommt man nur durch ausreichend gebildetes Personal. Gerade im öffentlichen Dienst ist das aussichtslos, denn die dort bezahlten Gehälter sind indiskutabel. Wer also freiwillig beim BSI oder der IT-Abteilung einer Stadt arbeitet, muss zwangsläufig ein gestörtes Verhältnis zu Geld und finanzieller Absicherung haben.
Die besten OpenSource-Projekte und Sicherheitsaudits entstehen durch gemeinsames Arbeiten und Wissensaustausch, ähnlich wie in der Forschungs/Wissenschafts-Community. Wer also seine Erkenntnisse teilt, hilft auch anderen. Dies muss gefördert werden und darf sich nicht zum (wirtschaftlichen) Nachteil der Veröffentlicher entwickeln.
Alles steht und fällt mit den finanziellen Mitteln. Wir bräuchten viel mehr Geld und zwar nicht für Geld-Brennöfen wie Fraunhofer, sondern für praktische Dinge und eben die Verbesserung der Ausbildung. Das kann auch durch die Unterstützung der Wirtschaft erfolgen bspw durch Outsourcing, aber ich befürchte hier werden die üblichen Verdächtigen (T-Systems, Siemens, Fraunhofer) bevorzugt die in diesem Segment international bewiesen haben, dass sie es nicht können.