Ingo Ruhmann  

  
  
  
Wie Frank Rieger eben schon sagte, das Vertrauen von Nutzern in IT-Sicherheitssysteme ist eine der Kernfragen in diesem ganzen Bereich. Sie steckt auch hinter diesem offensichtlichen Widerspruch bei der Frage: Warum hat es Open Source-Software in vielen Bereichen so schwer? Der Widerspruch besteht darin, daß wir als Experten wissen, wie gut Open-Source-Software ist, und natürlich auch, wie schlecht proprietäre Betriebssysteme oftmals sind, und trotzdem gibt es eine ganze Reihe von Punkten, an denen ein erhebliches Mißtrauen gegenüber Open Source-Software besteht. Diese Frage von Mißtrauen läßt sich möglicherweise durch vertrauensbildende Maßnahmen ergänzend aufweichen. Hier besteht aber die Notwendigkeit, sich strukturell mit diesen ganzen Fragen auseinanderzusetzen. Deswegen will ich das Thema in der Kürze der Zeit einfach etwas querbürsten und es nicht auf Krypto-Fragen reduzieren, sondern ausweiten auf Fragen der IT-Sicherheit im allgemeinen. Die Fragen, die im Zusammenhang mit Kryptographie wichtig sind, sind auch wichtig im Zusammenhang mit IT-Sicherheit allgemein. Man braucht sich nämlich, wenn man die Unterschiede zwischen proprietären und offenen Systemen verstehen will, eigentlich nur die grundlegendste IT-Sicherheitsebene anzugucken, nämlich: Wie häufig fallen proprietäre Betriebssysteme aus? Wie stabil sind Open-Source-Betriebssysteme? Es wird ja immer als der größte Vorteil neben den Kostenaspekten gesehen, wie stabil Linux im Vergleich zu Microsoft-Produkten ist. Das heißt, unter IT-Sicherheitsaspekten ist die Verfügbarkeit von Open Source-Systemen wesentlich höher, und trotzdem gibt es die altbekannten Vorbehalte.  

Black Box vs. Open Source 
Gleiches gilt auch für die Vertraulichkeit. Vertraulichkeit ist das Synonym dafür, daß andere Leute Daten, die von A nach B übermittelt werden, nicht zur Kenntnis erhalten. Schutz der Vertraulichkeit bieten kryptographische Systeme. Hier herrscht in der ganzen Fragen von Open Source und IT-Sicherheit ganz offensichtlich das Mißverständnis vor, daß IT-Sicherheit nur dann sicher ist, wenn sie auch einem vertraulichen Prozeß entwickelt wurde, d.h., wenige Leute wissen, um was es geht. Ich denke, daß ist ein erhebliches Mißverständnis, obwohl es natürlich nachvollziehbar ist. Wenn man sich nämlich anguckt, wie z.B. Microsoft-Produkte ihre Paßwörter bisweilen auch heute noch verschlüsseln, dann ist natürlich klar, warum. Es gibt einige Microsoft-Systeme, die ihre Paßwörter ganz einfach mit einer xor-Verschlüsselung mit einer relativ einfachen Zahl ablegen. Wenn bekannt wird, wie dieser Mechanismus funktioniert, dann ist er nichts mehr wert. Im Gegensatz dazu, wie allen bekannt, verschlüsselt Unix Paßwörter in einer Einwegfunktion und vergleicht sie auch in der verschlüsselten Version. Da es keine Umkehrfunktion dazu gibt, ist es völlig unerheblich, ob diese Einwegfunktion bekannt ist oder nicht. Und jeder kann auch das abgelegte Paßwort lesen, weil er damit nichts anfangen kann, denn es liegt ja nicht im Klartext vor. Wenn man sich mal die einzelnen Mechanismen vor Augen führt, kann man unterscheiden zwischen dem, was ich jetzt Black Box-Systeme genannt habe und was ich mit Open Source-Systemen bezeichnet habe. Wie wird Sicherheit hergestellt bei Black Box-Systemen? Ganz einfach durch die Stärke der Unkenntnis des Verfahrens -- das, was Frank eben als Security by Obscurity bezeichnet hat. Während bei Open-Source-Systemen Sicherheit einfach nur dadurch hergestellt werden kann, daß die Mechanismen in geeignter Weise stark sind.  

Das zweite, was immer als Einwand gebracht wird, ist das Mißtrauen gegen die Entwickler. Das übliche Beispiel ist: 'Wie kann ich diesen langhaarigen Leuten trauen, die mir den Bug Fix schicken?' Nun, richtig ist, ich weiß in der Tat nicht, wer die Leute sind, die Open Source-Software entwickeln. Sie haben eine Email-Adresse, aber ich habe sie nie kennengelernt. Dasselbe gilt aber auch für kommerzielle Produkte. Ich weiß genauso wenig, wer bei Microsoft oder SAP derjenige ist, der die Software entwickelt, aber ich kann versuchen, gegen die entsprechenden Firmen einen Prozeß zu führen. Hier wird also versucht, Sicherheit durch die Möglichkeit des Rechtsweges herzustellen. Das Problem an der Sache ist aber: Wieviele Fälle von Prozeßen gegen solche Firmen werden überhaupt geführt? Die Kriminalstatistik sagt, daß es jenseits von Kreditkartenbetrug allenfalls ein bis zwei Dutzend Fälle von Computerkriminalität gibt, die vor Gericht landen.  

Das rührt einfach daher, daß keine Analyse der Systeme möglich ist. Das heißt, wenn ein Fehler auftritt, kann ich mich effektiv nicht mit einiger Sicherheit an die Firma wenden, die für diesen Fehler verantwortlich ist. Wir kennen es, wenn man eine Hotline befragt, dann wird meistens gesagt: 'Das könnte ja auch noch den und den Grund haben. Es könnte der Treiber von irgendeinem Hardwareteil sein.' Solange die Sourcen nicht wirklich offenliegen, hat der Anbieter eines prorietären Systems natürlich die Möglichkeit abzustreiten, daß der Fehler bei ihm liegt. Und ich habe keine Möglichkeit, das herauszufinden.  

Bei Black-Box-Systemen ist eine Fehlererkennung nur durch einen Funktionsfehler im Betrieb möglich, bei Open Source-Systemen aber eine konkrete Analyse, woran dieser Fehler liegen könnte. Das heißt, effektiv ist erst in dem Fall, daß ich Open Source-Software einsetze, überhaupt die Möglichkeit gegeben, daß ich diesen Rechtsweg -- den viele bei prorietären Systemen für gegeben halten -- mit einiger Aussicht auf Erfolg beschreiten kann. Hinzu kommt sogar, daß ich, wenn ich bei bestimmten proprietären Systemen eine Analyse mache und herausfinde, daß der zur Sicherheit benutzte Mechanismus extrem schwach ist, da oftmals sogar rechtlich besonders schlechte Karten habe, weil der Schutz gegen Datenmißbrauch auch einen ausreichenden technischen Hintergrund voraussetzt. Das heißt, sind die technischen Mechanismen schwach, habe ich rechtlich auch gar keine Möglichkeiten. Das Ganze zu überprüfen ist rechtlich ausgesprochen schwierig, und möglich ist es nur bei Open Source-Systemen. Es sollte eben deswegen schon gar nicht zu solchen Sicherheitsproblemen kommen, weil wir vorher analysieren könnten, ob die Systeme sicher sind oder nicht.    

Dasselbe gilt in der Betrachtung der systematischen Kontrolle der Funktionstüchtigkeit. Eine derartige systematische Kontrolle ist bei diesen Black Box-Systemen definitiv unmöglich. Allerdings, wenn man sich jetzt die Open Source-Systeme ansieht, wird man sehen, daß man hier durchaus ein bißchen differenzieren muß. Wie Frank eben erzählte, gibt es nur sehr wenige, die sich PGP insgesamt angeguckt haben. Ich glaube, es gibt auch sehr wenige, die sich Open Source-Systeme insgesamt angeguckt haben. Diese Systeme haben mittlerweile eine Komplexität erreicht, daß sie nur für wenige Experten durchschaubar sind. Und gleichzeitig gehen sie in den allgemeinen Massenmarkt. D.h., wir bekommen es hier mit einer Dichotomie zu tun zwischen dieser Minderheit von Experten und der Mehrheit von Benutzern, die zwar im Prinzip die Möglichkeit hat, Open Source-Systeme zu überprüfen, effektiv hat sie die aber nicht. D.h., für eine Mehrheit ist auch hier das Funktionsprinzip von IT-Sicherheit einfach nur der Glaube, daß es funktioniert. Der Mehrheit ist es nur möglich, andere Leute zu fragen: 'Ist es denn wirklich sicher? Was kann ich hier verbessern?' Das heißt, es müssen irgendwelche Experten her. Und nur Experten sind in der Lage, das wirklich selber zu überprüfen.  

Wenn wir uns die Fehlerbehebung angucken, so ist ja bei diesen Black Box-Systemen noch nicht einmal überprüfbar, ob dieser Fehler effektiv behoben oder ob nur ein untauglicher Patch abgeliefert wurde. Bei Open Source-Systemen lassen sich immerhin Softwareentwickler anheuern, die das machen. Und für die Experten dieser Systeme ist immerhin vollständig überprüfbar, ob dieser Patch vernünftig war oder nicht.  

Zum Punkt Kenntnisunsicherheitsschwächen: Ich denke, da haben wir nun genügend Beispiele gehört. Ich will noch ein anderes Beispiel aus dem Bereich der Bundesregierung einführen. 1997 hat die Bundesregierung erklärt, daß im Bereich der Bundesbehörden 65.000 PCs mit Microsoft-Betriebssystemen im Einsatz sind. Heute werden es einige Tausend mehr sein. Keiner dieser PCs läßt sich auf Sicherheitsmängel überprüfen, ob er jetzt im Berlin-Bonn-Verkehr eingesetzt wird oder nicht. Im übrigen wurde die genutze Krypto-Hardware im Bonn-Berlin-Verkehr von einer Firma geliefert, die nachdem der Kaufentschluß gefallen war, von der südafrikanischen Firma Persetel Q Holdings gekauft wurde, die während der Zeiten des Boykotts gegen Südafrika großgeworden sind, mit besonders guten Kontakten zum südafrikanischen Militär. Im Herbst 1999 wurde dieser Firmenteil immerhin von der deutschen Firma UtiMaco gekauft. Für Black Box-Systeme ist daran wichtig: Das Know-How um die Kyptomodule war für einige Zeit für Beteiligte offengelegt, deren Vertrauenswürdigkeit niemand geprüft hat. Hier gibt es also einige Probleme, die dadurch nicht besser werden, wenn wir uns auf große kommerzielle Anbieter verlassen.  

Zum Thema Verbesserung: Wenn ich mir ein kleineres Sicherheitsproblem der letzten Wochen und Monate angucke, wird offenbar, daß Verbesserungen im Sicherheitszusammenhang immer wieder notwendig sind, und zwar im laufenden Betrieb. Die US-Navy hat festgestellt, daß Schiffe in der Adria im Kosovo-Krieg Mails senden und empfangen konnten und daß ihre Soldaten ziemlich blauäugig nicht nur Mails anderer Leute gelesen, sondern auch sensitive Informationen per Mail an ihnen unbekannte Leute weitergegeben haben. Was war die Lösung? Eingehende Mails wurden erlaubt, ausgehende nicht. Das funktioniert mit schlecht anpassbaren Systemen nur auf diese Art und Weise. Man hätte sich natürlich auch andere Wege überlegen können, diese Systeme ein wenig besser der neuen Situation anzupassen. Eine solche Anpassung ist natürlich bei Black Box-Systemen schlichtweg unmöglich. Bei Open Source-Systemen kann ich entsprechende Veränderungen jederzeit einbringen, wenn ich die Leute kenne oder selbst dazu in der Lage bin. Das heißt, die Anpassung gerade unter IT-Sicherheitsaspekten für spezifische Verhältnisse eines Unternehmens, sofort bei Einrichtung eines Systems oder wenn die Sicherheitslage oder die äußeren Umstände sich geändert haben, ist immer eine akute Notwendigkeit. Und hier zeigt sich einer der größten Schwächen dieser Black-Box-Systeme.  

Soweit die Auseindersetzung mit den Gegenargumenten. Ich möchte noch einmal darauf eingehen, daß diese Differenzierung zwischen Mehrheit und Minderheit in dem Maße notwendig ist, wie sich Open Source-Systeme mehr und mehr in den allgemeinen Markt hinein entwickeln. Ich denke, auf dieser Ebene wird am ehesten deutlich, warum es immer noch Vorbehalte einerseits und mangelnden Rückhalt andererseits gegenüber Open Source-Systemen gibt, weil nämlich für die Mehrheit der Nutzer der Glaube in die Effektivität der Verfahren immer noch der einzige für sie handhabbare Aspekt ist. Und wenn es für beide Systeme derselbe Mechanismus ist, dann denke ich, muß man hier auch den Hebel ansetzen, um es zu verändern. Wir hatten eben schon das alte Argument: Nicht alle kennen alle Features, nicht jeder kann die Effektivität einer IT-Sicherheitsmaßnahme beurteilen. Gerade PGP ist so komplex geworden, daß nicht jeder den Source Code insgesamt gelesen hat. Das heißt, wenn es um IT-Sicherheit geht, erst recht wenn es um kryptographische Verfahren geht, ist Offenheit der Systeme und Verfahren für die höhere Qualität und Sicherheit absolut effektiv notwendig. Nur, wenn sich Open Source-Systeme dem Otto-Normal-User nähern, sind hier eben andere Mechanismen erforderlich. Man kann daraus ein paar Schlußfolgerungen ziehen: Diese Sicherheitsbedenken gegen Open-Source-Systeme werden so lange anhalten, wie die Vorteile einfach nicht für die Mehrheit erkennbar sind. Notwendig für Otto-Normal-User ist eben nicht das Know-How von Open Source-Systeme -- es ist keine Bildungsfrage --, sondern die Herstellung von Vertrauen in diese Systeme. Denn die Überprüfbarkeit, die kann und will Otto-Normal-User nicht leisten. Das kann man auch nicht voraussetzen.  

Vertrauenswürdige Instanzen 
Lösen läßt sich das Problem eigentlich nur durch die Integration sogenannter vertrauenswürdiger Instanzen. Natürlich sollen, wie ich eben schon sagte, vertrauenswürdige Instanzen Vertrauen liefern und Kompetenz. Das ganze ist aber kontextsensitiv. Wenn ich irgendein System beschaffe, und ich bin mir nicht klar, wie sicher das ist, kann ich mir eine Sicherheitsfirma anheuern, die mir das erklärt und die ich selber dafür bezahle. Das ist die eine Lösung. Die andere Möglichkeit wäre, daß Distributoren dafür zahlen, daß sie sichere Systeme haben und das jemanden haben prüfen lassen. Das ist die kommerzielle Variante. Oder, und das wäre vielleicht das Effektivste, diese vertrauenswürdigen Instanzen beteiligen sich direkt an der Entwicklung. Wer könnten diese Instanzen denn sein? Es gibt, und das ist das interessante an offenen Systemen, auf einmal doch eine ganze Reihe mehr Akteure, als bisher. Bisher hatten wir für solche Überprüfungen ein Standardmodell: Der TÜV-IT oder das BSI bekommt einen Antrag auf den Tisch, ein bestimmtes System auf einen bestimmten Sicherheitsgrad hin zu prüfen. Die bekommen auch den Quelltext, machen hinterher einen Stempel drauf, nachdem sie Gebühren kassiert haben, und das wars. Wenn ich Open Source-Software habe, kann ich mir diese Sicherheitsakteure für entsprechende Zwecke, für die ich die Software hinterher einsetzen will, aussuchen. Das können entweder staatliche Akteure sein, d.h. Datenschutzbeauftrage, wenn es um Datenschutzfragen geht, das BSI oder TÜV-IT wie herkömmlich, oder ich kann mir auch den CCC vorstellen oder irgendwelche anderen Instanzen, die hier gerufen werden, um die Sicherheit bestimmter Features und Systeme zu überprüfen. Man kann sich genauso gut vorstellen, daß diese vertrauenswürdigen Instanzen national gerufen werden oder, wenn ich ein System global vertreiben will, daß ich mir international verteilt verschiedene Instanzen ins Boot hole. Und man könnte sich sogar vorstellen, daß hier neue organisatorische Strukturen geschaffen werden, im Zusammenhang mit der Open Source-Bewegung z.B. eine Security Task Force -- das ist nur so ein hingeworfener Begriff, der in diesem Bereich recht häufig zu hören ist -- zur Evaluation von Sicherheits-Features. Genau so etwas wäre eine Möglichkeit, um eine Vielzahl von Sicherheitsexperten in die Entwicklung miteinzubeziehen. Ich denke, der Beitrag von Frank Rieger hat auch gezeigt, daß eine ex-post-Analyse eines Riesenberges von Source Code genauso schwierig ist für solche Experten, wie für das BSI, wie für jeden anderen. Wichtiger und besser ist, diese Experten gleich in den Entwicklungsprozeß miteinzubeziehen.  

Kernpunkt dieser Idee ist, daß Sicherheit in Open Source-Systemen, im Gegensatz zu diesen Black Box-Systemen, nachweisbar ist, aber jemand muß dafür bezahlen und das organisieren. Wer zahlt, ist nach den herkömmlichen Modellen auch wieder klar. Wenn das BSI, wie es vor wenigen Wochen erklärt hat, Open Source-PGP für so wichtig hält, daß hier eine Evaluation von Seiten des BSI angestoßen wird, und das BSI auch die Kosten für diesen Prozeß übernehmen will, dann zahlt eben der Staat. Wenn die Anwender ein Interesse daran haben, dann können sie es entweder selbst bezahlen oder als Anwendergruppe Geld zusammenschmeissen, dann bezahlt die Privatwirtschaft. Oder, wenn die Experten schon in diesen Entwicklungsprozeß einberufen werden -- das ist die zwar sinnvollste, aber von der Finanzierung her die wackeligste Variante --, dann müssen dafür Ressourcen her. Das ist nun eines der Probleme, die man hier noch diskutieren kann.  

"Stiftung Software-Test" 
Wenn man über die Probleme von IT-Sicherheit und von Krypto-Software nachdenkt, macht es am ehesten Sinn, vertrauenswürdige Instanzen schon beim Entwicklungsprozeß zu beteiligen. Aber die kleine Parade von IT-Sicherheitslücken in Black Box-Systemen, die wir eben gesehen haben, zeigt auch ein Grundproblem. Jede Sicherheitslücke wird von den Medien natürlich begierig aufgenommen, führt aber bei der Mehrheit der Leute dazu, daß Computersysteme im allgemeinen als unsicher angesehen werden. Hier wird nicht differenziert zwischen Black Box-Systemen und Open-Source-Systemen. Und das aus dem einfachen Grunde, weil den meisten Leuten die Kompetenz abgeht, zu unterscheiden, ob es sich um eine überprüfbare Sicherheit handelt oder ob es einfach nur ein strukturelles Problem dieser Black Box-Systeme ist. Hier gibt es auch Vergleiche in anderen Bereichen. Die Stiftung Warentest z.B. geht her und prüft und differenziert, aber anhand von Kriterien, die allen offengelegt werden. Es ist schließlich kein Zufall, daß die Enquetekommission "Deutschlands Weg in die Informationsgesellschaft" des deutschen Bundestages in der letzten Legislaturperiode in ihrem Bericht zu IT-Sicherheit eine "Stiftung Software-Test" gefordert hat. Diese "Stiftung Software-Test" sollte sich mit Kriterien und mit der Evaluation von Software unter IT-Sicherheitsaspekten auseinandersetzen. Sinn der Sache ist, zu einer anderen Sicherheitskultur zu kommen. Weg von dieser Aufregung: 'Der und der Browser hat mal wieder dies und jenes Sicherheitsloch', und der Panik, die dann hinterher kommt. Oder diese mittlerweile notorischen Meldungen über neue Viren, bei denen die Hälfte der Mails sich auf Viren bezieht, die gar nicht existieren. Diese Aufregung ist ja ganz schön und nützlich, sie führt aber letztendlich nur zu reiner Panikmache ohne vernünftige Differenzierung. Open Source-Software kann diese vernünftige Differenzierung dadurch leisten, daß es eine überprüfbare Sicherheit bietet, nur müssen dann auch die Mechanismen dafür her. Das heißt, daß was eine "Stiftung Software-Test" leisten müßte, wäre eben das Definieren von Kriterien. Eine "Stiftung Software-Test" wäre wieder sowas zentralistisches, das muß aber nicht sein, wenn wir eben diese vertrauenswürdigen Instanzen einbeziehen.  

IT-Sicherheitskultur 
Meinen nächsten Punkt habe ich hier scherzhaft als 'von einer Public-Licence zu einer Publicity-Licence' bezeichnet. Wir hatten gestern hier auf dem Podium gehört, daß einige Entwickler sagen: 'Das ist doch prima, daß ich mich nicht mehr darum kümmern muß, Support für die Software zu machen, die ich schreibe. Das machen dann die Distributoren für mich.' Das ist richtig. Ich denke trotzdem, daß zu wenig Publicity betrieben wird, Publicity in dem Sinne, daß den Leuten erklärt wird, was die Sicherheitsvorteile von Open Source-Software sind. Hier sollte man in der Tat einigen Leuten, am ehesten noch den Distributoren, deutlich machen, daß sie noch einiges an Bringschuld zu erfüllen haben. Bringschuld in dem Sinne, daß sie die Öffentlichkeit nicht nur über die Vorzüge ihrer Produkte aufklären müssen, sondern auch über die Vorzüge ihrer Produkte in puncto Sicherheit.  

Schließlich das, was Frank Rieger eben auch schon angeführt hat: das Thema IT-Sicherheitskultur. Ich denke, daß ist ein noch relativ vager Begriff, der im Kern eigentlich nur besagt, daß das Bewußtsein um IT-Sicherheit steigen muß; daß es kein Kostenfaktor ist, sondern ein erheblicher Nutzenfaktor; und daß der Grad der Panik aus Unwissenheit bei irgendwelchen Problemen dadurch herabgesetzt werden muß, daß die Leute auf der einen Seite einfach kompetenter mit IT umgehen können und auf der anderen Seite ein kompetenteres Beratungsangebot zur Verfügung haben. Auch hier gibt es also strukturell einige Verbesserungen, die notwendig sind. Qualität sollte nicht vom Glauben abhängig sein, sondern von überprüfbaren Kriterien. Das ist bei Open Source-Software möglich. Das heißt nicht, daß herkömmliche Zulassungsverfahren so einfach auf die IT-Branche übertragbar sind. Davor möchte ich noch einmal warnen, weil das immer so gerne als Gegenfrage kommt. Die Zulassung von IT-Systemen ist ein zeitraubender Prozeß, um den es hierbei eigentlich nicht gehen kann. Es müßte stattdessen darum gehen, die Leute, die für die Mehrheit der Nutzer das Vertrauen in die Systeme symbolisieren, das sie brauchen, weil sie selber nicht in der Lage sind, sie zu kontrollieren, schon in die Entwicklung zu integrieren. Ich denke, daß diese ganze Auseinandersetzung um IT-Sicherheitsfragen, wie jetzt z.B. bei PGP, die momentan nur als Dichotomie gesehen wird von Security by Obscurity, die niemand überprüfen kann, versus Offenheit, die jeder überprüfen kann, eigentlich nur ein erster Schritt ist. Dieser erste Schritt wird dazu führen, daß wir eine Infrastruktur von Überprüfbarkeit und von vertrauenswürdigen Instanzen brauchen, die das auch beglaubigen kann, was wir im offenen Code lesen können. Insofern denke ich, daß die Diskussion, die wir heute führen werden, nur ein Anfang ist.