Open-Source-Softwareentwicklung gilt häufig als ein unstrukturierter Prozess, der es jedem erlaubt, nach eigenem Gutdünken Code in ein Projekt einzubringen. Deswegen wird Open-Source-Software (OSS) oft auch als unausgereift betrachtet. Auf der anderen Seite zeigt der zunehmende OSS-Einsatz für wichtige Prozesse bei Firmen und Behörden, dass diese Produkte durchaus auch im professionellen Umfeld erfolgreich sind. Dies liegt kaum daran, dass für OSS keine Anschaffungskosten anfallen; da im kommerziellen Umfeld die Betriebskosten wesentlich wichtiger sind, wirkt sich ein Kostenvorteil bei der Anschaffung nicht sehr stark aus.
Wichtiger ist hier, dass Open-Source-Produkte bezüglich der gebotenen Funktionen, der Stabilität im Betrieb, der Konfigurierbarkeit und Wartbarkeit, der Bedienung und nicht zuletzt auch bezüglich der Sicherheit mit kommerziellen Produkten gleichziehen oder sie unter Umständen sogar übertreffen. Solche Eigenschaften wären mit einer unstrukturierten Softwareentwicklung nicht zu erreichen.
In "The Cathedral and the Bazaar" (![[externer Link]](../../../../images/link.gif)
www.catb.org/~esr/writings/cathedral-bazaar/) vergleicht Eric S. Raymond die OSS-Entwicklung mit einem orientalischen Basar, in dem viele Menschen über ein Projekt diskutieren und ihre Ideen einbringen. Die kommerzielle Softwareentwicklung vergleicht er dagegen mit dem Bau einer Kathedrale im Mittelalter: Eine kleine Gruppe entwickelt unter Anleitung und nach einem strengen Plan und präsentiert das Ergebnis erst dann der Öffentlichkeit, wenn es rundum fertig ist.
Der Open-Source-Entwicklungsprozess stützt sich wesentlich darauf, schon in einem möglichst frühen Zustand des "Produkts" die Öffentlichkeit einzubinden. Diese soll sowohl Ideen für neue Funktionen liefern als auch den vorhandenen Prototyp testen. Eine derartige Offenheit erfordert jedoch schon in einer frühen Entwicklungsphase eine strenge Kontrolle. Dass ein weitgehend unkontrollierter Entwicklungsprozess letztendlich zum Chaos führt, weiß die Open-Source-Gemeinde sehr genau.
Ein neues Open-Source-Projekt startet normalerweise mit einer Idee zur Entwicklung einer Software, die von einer beliebigen Person eingebracht wird. Diese versucht anschließend, andere für ihre Idee zu begeistern, damit sie zu dem Projekt beitragen. In den meisten Fällen bringt der Ideengeber auch schon einen ersten (meist sehr unfertigen) Prototypen ein. Alternativ kann auch ein fertiges oder nahezu fertiges Produkt als Open-Source-Projekt weitergeführt werden – so wie beispielsweise der Netscape-Browser in Mozilla eingebracht wurde.
Danach benötigt ein Open-Source-Projekt vor allem:
http://sourceforge.net/), wo mehrere tausend OSS-Projekte registriert sind.Normalerweise ist zu Beginn eines Projekts der Ideengeber auch der so genannte Maintainer, also die (Management-)Instanz, die über die Entwicklung des Produkts entscheidet. Bei größeren Projekten ist es durchaus üblich, hierfür ein Gremium zu etablieren, das dann gemeinschaftlich über Änderungen, Ergänzungen und Freigaben entscheidet. Zusätzlich kann das OSS-Management auch Regeln etablieren, an die sich Entwickler halten müssen, soll ihr Beitrag akzeptiert werden. Ein Beispiel mit umfangreichen derartigen Regeln ist die Linux-Distribution Debian – Interessenten seien auf das "Debian Policy Manual" ( www.debian.org/doc/debian-policy/) verwiesen.
Der Erfolg eines Open-Source-Projekts hängt entscheidend davon ab, möglichst viele Mitstreiter zu finden. Ihr Beitrag kann sowohl in Form von Änderungen und Ergänzungen zum Programmcode als auch durch Testen des Produkts erfolgen. Das Erstellen von Anwenderdokumentation ist ebenfalls gern gesehen – auch OSS-Entwickler sind selten begeistert, wenn man sie um Dokumentation bittet.
Mitstreiter findet am besten, wenn möglichst schnell neue Versionen des Produkts mit neuen Funktionen zur Erprobung bereitstehen. Es ist daher ein Prinzip der Open-Source-Entwicklung, auch schon unfertige und instabile Versionen (normalerweise auch als solche gekennzeichnet) zu veröffentlichen. Im Lauf der – sozusagen öffentlichen – Erprobung wird dann entschieden, welche Funktionen man tatsächlich in das nächste als stabil bezeichnete Release übernimmt. Somit ähnelt eine OSS-Entwicklung einer "Rapid Prototyping"-Entwicklung, bei der der Prototyp durch eine offene Erprobung zu einem stabilen Produkt überführt wird.
Wenn eine solche Entwicklungsmethodik erfolgreich sein soll, erfordert sie ein ausgefeiltes Konfigurationsmanagement, das Änderungen (inklusive Urheber) genau verfolgt und es ermöglicht, sie notfalls auch wieder rückgängig zu machen. Es ist daher kein Zufall, dass eine Reihe ausgefeilter Konfigurationsmanagementwerkzeuge als Open-Source-Projekte entstanden sind.
Es ist ein Prinzip der Open-Source-Gemeinde, sich wo immer möglich auf andere OSS abzustützen. Daher nutzen sehr viele Projekte das Concurrent Versions System (CVS) als Managementwerkzeug ( https://www.cvshome.org/). Eine Ausnahme ist übrigens der Linux-Kern: Dort wird ein kommerzielles Produkt verwendet (Bitkeeper), da Linus Torvalds als oberste Management-Instanz darin eine bessere Management Plattform sieht. Neben CVS dient häufig das Tool Bugzilla ( www.bugzilla.org) zur Verwaltung gefundener Fehler und Probleme. Interessanterweise werden diese beiden Werkzeuge auch in vielen größeren kommerziellen Entwicklungsprojekten eingesetzt.
Tests und eventuell auch Schwachstellen-Analysen laufen ebenfalls in "offener" Weise: Jeder erprobt neue Features nach eigenem Gutdünken und lässt eventuell gefundene Fehler oder Probleme in das Projekt zurückfließen. Daher haben Open-Source-Projekte meistens eine sehr gute Infrastruktur, um solches Feedback einzuspeisen. Allerdings ist nur selten klar geregelt, wer welche Tests durchführt; nur wenige Projekte (unter anderem der Linux-Kern) haben systematische Tests als Teil der Entwicklung integriert.
Bei so vielen Parallelen zu einem kommerziellen Entwicklungsprojekt stellt sich die Frage nach den Unterschieden. Hier zeigen sich im Wesentlichen drei Punkte:
In einem Open-Source-Projekt werden die funktionalen Anforderungen von den Projektbeteiligten definiert – und gegebenenfalls im Laufe des Projekts geändert. Eine exakte Spezifikation gibt es normalerweise nur dann, wenn das Projekt einen bereits definierten Standard implementieren soll. Praktisch alle anderen Projekte starten mit einer bloßen Idee, die sich in der Folge entwickelt. Bedingt durch die Art der Projektbeteiligten werden die funktionalen Anforderungen oft aus einer rein technischen Sicht heraus bestimmt. Kommerzielle Interessen – und häufig auch die Interessen "normaler" Anwender – bleiben oft unberücksichtigt; stattdessen stehen technische Herausforderungen im Vordergrund.
Bei einem kommerziellen Projekt werden dagegen die funktionalen Anforderungen normalerweise aus dem kommerziellen Interesse heraus bestimmt – schließlich will man mit dem Produkt ja Geld verdienen. Sie sind daher meist schon zu Projektbeginn genauer definiert und orientieren sich an dem, was die Marketingabteilung als Kundenwünsche eruiert hat. Natürlich ist auch dies im Verlauf des Projekts Änderungen unterworfen: Marketing-Manager haben mindestens so oft neue Ideen wie Open-Source-Entwickler – meist allerdings mit wesentlich weniger technischem Background.
Im Ergebnis haben Open-Source-Produkte häufig die besseren technischen Funktionen, aber oft auch eine schlechtere Anwender-Schnittstelle.
OSS-Projekte haben meist einen wesentlich häufigeren Release-Wechsel als kommerzielle Produkte. Zusätzlich werden in noch kürzeren Abständen "unstabile" Versionen herausgegeben, die dazu dienen, neue Funktionen oder Änderungen zu erproben, auch wenn diese noch mit Fehlern und Mängeln behaftet sind. Dadurch wird es möglich, Tests auf eine breite Basis zu stellen und die Akzeptanz neuer Funktionen frühzeitig zu ermitteln.
In einer kommerziellen Entwicklung sind häufige Release-Wechsel dagegen kontraproduktiv: Ein kommerzielles Release muss beim Hersteller alle notwendigen Tests und Prüfungen durchlaufen haben, will man Haftungsprobleme vermeiden. "Unstabile" Versionen werden aus mehreren Gründen nicht herausgegeben: Zum einen fürchtet man, dass neue Funktionen zu früh bekannt werden und damit der Konkurrenz die Möglichkeit eröffnen, frühzeitig nachzuziehen. Zum anderen können zu viele Fehler und Probleme beim Kunden ein negatives Image hinterlassen. Daher geben kommerzielle Entwickler Kunden normalerweise erst dann eine "Beta-Version" zum Testen, wenn diese einerseits bereits eine recht hohe Stabilität erreicht hat und andererseits keine größeren Änderungen am Funktionsumfang mehr zu erwarten sind.
Das schon mehrfach erwähnte "öffentliche Testen" ermöglicht zwar eine breite Erprobungs-Basis (vorausgesetzt es finden sich genügend Interessenten), führt aber andererseits zu einer fehlenden Transparenz, was wie getestet wurde. Somit ist in vielen Open-Source-Projekten unklar, welche Testabdeckung erzielt wurde. Einige OSS-Projekte haben dies als Problem erkannt und Tests als festen Bestandteil integriert – für den Linux-Kern gibt es hierfür sogar ein eigenes Projekt: das Linux Test Project (LTP), das interessanterweise von kommerziellen Unternehmen gesponsert wird (siehe http://ltp.sourceforge.net/).
Mit solchen Projekten versucht man, strukturierte Testmethoden und nachvollziehbare Testabdeckungen bei OSS zu erreichen, wie sie in kommerziellen Projekten normalerweise gegeben sind. Bisher gibt es dies aber nur bei wenigen Open-Source-Projekten.
Ein weiteres Manko: Bei den meisten Open-Source-Projekten sucht man vergeblich nach einer brauchbaren Beschreibung des Designs und der internen Funktionsweise des Produkts. Allenfalls in den zugehörigen Diskussionsforen oder in einzelnen Abhandlungen finden sich gelegentlich Hinweise wie bestimmte Funktionen implementiert sind. Dies ist jedoch keinesfalls einheitlich dokumentiert und beschränkt sich dann auch auf solche Funktionen, bei denen Anwender oder andere Programmierer beharrlich nach einer solchen Beschreibung gefragt haben. In solchen Fällen lässt sich dann manchmal ein OSS-Guru dazu herab, ein bis zwei Seiten "Dokumentation" für diejenigen zu erstellen, die noch immer nicht in der Lage sind 1000 Zeilen undokumentierten C-Code in weniger als zwei Stunden vollständig zu verstehen und ihm statt dessen mit ihren dauernden Nachfragen auf die Nerven gehen.
Wer allerdings glaubt, kommerzielle Produkte seien wesentlich besser dokumentiert, würde eine herbe Enttäuschung erleben, wenn er ihre interne Designdokumentation zu sehen bekäme. Designdokumentation ist nicht nur bei OSS-Projekten ein eher dunkles Kapitel der heutigen Softwareentwicklung. Abgesehen von Entwicklungen für kritische Bereiche ist die Designdokumentation auch im kommerziellen Bereich sehr häufig verbesserungswürdig: In 17 Jahren Erfahrung mit der Evaluation kommerzieller Produkte hat der Autor nur wenige Fälle vorgefunden, in denen hier nicht erheblich nachgebessert werden musste. Die Qualität der Designdokumente hat Beobachtungen von atsec zufolge in den letzten Jahren sogar kontinuierlich abgenommen: In den meisten Unternehmen wird die kurzfristige Senkung der Kosten durch Streichungen bei der Designdokumentation für wichtiger angesehen als mögliche langfristige Einsparungen durch qualitativ hochwertige Dokumentation.
Die Common Criteria (CC) sind prinzipiell ein Standard zur Analyse und Bewertung der Sicherheitsfunktionen eines IT-Produkts oder -Systems. Daher stehen produktbezogene Aspekte wie die Analyse der Sicherheitsfunktionen, der Test dieser Funktionen oder die konkrete Suche nach Schwachstellen im Vordergrund. Es werden aber auch – besonders auf höheren Stufen – eine Reihe von Aspekten des Entwicklungsprozesses betrachtet. Dabei gehen die CC von einem wohldefinierten und kontrollierten Entwicklungsprozess aus, der für den gesamten Evaluationsgegenstand (EVG) gilt.
Ein OSS-Entwicklungsprozess wird zwar durchaus in weiten Teilen streng kontrolliert, ist aber meist nicht exakt definiert. Ausnahmen sind größere Projekte, die teilweise sehr detaillierte, projektspezifische Richtlinien besitzen. Von den Common Criteria geforderte Verfahren zum Konfigurationsmanagement sind in fast allen OSS-Projekten vorhanden, jedoch fast immer auf den Quellcode und einige wenige Dokumente beschränkt, die Generierung und Konfiguration des Produkts beschreiben. Der Entwicklungsprozess hat allerdings – analog zu vielen kommerziellen Entwicklungen – Lücken, wenn es um systematisches und nachvollziehbares Testen oder die Designdokumentation geht.
Die Common Criteria verlangen jedoch vom Hersteller ausreichende Dokumentation bezüglich des Produkt-Designs, der durchgeführten Tests von Sicherheitsfunktionen sowie der Kontrolle des Entwicklungsprozesses. Zusätzlich wird korrekte und vollständige Dokumentation für den Anwender erwartet, die sowohl Installation als auch Betrieb abdeckt. Die Evaluation prüft diese Dokumentation auf Vollständigkeit und Korrektheit und prüft zusätzlich das Produkt auf die Einhaltung der vom Hersteller festgelegten Sicherheitsanforderungen. Außerdem wird die Einhaltung der Anforderungen an den Entwicklungsprozess entsprechend der angestrebten EAL-Stufe geprüft.
Nur in seltenen Fällen wird auch ein kommerzieller Hersteller, der vorher noch nie ein Produkt einer Sicherheitsevaluation unterzogen hat, sofort alle diese Anforderungen erfüllen. Es ist der Normalfall, dass zusätzliche Dokumentation und Tests entwickelt und Prozesse angepasst werden müssen. Für OSS ist das nicht anders. Das Problem davei ist: Diese Anpassungen entsprechen nicht dem, was ein Softwareentwickler (egal ob OSS oder kommerziell) als notwendig und sinnvoll ansieht und daher wird man ohne entsprechenden Druck nicht die erforderlichen Ergebnisse erhalten. In einem kommerziellen Umfeld erzeugt das Management solchen Druck – in einem OSS-Projekt ist dies aber praktisch nicht möglich.
Die geschilderten Probleme traten auch bei der Linux-Evaluation auf. In einer ersten Analyse hatte atsec unter anderem als Defizite festgestellt, dass für circa 60 System Calls des betrachteten Linux-Kerns keine Beschreibung existierte, die Sicherheitsfunktionen für ein High-Level-Design unzureichend dokumentiert waren und auch die allgemeine Designdokumentation entweder gar nicht oder nur unzureichend vorhanden war. Zudem erwies sich trotz des Linux-Test-Projekts die Testabdeckung der Sicherheitsfunktionen als bei weitem unzureichend.
Auf den ersten Blick erschien das Ergebnis dieser Analyse katastrophal. Für die erste Evaluation von Linux (nach EAL2) konnten die Projektbeteiligten – IBM, SuSe und atsec – dennoch eine Strategie entwickeln, um diese Defizite zu beseitigen. So übernahm beispielsweise IBM die Aufgabe, die fehlende Dokumentation der System Calls und der sicherheitsrelevanten Funktionen in- und außerhalb des Kerns nachzuholen sowie noch notwendige Tests zu entwickeln und in das Linux-Test-Projekt zu integrieren. SuSe als Linux-Distributor übernahm hingegen die Rolle des Software-Integrators und zeichnete für die Prozesse zu Konfigurationsmanagement, Abnahmeverfahren, Sicherheit der Entwicklungsumgebung, Softwareintegration und Fehlerbehandlung verantwortlich.
Mit dieser Konstellation konnten die Probleme erfolgreich adressiert werden: Aufgaben, die normalerweise niemand aus der OSS-Gemeinde freiwillig übernähme, erledigte ein kommerzieller Sponsor. Durch den Distributor als Mittler zwischen Entwicklern und Anwendern konnten auch die prozessbezogenen Anteile der Common Criteria erfüllt werden. Diese Methode wurde weiterentwickelt und in fünf späteren EAL3-/EAL4-Evaluationen von SuSe- und Redhat-Linux angewandt.
Die Defizite von Linux bezüglich der CC-Anforderungen konnten so in ähnlicher Weise beseitigt werden wie bei einem kommerziellen Produkt. Der einzige Unterschied ist, dass man einen Sponsor finden muss, der die Arbeiten zur Behebung der Defizite organisiert und sie und die Evaluation an sich finanziert. Im Fall von Linux haben sich mit IBM und HP zwei Sponsoren gefunden, die ein hinreichendes wirtschaftliches Interesse an der Verbreitung von Linux haben – zusätzlich übernahmen die Distributoren wichtige Rollen.
Die Linux-Evaluationen können daher nur zum Teil als "Paradebeispiel" einer OSS-Evaluierung betrachtet werden. Sie waren vielmehr ein Mittelding zwischen der Evaluation eines reinen Open-Source-Produkts und eines kommerziellen Produkts. Dennoch lässt sich die Vorgehensweise ohne Weiteres auf andere OSS übertragen – vorausgesetzt es findet sich ein Sponsor.
Gleichzeitig haben die Linux-Evaluierungen einen Schwachpunkt der Common Criteria aufgezeigt, der auch bei kommerziellen Produkten mehr und mehr zum Problem wird: Die prozessorientierten Anteile der CC gehen von einem weitgehend einheitlichen Softwareentwicklungsprozess aus, der vollständig von einem Hersteller kontrolliert wird. In der Praxis ist dies aber auch bei kommerziellen Produkten nur die Ausnahme. Bei größeren Produkten (z. B. Betriebssystemen) findet die Entwicklung an sehr vielen Stellen statt, wobei unterschiedliche Werkzeuge zum Einsatz kommen. Hier verläuft die Softwareentwicklung nicht anders als zum Beispiel die Produktion eines modernen Autos, das aus vielen Teilen montiert wird, die zuvor verschiedene Unternehmen nach unterschiedlichen Methoden an vielen Standorten produziert haben.
Bei der Evaluation von Linux wurde die Instanz, welche die "Endmontage" und Abnahme durchführt, als "Entwickler" im Sinne der Common Criteria betrachtet: der Distributor. Erst durch die Beschränkung der prozessorientierten CC-Anteile auf den Distributor war es möglich, die Anforderungen zu erfüllen.
Open-Source-Software kann nach den Common Criteria evaluiert werden. Aber weder jedes kommerzielle noch jedes OSS-Produkt ist "reif" für eine Sicherheitsevaluation. Zudem wird ein kommerzielles Sponsoring bei der Evaluation von OSS wohl immer erforderlich sein, um fehlende Anteile zu entwickeln und die Evaluation selbst zu finanziere. Dies setzt ein kommerzielles Interesse an der Evaluation voraus, was die Zahl der OSS-Produkte, die hierfür Evaluation infrage kommen, deutlich einschränkt. Findet sich aber ein solcher Sponsor und hat die Open-Source-Gemeinde selbst für das Produkt schon in größerem Umfang Sicherheitsuntersuchungen durchgeführt, so ist eine CC-Evaluation selbst bis EAL4 möglich.
Helmut Kurth ist Mitbegründer und Chief Scientist bei atsec information security.
Dieser Artikel ist eine gekürzte Fassung des Beitrags "Aktuelle Erfahrungen mit der Evaluierung von Open Source Software" zum 9. BSI-Kongress.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2005#4, Seite 33
| 