Dipl.-Inform. Carsten Eilers

Am 15. Januar 2002 schickte Bill Gates eine E-Mail mit dem Subject "Trustworthy computing" an alle Microsoft-Mitarbeiter. Sie leitete zumindest offiziell (inoffiziell gab es schon zuvor entsprechende Überlegungen) einen Sinneswandel bei Microsoft ein: Die Sicherheit der veröffentlichten Software erhielt oberste Priorität. In einem ersten Schritt wurden mehrere laufende Entwicklungsprojekte gestoppt und die Entwickler zu IT-Sicherheits-Schulungen geschickt, bevor sie ihre Arbeit fortsetzen durften.

Zu diesem Umdenken kam es natürlich nicht ohne Grund: In den Vorjahren hatte Windows unter mehreren Wurmwellen zu leiden. Zwar lässt es sich nicht vermeiden, dass Windows als das am weitesten verbreitete Betriebssystem auch den meisten Angriffen ausgesetzt ist. Dass es damals aber auch gleichzeitig die meisten Schwachstellen aufwies und den Cyberkriminellen die Arbeit dadurch extrem erleichterte, war einzig und allein Microsofts Schuld. Und daran konnte und wollte Microsoft etwas ändern.

2004 wurde dann im Rahmen des Trustworthy Computing der "Security Development Lifecycle" entwickelt, der nach einigen Änderungen seitdem in einer "vereinfachten" Version Grundlage jeder von Microsoft entwickelten Software ist.

Lohnt sich der SDL?

Ein deutlicher Beweis dafür, dass sich sichere Entwicklung auszahlt, ist ein Vergleich der Version einer Software, die vor der Einführung des SDL entwickelt wurden, mit der nach der Einführung entwickelten Version:

• Das erste vollständig nach dem SDL entwickelte System war Windows Vista, in dem im ersten Jahr nach seiner Veröffentlichung 45% weniger Schwachstellen gefunden wurden als im ersten Lebensjahr von Windows XP: 119 Schwachstellen in XP und "nur" 66 Schwachstellen in Vista.
• Noch besser sieht es beim SQL Server aus: Während im "unsicher" entwickelten SQL Server 2000 in den drei Jahren nach der Veröffentlichung 34 Schwachstellen gefunden wurden, waren es im nach dem SDL entwickelten SQL Server 2005 ganze 3 - eine Reduzierung um 91%.

Die Grundsätze des SDL

Der SDL basiert auf vier "Best Practices":

"Secure by design"

Schon beim Entwurf der Software wird ihre Sicherheit berücksichtigt, z.B. indem Bedrohungsmodelle erstellt und erkannte mögliche Angriffe verhindert oder zumindest erschwert werden.

"Secure by default"

Egal wie sicher eine Software auch entworfen und implementiert wurde, sie wird immer Schwachstellen enthalten. Daher müssen die Standardeinstellungen so gewählt werden, dass ein Angriff möglichst erschwert wird, zumindest aber seine Folgen begrenzt werden. In der Umsetzung bedeutet das z.B., dass die Angriffsfläche durch das standardmäßige Deaktivieren selten benutzter Funktionen reduziert wird und dass die Software mit so wenig Privilegien wie möglich auskommt.

"Secure by deployment"

Die fertige Software wird so ausgeliefert, dass sie möglichst optimal installiert und eingerichtet wird. Das bedeutet zuerst einmal, dass die Dokumentation und die Standardeinstellungen des Installationsprogramms gezielt auf eine sichere Installation ausgerichtet werden. Es umfasst aber auch z.B. Schulungen für Administratoren und Benutzer, so dass die die Software sicher konfigurieren und/oder bedienen können.

"Communications"

Werden Schwachstellen gefunden, werden die Benutzer zügig darüber informiert und mit Workarounds und Patches versorgt.

Die Phasen des SDL

Aus den "Best Practices" ergibt sich der eigentliche SDL, der aus sieben Phasen besteht. Fünf davon bestehen wiederum aus 3 Schritten, so dass das Ganze auf den ersten Blick ziemlich aufwändig erscheint, siehe Tabelle 1. Aber das täuscht, so schlimm ist sichere Entwicklung gar nicht. Einen Teil der Schritte müssen Sie sowieso so oder so ähnlich durchführen, andere lassen sich i.A. recht einfach realisieren.

Microsoft unterstützt Sie in allen Phasen mit Trainingsmaterialien und/oder Tools.

Tabelle 1: Der vereinfachte Security Development Lifecycle

Falls Sie auf einen SDL mit 5 Phasen stoßen, lassen Sie sich nicht verwirren, i.A. handelt es sich dabei ebenfalls um den hier behandelten "Vereinfachten SDL". Teilweise wird die Trainings-Phase als Voraussetzung für den SDL betrachtet, die Response-Phase als seine Folge. Bei dieser Einteilung besteht der eigentliche SDL nur aus den fünf Phasen 2 bis 6.

Ab der nächsten Folge stellen ich Ihnen die sieben Phasen vor.

Carsten Eilers