A.12 Abschließende Bemerkung
Bei allen Maßnahmen und Aktionen, die im Rahmen der Etablierung eines sicheren Software-Entwicklungsprozesses durchgeführt werden, bleibt das Ergebnis – die Software – immer nur eine Annäherung an ein sicheres Produkt. Software ist zu komplex, um fehlerfrei sein zu können, und ein optimal auf Sicherheit getrimmter Entwicklungsprozess wird eine Menge Sicherheitslücken vermeiden, aber keine Garantie für absolut sichere Software sein.
Interessanterweise gibt es Software, die als sicher gilt. Qmail ist ein gutes Beispiel dafür. Qmail ist ein MTA, ein Mail Transfer Agent, für Unix-Systeme und wurde von seinem Programmierer Dan Bernstein als Ersatz für das durch immer neue Sicherheitslücken geplagte Urviech Sendmail konzipiert. 1997 hat Dan Bernstein einen Preis von 500 USD für denjenigen ausgelobt, der eine Sicherheitslücke in Qmail nachweisen kann. Das ist bis heute niemandem gelungen.
Die Begründung, warum aus seiner Sicht Qmail so sicher ist, gibt Dan Bernstein in der Qmail Security Guarantee [http://cr.yp.to/qmail/guarantee.html]. Die Kurzzusammenfassung lautet wie folgt:
- Behandeln Sie Programme und Dateien niemals als Adressen.
- Arbeiten Sie so selten wie möglich mit setuid-Programmen.
- Arbeiten Sie so selten wie möglich als root.
- Lagern Sie Funktionen in eigene Programme aus, sich nicht gegenseitig vertrauen.
- Parsen Sie nicht.
- Halten Sie Design und Code einfach (übersichtlich – Keep it simple, stupid!).
- Schreiben Sie bugfreien Code.
Auch wenn diese sieben Argumente für die Sicherheit von Qmail nicht den Anschein eines sicheren Entwicklungsprozesses erwecken, sind sie dennoch alle in verschiedenen Controls des oben beschriebenen Anforderungskatalogs enthalten. Und da schließt sich der Kreis: Ein einzelner, fähiger und engagierter Programmierer kann auch ohne einen Prozess sichere Software schreiben. Das funktioniert auch in einem Team gleichartig engagierter und fähiger Programmierer. Allerdings ist das Ergebnis nur so lange gut, wie alle Beteiligten ihren Elan behalten, ihr Wissen auf dem neuesten Stand bleibt und sie sich an alle selbst gesteckten Vorgaben bezüglich Design und Implementierung halten. Um diese Voraussetzung dauerhaft zu schaffen, ist ein entsprechend gearteter Entwicklungsprozess notwendig.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
