Entwicklungszyklus für sichere Software

Veröffentlicht: 30. Mai 2005

Von Steve Lipner und Michael Howard

Dieser Artikel erläutert den Trustworthy Computing Security Development Lifecycle (SDL – Entwicklungszyklus für vertrauenswürdigen Computereinsatz). Diesen Prozess hat Microsoft für die Entwicklung von Software übernommen, die böswilligen Angriffen standhalten muss. Er erweitert die Phasen der Softwareentwicklung bei Microsoft um mehrere auf Sicherheit abzielende Aktivitäten und Projektergebnisse. Zu diesen Aktivitäten und Projektergebnissen zählen die Entwicklung von Bedrohungsmodellen beim Softwareentwurf, die Verwendung von Tools zur statischen Codeanalyse bei der Implementierung sowie das Durchführen von Codeüberprüfungen und Sicherheitstests bei einer gezielten Suche nach Sicherheitsmängeln ("Security Push" – Sicherheitsinitiative). Vor der Veröffentlichung einer nach dem SDL entwickelten Software muss diese eine abschließende Sicherheitsüberprüfung (FSR – Final Security Review) durchlaufen, die von einem von der Entwicklungsgruppe unabhängigen Team durchgeführt wird. Im Vergleich zwischen mit bzw. ohne SDL entwickelter Software wurden in SDL-Software wesentlich weniger Sicherheitslücken entdeckt. In diesem Artikel wird der SDL erläutert und von Erfahrungen bei der Entwicklung von Microsoft-Software nach dem SDL berichtet. Dieser Artikel enthält auch Links zu englischsprachigen Seiten. (19 gedruckte Seiten)

Hinweis
Dieser Artikel ist eine aktualisierte Version von "The Trustworthy Computing Security Development Lifecycle" (in englischer Sprache), der ursprünglich auf der im Dezember 2004 in Tucson, Arizona, mit Unterstützung von IEEE durchgeführten 2004 Annual Computer Security Applications Conference vorgestellt wurde.

Auf dieser Seite

 Einführung
 Der SDL-Prozess
 Implementieren des SDL bei Microsoft
 Ergebnisse der Implementierung des SDL bei Microsoft
 Beobachtungen über die Anwendung des SDL
 Schlussfolgerung
 Danksagung
 Referenzen
 Hinweise

Einführung

Es ist dringend erforderlich, dass sich alle Softwareanbieter mit Sicherheitsbedrohungen befassen. Für Softwareanbieter ist Sicherheit aufgrund der Kräfte des freien Markts und der Notwendigkeit, wichtige Infrastrukturen zu schützen bzw. ein weit verbreitetes Vertrauen in Computertechnik zu wecken, eine grundlegende Anforderung. Für alle Softwareanbieter ist es eine große Herausforderung sicherere Software zu erstellen, die seltener durch Patches aktualisiert werden muss und für die eine weniger lästige Sicherheitsverwaltung erforderlich ist.

Für die Softwareindustrie ist der Schlüssel zum Erfüllen der heutigen Forderung nach verbesserter Sicherheit die Implementierung wiederholbarer Prozesse, die zuverlässig zu messbar besserer Sicherheit führen. Deshalb müssen die Softwarehersteller zu einem strengeren Softwareentwicklungsprozess übergehen, der sich in größerem Maße auf Sicherheit konzentriert. Ein solcher Prozess soll dazu dienen, die Anzahl der noch vorhandenen Sicherheitsschwachstellen im Entwurf, in der Implementierung und in der Dokumentation zu minimieren und diese Schwachstellen so früh wie möglich im Entwicklungszyklus zu erkennen und zu beheben. Die Notwendigkeit für einen solchen Prozess ist für Unternehmens- und Anwendersoftware am größten, die Eingaben aus dem Internet verarbeiten, wichtige und potenziell angriffsgefährdete Systeme steuern oder persönlich identifizierbare Informationen verarbeiten.

Bei der Entwicklung sichererer Software gibt es drei Aspekte: ein wiederholbarer Prozess, die Schulung der Entwickler sowie Bewertungsmaßstäbe und Verantwortlichkeit. Dieses Dokument konzentriert sich auf den SDL-Aspekt des wiederholbaren Prozesses, obwohl auch die Schulung der Entwickler und einige allgemeine Bewertungsmaßstäbe, die den aktuellen Einfluss der Anwendung einer Teilmenge des SDL aufzeigen, erläutert werden.

Wenn die bei Microsoft gesammelten Erfahrungen als Richtlinien gelten können, sollte die Übernahme des SDL bei anderen Unternehmen der Softwareentwicklung keine übertriebenen Kosten verursachen. Nach den Erfahrungen bei Microsoft wiegen die Vorteile, die dadurch entstehen, dass eine sicherere Software entwickelt wird (z. B. weniger Patches und zufriedenere Kunden), die Kosten auf.

Im Zuge des SDL werden durch die Integration von Maßnahmen, die zu verbesserter Softwaresicherheit führen, die Prozesse eines Softwareentwicklungsunternehmens angepasst. In diesem Dokument werden die Maßnahmen zusammengefasst und beschrieben, die in einen typischen Softwareentwicklungszyklus integriert werden können. Ziel dieser Änderungen ist nicht die vollständige Überarbeitung des Prozesses, ihm sollen nur wohl definierte Sicherheitskontrollpunkte und Sicherheitsprojektergebnisse hinzugefügt werden.

In diesem Dokument wird davon ausgegangen, dass es im Softwareentwicklungsunternehmen eine zentrale Gruppe gibt, die folgende Aufgaben übernimmt: Entwickeln und Weiterentwickeln bewährter Sicherheitsmethoden und Verbessern der Prozesse, Unterstützen des gesamten Unternehmens als Quelle für Expertenwissen und Durchführen einer abschließenden Überprüfung (der FSR) vor der Veröffentlichung der Software. Nach den Erfahrungen bei Microsoft ist eine solche Gruppe für eine erfolgreiche Implementierung des SDL und für eine Verbesserung der Softwaresicherheit sehr wichtig. In einigen Unternehmen wird möglicherweise davon ausgegangen, dass die Funktion des zentralen Sicherheitsteams durchaus von einem externen Partner oder Berater durchgeführt werden kann. In diesem Artikel wird die Integration eines Satzes von Schritten beschrieben, der die Softwaresicherheit in dem Softwareentwicklungsprozess verbessern soll, der normalerweise in großen Softwareentwicklungsunternehmen verwendet wird. Diese Schritte wurden bei Microsoft als Teil der Trustworthy Computing-Initiative entworfen und implementiert. Das Ziel dieser Prozessverbesserungen ist die Verminderung der Anzahl und des Schweregrads der Sicherheitsschwachstellen in Software, die bei Kunden zum Einsatz kommt. In diesem Dokument wird der geänderte Softwareentwicklungsprozess, der derzeit bei Microsoft implementiert wird, als der Trustworthy Computing Software Development Lifecycle (SDL – Entwicklungszyklus für vertrauenswürdigen Computereinsatz) bezeichnet.

Die Erfahrungen bei Microsoft zeigen, dass das Sicherheitsteam in der Entwurfs- und der Entwicklungsphase der Software für häufige Interaktionen verfügbar sein muss, und dass dem Team vertrauliche technische Informationen und Geschäftsinformationen zur Verfügung gestellt werden müssen. Aus diesen Gründen wird empfohlen, das Sicherheitsteam innerhalb des Softwareentwicklungsunternehmens einzurichten (obwohl es sich möglicherweise anbieten kann, für den Aufbau des Teams und die Einarbeitung der Teammitglieder Berater zu engagieren).

Der grundlegende Prozess

Der allgemein akzeptierte Softwareentwicklungsprozess bei Microsoft entspricht ungefähr dem Ablauf in Abbildung 1. Im Großen und Ganzen ist dieser Prozess in der industriellen Praxis üblich.

Abbildung 1: Der Standardentwicklungsprozess bei Microsoft

Auch wenn Abbildung 1 fünf Meilensteine enthält und es nach einem Entwicklungsprozess nach dem Wasserfallmodell aussieht, ist der Prozess tatsächlich spiralförmig. Während der Implementierung wird häufig zu den Anforderungen und zum Entwurf zurückgekehrt. Dies geschieht als Reaktion auf veränderte Marktanforderungen und Gegebenheiten, die während der Implementierung der Software auftreten. Darüber hinaus betont der Entwicklungsprozess die Notwendigkeit, fast zu jedem Zeitpunkt über ausführbaren Code zu verfügen, so dass jeder Hauptmeilenstein tatsächlich in die Bereitstellung einer Reihe von Builds aufgeteilt ist, die fortlaufend getestet und (vom Entwicklungsteam) einsatzbereit verwendet werden können.

Übersicht über den SDL

Aus den Erfahrungen mit der Sicherheit realer Software wurden einige höhere Grundsätze zur Erstellung sichererer Software abgeleitet. Microsoft nennt diese Grundsätze SD³+C: Secure by Design (Sicher aufgrund des Entwurfs), Secure by Default (Sicher aufgrund der Standardeinstellungen), Secure in Deployment (Sicher bei der Bereitstellung) und Communications (Kommunikation). Für diese Grundsätze gelten die folgenden kurzen Definitionen:

• Secure by Design: Die Software sollte so geplant, entworfen und implementiert werden, dass sie sich selbst und die Informationen, die sie verarbeitet, schützt und Angriffen standhält.

• Secure by Default: Im Praxiseinsatz kann Software keine perfekte Sicherheit bieten, deshalb sollten die Designer davon ausgehen, dass Sicherheitsfehler vorhanden sind. Um den entstehenden Schaden zu minimieren, wenn Angreifer versuchen, diese noch vorhandenen Fehler auszunutzen, sollte der Standardzustand der Software Sicherheit fördern. Die Software sollte beispielsweise mit den niedrigsten erforderlichen Berechtigungen ausgeführt werden, und Dienste oder Features, die nicht häufig verwendet werden müssen, sollten in der Standardeinstellung deaktiviert oder nur für wenige Benutzer zugänglich sein.

• Secure in Deployment: Zu einer Software sollten Tools und Anleitungen gehören, die Endbenutzer und/oder Administratoren dabei unterstützen, sie sicher zu verwenden. Außerdem sollten Aktualisierungen einfach bereitzustellen sein.

• Communications: Softwareentwickler sollten auf die Entdeckung von Produktschwachstellen vorbereitet sein und offen und verantwortungsbewusst mit Endbenutzern und/oder Administratoren kommunizieren, um ihnen bei Schutzmaßnahmen zu helfen (z. B. durch Patches oder Workarounds).

Zwar stellt jedes Element von SD³+C Anforderungen an den Entwicklungsprozess, jedoch bieten die ersten beiden Elemente (Secure by Design und Secure by Default) die größten Sicherheitsvorteile. Secure by Design fördert Prozesse, durch die in erster Linie die Einführung von Schwachstellen verhindert werden soll. Dahingegen ist für Secure by Default erforderlich, dass die Software in den Standardeinstellungen eine möglichst kleine Angriffsfläche bietet.

Die Einführung von Sicherheitsmaßnahmen, die das SD³+C-Paradigma in den vorhandenen Entwicklungsprozess integrieren sollen, führt zu der Gesamtprozessorganisation in Abbildung 2.

Abbildung 2: Der Entwicklungsprozess bei Microsoft mit den SDL-Verbesserungen

In Abschnitt 2 dieses Dokuments werden die Komponenten des SDL auf einer oberen Ebene beschrieben. Abschnitt 3 enthält eine kurze Zusammenfassung der Besonderheiten der SDL-Implementierung von Microsoft. Abschnitt 4 dieses Dokuments enthält einige Beispieldaten zur Veranschaulichung, dass die frühe Anwendung des SDL bei der Entwicklung von Microsoft Windows Server 2003 und anderer Software im Vergleich zu früheren Softwareversionen zu weniger Sicherheitsschwachstellen und besseren Schweregradbewertungen geführt hat. Abschnitt 5 enthält einige qualitative Betrachtungen über Prozesselemente, die auf Grundlage der Erfahrungen in der Anwendung des SDL bei Microsoft gesammelt wurden. Abschließend enthält Abschnitt 6 einige allgemeine Schlussfolgerungen.

 

Der SDL-Prozess

Wie bereits erwähnt, wird auf die Schulungen für Entwickler in diesem Artikel nicht näher eingegangen. Es muss jedoch unbedingt darauf hingewiesen werden, wie wichtig ein Schulungsprogramm für den Erfolg des SDL ist. Hochschul- und Universitätsabsolventen der Informatik oder ähnlicher Disziplinen mangelt es im Allgemeinen an der erforderlichen Praxis, um sofort vollwertiges Teammitglied zum Entwerfen, Entwickeln und Testen sicherer Software zu werden. Selbst Teilnehmer an Sicherheitskursen haben sich wahrscheinlich mehr mit Verschlüsselungsalgorithmen oder Modellen der Zugriffskontrolle befasst als mit Pufferüberläufen. Im Allgemeinen mangelt es auch Softwareentwicklern, -ingenieuren und -testern aus der Industrie an geeigneten Sicherheitskenntnissen.

Unter diesen Umständen muss sich ein Unternehmen, das versucht, sichere Software zu entwickeln, um die entsprechende Ausbildung der Entwicklungsbelegschaft kümmern. Wie genau dieser Herausforderung zu begegnen ist, variiert je nach der Größe des Unternehmens und den verfügbaren Ressourcen. Ein Unternehmen mit einer großen Entwicklerbelegschaft wird möglicherweise in der Lage sein, ein internes Programm aufzubauen, das seinen Entwicklern fortlaufende Sicherheitsschulungen bietet, dagegen muss sich ein kleineres Unternehmen möglicherweise auf externe Schulungen verlassen. Bei Microsoft muss das gesamte Personal, das an der Softwareentwicklung beteiligt ist, ein jährliches Training zum Auffrischen der Sicherheitskenntnisse durchlaufen.

Anforderungsphase

Bei der Entwicklung sicherer Systeme ist die Notwendigkeit, Sicherheit "von Grund auf" zu betrachten, ein fundamentaler Grundsatz. Obwohl viele Entwicklungsprojekte "nächste Versionen" herstellen, die auf vorhergehenden Versionen aufbauen, bietet die Anforderungsphase und die Anfangsplanung einer neuen Version die besten Möglichkeiten für die Erstellung sicherer Software.

In der Anforderungsphase nimmt das Produktteam Kontakt zum zentralen Sicherheitsteam auf und bittet um Zuweisung eines Sicherheitsberaters (der in der SDL-Implementierung bei Microsoft als der "Sicherheitspartner" bezeichnet wird), der in der weiteren Planung als Ansprechpartner, Ressource und Informationsquelle dient. Der Sicherheitsratgeber unterstützt das Produktteam, indem er Pläne überprüft, Empfehlungen ausspricht und sicherstellt, dass das Sicherheitsteam passende Ressourcen einplant, um den Zeitplan des Produktteams zu unterstützen. Der Sicherheitsratgeber berät das Produktteam in Bezug auf die Sicherheitsmeilensteine und Abbruchkriterien, die abhängig von der Größe, der Komplexität und dem Risiko des Projekts erforderlich sind. Für das Produktteam bleibt der Sicherheitsratgeber von Projektbeginn bis zum Abschluss der FSR und der Veröffentlichung der Software der Ansprechpartner des Sicherheitsteams. Außerdem dient der Sicherheitsratgeber als Kontakt zwischen den Leitungen des Sicherheits- und des Produktteams und berät die Teamleitung, ob die Sicherheitselemente des Projekts im Zeitplan liegen. Dadurch sollen im fortgeschrittenen Prozess Überraschungen in Bezug auf Sicherheitsfragen verhindert werden.

In der Anforderungsphase soll das Produktteam planen, wie Sicherheit in den Entwicklungsprozess integriert wird, Hauptsicherheits-Belange identifizieren und Überlegungen anstellen, wie Softwaresicherheit zu maximieren und gleichzeitig Störungen der Pläne und Zeitpläne zu minimieren sind. Als Teil dieses Prozesses muss das Team überlegen, wie die Sicherheitsfeatures und Sicherheitsmaßnahmen der Software mit anderen Softwareprodukten zusammenarbeiten, mit der sie wahrscheinlich gemeinsam verwendet wird. (Die Schnittstellen zu anderen Softwareprodukten sind ein entscheidender Aspekt in Bezug auf die Benutzeranforderungen, einzelne Produkte in sichere Systeme zu integrieren.) Die in der Anforderungsphase erstellten Planungsdokumente sollten die Gesamtperspektive des Produktteams im Hinblick auf Sicherheitsziele, Herausforderungen und Pläne widerspiegeln. Obwohl die Pläne im Laufe des Projekts noch geändert werden können, ist eine frühe Besprechung dieser Pläne wichtig. Dadurch soll sichergestellt werden, dass keine Anforderungen übersehen werden oder erst im letzten Moment auffallen.

Jedes Produktteam sollte die Anforderungen an Sicherheitsfeatures als Teil dieser Phase auffassen. Obwohl einige Anforderungen an Sicherheitsfeatures aus den Bedrohungsmodellen gefolgert werden können, ist es wahrscheinlich, dass weitere Sicherheitsfeatures aufgrund von Benutzeranforderungen und Kundenwünschen aufzunehmen sind. Außerdem entstehen Anforderungen an Sicherheitsfeatures durch die Notwendigkeit, bestimmten Industriestandards zu entsprechen sowie durch Zertifizierungsprozesse. Das Produktteam sollte diese Anforderungen als Teil des normalen Planungsprozesses erkennen und widerspiegeln.

Entwurfsphase

In der Entwurfsphase werden die allgemeinen Anforderungen und die Struktur der Software identifiziert. In Bezug auf Sicherheit gibt es in der Entwurfsphase die folgenden Hauptelemente:

• Definieren der Sicherheitsarchitektur und der Entwurfsrichtlinien: Definieren Sie die Gesamtstruktur der Software in Bezug auf Sicherheit und identifizieren Sie die Komponenten, deren ordnungsgemäße Funktion grundlegend für die Sicherheit ist (die "Trusted Computing Base"). Identifizieren Sie die Entwurfstechniken für die gesamte Software, z. B. Schichtenbildung, Verwenden von streng typisierten Sprachen, Anwenden der geringsten Berechtigungen und Minimieren der Angriffsfläche. (Schichtenbildung bezeichnet die Organisation der Software in Komponenten, die so strukturiert sind, dass Ringabhängigkeiten zwischen den Komponenten vermieden werden. Die Komponenten sind in Schichten organisiert. Dabei kann eine höhere Schicht von den Diensten der unteren Schichten abhängig sein, eine untere Schicht jedoch nicht von denen einer höheren.) Besonderheiten einzelner Architekturelemente werden in einzelnen Entwurfsspezifikationen verfeinert, die Sicherheitsarchitektur identifiziert jedoch die Gesamtperspektive des Sicherheitsentwurfs.

• Dokumentieren der Elemente der Angriffsfläche der Software. Davon ausgehend, dass keine Software absolut sicher sein kann, ist es wichtig, in der Standardeinstellung allen Benutzern nur die Features zur Verfügung zu stellen, die von den meisten Benutzern verwendet werden, und diese Features nur mit den Berechtigungen zu installieren, die für ihre Ausführung unbedingt erforderlich sind. Das Erfassen der Elemente der Angriffsfläche ist für das Produktteam ein aktueller Bewertungsmaßstab für die Sicherheit in den Standardeinstellungen. Dadurch kann es Instanzen erkennen, durch die Software anfälliger für Angriffe wird. Obwohl einige Instanzen einer größeren Angriffsfläche durch eine erweiterte Funktionalität oder Benutzerfreundlichkeit des Produkts gerechtfertigt werden können, ist es wichtig, diese Instanzen während des Entwurfs und der Implementierung zu erkennen und zu hinterfragen, um die Software in einer möglichst sicheren Standardkonfiguration auszuliefern.

• Bedrohungsmodellierung: Das Produktteam erstellt Bedrohungsmodelle für die einzelnen Komponenten. Mithilfe einer strukturierten Vorgehensweise identifiziert das Komponententeam die Funktionen, die die Software unterstützen muss, und die Schnittstellen, über die auf diese Funktionen zugegriffen werden kann. Bei der Bedrohungsmodellierung werden die Bedrohungen, die den einzelnen Funktionen schaden können, und die Wahrscheinlichkeit ihres Auftretens (mithilfe einer Risikoabschätzung) identifiziert. Anschließend identifiziert das Komponententeam die Gegenmaßnahmen, durch die das Risiko gemindert werden kann: entweder in Form von Sicherheitsfeatures wie Verschlüsselung oder durch eine ordnungsgemäße Funktion der Software, die vor Schaden bewahrt. Somit unterstützt die Bedrohungsmodellierung das Produktteam beim Identifizieren von erforderlichen Sicherheitsfeatures und Bereichen, in denen besonders sorgfältige Codeüberprüfungen und Sicherheitstests erforderlich sind. Die Bedrohungsmodellierung sollte durch ein Tool unterstützt werden, das Bedrohungsmodelle in maschinenlesbarer Form speichern und aktualisieren kann.

• Definieren von zusätzlichen Auslieferungskriterien: Obwohl grundlegende Sicherheitskriterien für die Auslieferung auf Unternehmensebene definiert werden sollten, können für einzelne Produktteams oder Softwareversionen spezifische Kriterien gelten, die vor der Veröffentlichung der Software erfüllt sein müssen. Beispielsweise könnte sich ein Produktteam, das eine aktualisierte Version einer Software entwickelt, die an Kunden ausgeliefert und wahrscheinlich extremen Angriffen ausgesetzt sein wird, dafür entscheiden, dass die neue Software einen gewissen Zeitraum frei von extern berichteten Schwachstellen sein muss, bevor sie veröffentlicht werden kann (d. h., die Schwachstellen sollten im Entwicklungsprozess gefunden und behoben werden, und nicht erst nachdem sie von Kunden gemeldet wurden).

Implementierungsphase

In der Implementierungsphase programmiert, testet und integriert das Produktteam die Software. In dieser Phase werden hauptsächlich Schritte unternommen, die Sicherheitsfehler beheben oder verhindern, dass Sicherheitsfehler entstehen. Dadurch wird die Wahrscheinlichkeit entscheidend verringert, dass Sicherheitsschwachstellen ihren Weg in die endgültige Version der Software finden, die an den Kunden ausgeliefert wird.

Die Ergebnisse der Bedrohungsmodellierung sind in der Implementierungsphase besonders hilfreich. Die Entwickler konzentrieren sich auf die Fehlerfreiheit des Codes, um besonders schwerwiegende Bedrohungen abzuschwächen, und die Tester konzentrieren sich bei ihren Test auf die Überprüfung, ob diese Bedrohungen tatsächlich blockiert oder abgeschwächt werden.

In der Implementierungsphase des SDL gibt es die folgenden Elemente:

• Anwenden von Codierungs- und Teststandards: Programmierstandards helfen den Entwicklern Fehler zu vermeiden, die zu Sicherheits-Schwachstellen führen können. Beispielsweise kann die Verwendung von sichereren und konsistenteren Zeichenfolgenverarbeitungen und Pufferbearbeitungskonstrukten helfen, Schwachstellen durch Pufferüberläufe zu vermeiden. Teststandards und bewährte Methoden tragen dazu bei, dass sich die Tester auf die Erkennung von potenziellen Sicherheitsschwächen konzentrieren können, anstatt nur die ordnungsgemäße Ausführung der Softwarefunktionen und -features zu überprüfen.

• Anwenden von Sicherheitstesttools (einschließlich Fuzzingtools): "Fuzzing" stellt für Software-APIs und Netzwerkschnittstellen strukturierte, jedoch ungültige Eingaben zur Verfügung, mit deren Hilfe Softwareschwachstellen möglichst sicher erkannt werden sollen.

• Anwenden von Tools zur statischen Codeanalyse: Einige Codierungsfehler, die zu Schwachstellen führen (z. B. Pufferüberläufe, Integerüberläufe und nicht initialisierte Variablen), können von Tools erkannt werden. Microsoft hat viel in die Entwicklung solcher Tools investiert (die beiden am längsten verwendeten Tools sind als PREfix und PREfast bekannt) und entwickelt diese Tools in Bezug auf neu entdeckte Arten von Codierungsfehlern und Softwareschwachstellen ständig weiter.

• Durchführen von Codeüberprüfungen: Die automatisierten Tools und Tests werden durch Codeüberprüfungen ergänzt, in denen das Wissen geschulter Entwickler angewendet wird, um den Quellcode zu untersuchen und potenzielle Sicherheitsschwachstellen zu erkennen und zu beheben. Im Entwicklungsprozess sind diese Codeüberprüfungen ein entscheidender Schritt zum Beheben von Sicherheitsschwachstellen in der Software.

Überprüfungsphase

Die Überprüfungsphase ist der Punkt, an dem die Software über den vollen Funktionsumfang verfügt und die Benutzerbetatests beginnen. Während die Software die Betatests durchläuft, führt das Produktteam eine Suche nach Sicherheitsmängeln ("Security Push") durch, zu der Sicherheitscodeüberprüfungen, die über die der Implementierungsphase hinausgehen, und konzentrierte Sicherheitstests gehören.

Microsoft hat diesen Security Push Anfang 2002 in der Überprüfungsphase von Windows Server 2003 und mehreren anderen Softwareversionen eingeführt. Für die Einführung des Security Pushs in den Prozess sprachen die beiden folgenden Gründe:

• Der Entwicklungszyklus der fraglichen Versionen hatte die Überprüfungsphase erreicht, und diese Phase bot sich an, um die konzentrierten Codeüberprüfungen und die erforderlichen Tests durchzuführen.

• Der Security Push stellt in der Überprüfungsphase sicher, dass die Codeüberprüfungen und -tests auf die Endversion der Software abzielen. Außerdem bietet sie die Gelegenheit, den Code, der in der Implementierungsphase entwickelt oder aktualisiert wurde, sowie den "Legacycode" (nicht geänderter alter Code) zu überprüfen.

Der erste Grund spiegelt einen historischen Zufall wider: die Entscheidung, einen Security Push zu starten, wurde ursprünglich in der Überprüfungsphase gefällt. Jedoch ist Microsoft zu dem Schluss gekommen, dass die Durchführung eines Security Pushs in der Überprüfungsphase tatsächlich ein gutes Verfahren ist, um sicherzustellen, dass die Endsoftware die Anforderungen erfüllt, und um eine intensivere Überprüfung des vorhandenen, aus früheren Softwareversionen übernommenen Legacycodes zu gestatten.

Beachten Sie, dass Codeüberprüfungen und -tests von äußerst wichtigem Code (der Teil der "Angriffsfläche" der Software ist) in mehreren Teilen des SDL wichtig sind. Beispielsweise sollten solche Überprüfungen und Tests in der Implementierungsphase erforderlich sein, um eine frühe Behebung jeglicher Probleme zu ermöglichen und die Quelle solcher Probleme zu identifizieren und zu beheben. Außerdem sind sie in der Überprüfungsphase sehr wichtig, wenn das Produkt fast fertig gestellt ist.

Veröffentlichungsphase

In der Veröffentlichungsphase sollte die Software eine abschließende Sicherheitsüberprüfung (FSR – Final Security Review) durchlaufen. Das Ziel der FSR ist die Beantwortung der Frage "Ist diese Software so sicher, dass sie an Kunden ausgeliefert werden kann?" Die FSR wird, abhängig vom Umfang der Software, zwei bis sechs Monate vor der Fertigstellung der Software durchgeführt. Die Software muss sich vor der FSR in einem stabilen Zustand befinden, in dem vor der Veröffentlichung nur noch kleine Änderungen zu erwarten sind, die in keinem Zusammenhang mit Sicherheit stehen.

Die FSR ist eine unabhängige Überprüfung der Software, die vom zentralen Sicherheitsteam des Unternehmens durchgeführt wird. Der Sicherheitsratgeber aus dem Sicherheitsteam berät das Produktteam in Bezug auf den für die Software erforderlichen Umfang der FSR und versorgt das Produktteam vor der FSR mit einer Liste von erforderlichen Ressourcen. Das Produktteam versorgt das Sicherheitsteam mit den Ressourcen und Informationen, die zum Abschließen der FSR benötigt werden. Die FSR beginnt mit dem Ausfüllen eines Fragebogens durch das Produktteam und einem Interview mit einem Mitglied des Sicherheitsteams, der der FSR zugewiesen wurde. In jeder FSR ist eine Überprüfung der Fehler erforderlich, die ursprünglich als Sicherheitsfehler identifiziert wurden, sich jedoch nach genauerer Analyse als ohne Einfluss auf die Sicherheit herausgestellt haben. Dadurch soll sichergestellt werden, dass die Analyse ordnungsgemäß durchgeführt wurde. Außerdem wird die Software in der FSR dahingehend überprüft, ob sie neu berichteten Schwachstellen standhält, die ähnliche Softwareprodukte betreffen. In einer FSR für eine Hauptversion einer Software sind Penetrationstests erforderlich. Außerdem sollte das Sicherheitsteam, wenn möglich, durch externe Sicherheitsberater ergänzt werden.

Die FSR ist kein einfacher Test, bei dem es nur um Bestehen oder Durchfallen geht. Sie hat auch nicht das Ziel, alle noch in der Software vorhandenen Sicherheitsschwachstellen zu finden – das wäre einfach unmöglich. Stattdessen gibt die FSR dem Produktteam und der Leitung des Unternehmens eine Gesamtübersicht über die Sicherheitsverfassung der Software und die Wahrscheinlichkeit, dass sie nach der Veröffentlichung beim Kunden in der Lage sein wird, Angriffen standzuhalten. Wenn bei der FSR für die verbleibenden Schwachstellen ein Muster erkannt wird, sollten diese Schwachstellen nicht einfach behoben werden. Kehren Sie in eine frühere Phase zurück, und entwickeln Sie weitere gezielte Aktionen, um die grundlegenden Ursachen für diese Fehlerart zu behandeln (z. B. durch Verbessern der Schulungen oder Erweitern der Tools).

Support- und Servicephase

Trotz der Anwendung des SDL bei der Entwicklung können die Entwicklungsmethoden nach dem aktuellen Stand der Technik noch nicht die Auslieferung von Software sicherstellen, die keine Schwachstellen enthält – und es sprechen gute Gründe dafür, dass sie dazu nie in der Lage sein werden. Selbst wenn der Entwicklungsprozess bis zur Auslieferung der Software alle Schwachstellen eliminieren könnte, würden neue Angriffe entwickelt werden, und die bisher "sichere" Software wäre plötzlich anfällig. Somit müssen die Produktteams darauf vorbereitet sein, auf neu entdeckte Schwachstellen in der Software zu reagieren, die bereits an Kunden ausgeliefert wurde.

Um geeignet reagieren zu können, müssen die Produktteams darauf vorbereitet sein, Berichte über Schwachstellen auszuwerten und gegebenenfalls Sicherheitshinweise und Aktualisierungen zu veröffentlichen. Außerdem müssen sie eine nachträgliche Analyse der berichteten Schwachstellen durchführen und entsprechend reagieren. Die Antworten auf eine aufgetretene Schwachstelle reichen vom Veröffentlichen einer Aktualisierung für einen isolierten Fehler über das Aktualisieren der Tools zur Codeanalyse bis zum Initiieren von Codeüberprüfungen wichtiger Subsysteme. Das Ziel in der Antwortphase ist es, aus Fehlern zu lernen und mithilfe der Informationen in den Schwachstellenberichten weitere Schwachstellen zu erkennen und zu beheben, bevor sie im Einsatz entdeckt und die Kunden einem Risiko ausgesetzt werden. Außerdem hilft diese Phase dem Produktteam und dem Sicherheitsteam beim Anpassen von Prozessen, damit ähnliche Fehler zukünftig nicht mehr auftreten.

 

Implementieren des SDL bei Microsoft

Die Microsoft-Implementierung des SDL hat sich seit den "Security Pushs" von Anfang 2002 weiterentwickelt. Um den Prozess zu initiieren und Produkte stark in der Entwicklung zu beeinflussen, wurden die Security Pushs zu relativ kurzzeitigen Aktivitäten verdichtet, die über mehrere Phasen des SDL verteilt werden sollten. Die Security Pushs hatten einen bedeutenden Einfluss auf die Pläne, Ressourcen und Zeitpläne der Produktteams und hätten ohne die aktive Unterstützung der obersten Unternehmensleitung von Microsoft sehr viel schwerer durchgeführt werden können. Die Security Pushs konzentrierten sich auf Bedrohungsmodellierung, Codeüberprüfungen und Sicherheitstests (einschließlich Penetrationstests). Die FSR wurde Ende 2002/Anfang 2003 vor der Veröffentlichung von Windows Server 2003 eingeführt. Sie hatte bedeutenden Einfluss auf die Standardkonfiguration, in der Windows Server 2003 schließlich ausgeliefert wurde.

Nach den ersten Security Pushs und FSRs initiierte Microsoft ein Projekt, um den SDL-Prozess zu formalisieren. Vier spezifische Ergebnisse dieses Projekts sind einer besonderen Erwähnung wert:

• Richtlinie zum Implementieren der obligatorischen Anwendung des SDL

• Obligatorische Schulung des Entwicklungspersonals

• Bewertungsmaßstäbe für Produktteams

• Die Rolle des zentralen Sicherheitsteams

In den folgenden Abschnitten werden diese Bereiche erläutert.

Obligatorische Anwendung des SDL

Angesichts der aufgezeigten Vorteile des SDL (siehe Abschnitt 5) traf Microsoft die Entscheidung zum Formalisieren einer Anforderung, nach der der SDL für einen großen Softwarebereich angewendet werden muss. Mit dem Schreiben dieses Dokuments wird der SDL für jede Software obligatorisch, auf die folgende Merkmale zutreffen:

• Zur Verarbeitung von persönlichen oder vertraulichen Informationen gedacht

• Zur Verwendung in einem Unternehmen oder in anderen Organisationen (einschließlich Regierungsorganisationen, akademischen oder nicht gewinnorientierten Organisationen) gedacht

• Zur Verbindung mit dem Internet oder einer anderen Netzwerkumgebung gedacht

Zu den Softwareprodukten, die nicht von dieser Vorgabe erfasst werden, zählen eigenständige Anwendungen, die nicht den oben genannten Kriterien entsprechen (z. B. Spiele für sehr kleine Kinder). Natürlich verbietet der SDL solchen Softwareprodukten, die Sicherheit der Plattform (Betriebssystem oder andere Software) zu stören, auf der die Software ausgeführt wird.

Obligatorische Schulung

Ein Hauptaspekt der Security Pushs von Anfang 2002 war die teamweite Schulung aller Entwickler, Tester und Programm-Manager sowie des Dokumentierungspersonals für Produktgruppen. Microsoft hat eine Anforderung formalisiert, nach der für die Entwickler in Unternehmen, deren Software nach dem SDL erstellt wird, jährliche Sicherheitsschulungen durchzuführen sind. Diese Schulungen müssen aufgrund der Tatsache jährlich durchgeführt werden, dass Sicherheit kein statischer Bereich ist, da sich die Bedrohungen, Angriffe und Abwehrmöglichkeiten weiterentwickeln. Solange sich Bedrohungen verändern, sind sogar für Entwickler, die in Bezug auf die ihre Software betreffenden Sicherheitsaspekte äußerst kompetent und qualifiziert waren, zusätzliche Schulungen erforderlich. Beispielsweise ist die Bedeutung von Schwachstellen durch Integerüberläufe in den letzten vier Jahren dramatisch angestiegen, und kürzlich wurde gezeigt, dass einige Verschlüsselungsalgorithmen bisher unerkannte Schwachstellen enthalten.

Microsoft hat eine allgemeine Einführung und Aktualisierung in Bezug auf Sicherheit entwickelt, die Entwicklern in "Live-Trainings" und mithilfe digitaler Medien vermittelt wird. Microsoft hat diesen Kurs als Basis für spezialisierte Schulungen verwendet, in denen nach Softwaretechnologie und nach Entwicklerrolle unterschieden wird. Derzeit erstellt Microsoft einen Lehrplan für Sicherheitsschulungen, der eine weitere Spezialisierung nach Technologie, Rolle und Stand der Teilnehmerkenntnisse einführt.

Viele Partner und Kunden von Microsoft haben sich nach der Verfügbarkeit der Sicherheitsschulungen und -prozesse von Microsoft erkundigt. Bei Microsoft Press wurden Bücher über die internen Methoden von Microsoft für sicheren Entwurf, sicheres Codieren und über Bedrohungsmodellierung veröffentlicht, und Microsoft Learning bietet Kurse auf Grundlage der internen Methoden von Microsoft an.

Bewertungsmaßstäbe für Produktteams

Als Unternehmen folgt Microsoft dem Motto "Wenn Sie etwas nicht messen können, können Sie es auch nicht verwalten". Obwohl es sehr schwer ist, Bewertungsmaßstäbe zu finden, mit denen sich die Sicherheit von Software zuverlässig messen lässt, gibt es durchaus Bewertungsmaßstäbe, die stellvertretend für Software-Sicherheit sind. Diese Bewertungsmaßstäbe reichen von der Schulungsabdeckung der Entwickler (zu Beginn des Entwicklungszyklus) bis zu der Rate der entdeckten Schwachstellen in der Software, die an Kunden ausgeliefert wurde.

Microsoft hat einen Satz von Sicherheitsbewertungsmaßstäben entworfen, mit dem die Produktteams ihren Erfolg in der Implementierung des SDL überwachen können. Diese Bewertungsmaßstäbe zielen auf die Teamimplementierung des SDL ab, von Bedrohungsmodellierung über Codeüberprüfung und Sicherheitstests bis zur Sicherheit der Software, die in der FSR überprüft wird. Da diese Bewertungsmaßstäbe im Laufe der Zeit implementiert werden, sollten sie den Teams ermöglichen, ihre eigene Leistung (besser, gleich oder schlechter) aufzuzeichnen und mit anderen Teams zu vergleichen. Die Leiter der Produktteams und die Geschäftsleitung von Microsoft erhalten regelmäßig Berichte mit aggregierten Bewertungsmaßstäben.

Das zentrale Sicherheitsteam

Einige Zeit vor den Security Pushs von 2002 hat Microsoft das SWI-Team (Secure Windows Initiative) eingerichtet. Dieses Team hatte die Funktion, die Softwaresicherheit zu verbessern, die Schwachstellen in Windows zu reduzieren und anderen Produktteams Sicherheitssupport zu bieten. Das SWI-Team spielte bei der Organisation und Verwaltung des Windows Server 2003-Security Pushs die zentrale Rolle und bot für alle Security Pushs Schulungen und Beratungssupport an, die seit Anfang 2002 durchgeführt wurden. Außerdem führte das SWI-Team die FSR für Windows Server 2003 durch und führte dabei den FSR-Prozess ein.

Mit der formalen Einführung des SDL hat das SWI-Team die Rolle des zentralen Sicherheitsteams für Microsoft übernommen. Zu den Verantwortlichkeiten des SWI-Teams zählen unter anderem:

• Entwicklung, Wartung und Verbesserung des SDL, einschließlich Definition der obligatorischen Aspekte des Prozesses

• Entwicklung, Verbesserung und Durchführung der Entwicklerschulungen

• Bereitstellung der "Sicherheitsratgeber", die die Produktteams durch den Prozess führen, Überprüfungen für Produktteams durchführen und sicherstellen, dass Fragen der Produktteams zeitnah, richtig und autorisiert beantwortet werden

• Dienen als Experten für einen großen Bereich an Sicherheitsthemen und stellen dadurch sicher, dass Fragen, die an oder über die Sicherheitsratgeber gestellt werden, zeitnah und richtig beantwortet werden

• Durchführung der FSRs vor der Veröffentlichung der Software

• Technische Untersuchung der berichteten Schwachstellen in der an Kunden ausgelieferten Software, um sicherzustellen, dass grundlegende Ursachen verstanden werden und die geeignete Antwortebene initiiert wird

Die Verfügbarkeit und Effektivität des SWI-Teams haben sich bei der Implementierung des SDL bei Microsoft als Schlüsselfaktoren erwiesen. Microsoft zielt darauf ab, über einen skalierbaren Prozess zur Entwicklung sichererer Software zu verfügen, und dieses Ziel impliziert die Notwendigkeit, in allen Produktteams über weit verbreitete Sicherheitskompetenz zu verfügen. Jedoch ist ein zentrales und hochqualifiziertes Sicherheitsteam der Schlüssel, um die Arbeit in den Produktteams des Unternehmens zu beschleunigen und sie beim Erstellen sichererer Software zu unterstützen. Außerdem stellt es sicher, dass die FSR nicht innerhalb des Produktteams durchgeführt wird.

 

Ergebnisse der Implementierung des SDL bei Microsoft

Noch kann Microsoft keine endgültigen Aussagen treffen, ob der SDL die Sicherheit von Microsoft-Software verbessert, jedoch sind die bisherigen Ergebnisse äußerst ermutigend.

Windows Server 2003 war die erste Betriebssystemversion von Microsoft, in der große Teile des SDL implementiert wurden. Abbildung 3 zeigt für die beiden aktuellsten Microsoft-Serverbetriebssysteme, Windows 2000 und Windows Server 2003, die Anzahl der nach der Veröffentlichung innerhalb eines Jahres veröffentlichten Sicherheitsbulletins. (Bei der Veröffentlichung von Windows 2000 verfügte Microsoft noch nicht über ein formales Bewertungssystem für den Schweregrad eines Sicherheitsbulletins. Microsoft hat die Sicherheitsbulletins für Windows 2000 mit dem aktuellen System zur Bewertung von Schweregraden ausgewertet.) Wie in diesem Artikel bereits erläutert, wurde Windows Server 2003 nach den meisten (nicht allen) SDL-Prozessen entwickelt, Windows 2000 jedoch nicht.

Abbildung 3: Kritische und hohe Windows-Sicherheitsbulletins vor bzw. nach SDL

Die Definition der Schweregradklassen finden Sie unter https://www.microsoft.com/germany/technet/datenbank/articles/527029.mspx.

Auch bei anderen Softwareversionen von Microsoft wurden Elemente des SDL angewendet. Die Produktteams von SQL Server und Exchange Server haben vor der Veröffentlichung eines Service Packs (eine Softwareversion, in der Patches für Sicherheitsschwachstellen und andere Probleme zusammengefasst sind), einen Security Push einschließlich Bedrohungsmodellierung, Codeüberprüfungen und Sicherheitstests durchgeführt. Die Ergebnisse des SQL Server-Security Pushs wurden in Service Pack 3 für SQL Server 2000 aufgenommen und die des Exchange Server-Security Pushs in Service Pack 3 für Exchange 2000 Server. Die Abbildungen 4 und 5 zeigen, wie viele Sicherheitsbulletins in gleichlangen Zeiträumen (24 Monate für SQL Server 2000 und 18 Monate für Exchange 2000 Server) vor bzw. nach der Veröffentlichung des entsprechenden Service Packs veröffentlicht wurden.

Abbildung 4: SQL Server 2000-Sicherheitsbulletins vor bzw. nach SDL

Abbildung 5: Exchange Server 2000-Sicherheitsbulletins vor bzw. nach SDL

Ein weiteres ermutigendes Beispiel ist die IIS-Komponente (Internet Information Server) von Windows Server 2003 (IIS 6): In den beiden Jahren seit der Veröffentlichung hat Microsoft ein den Webserver betreffendes Sicherheitsbulletin veröffentlicht, und das bezüglich einer Komponente (WebDAV), die in der Standardeinstellung nicht installiert wird.

Obwohl die Auswahl der Sicherheitsschwachstellen noch klein ist und die Zeiträume begrenzt sind, deuten diese Ergebnisse darauf hin, dass der SDL wirkungsvoll ist. Microsoft überwacht andauernd die Anzahl der Schwachstellen in Windows Server 2003 und den Service Packs für Exchange Server und SQL Server, um festzustellen, ob sich die bisherigen Trends fortsetzen. Außerdem analysiert Microsoft neue Versionen anderer Microsoft-Softwareprodukte, die nach der vollständigen Implementierung des SDL ausgeliefert werden, um festzustellen, ob die Häufigkeiten und Schweregradbewertungen der Sicherheitsschwachstellen weiterhin sinken.

 

Beobachtungen über die Anwendung des SDL

Anhand der im vorigen Abschnitt vorgestellten Daten kann abgeschätzt werden, "was" der SDL leisten kann. In diesem Abschnitt wird versucht, einige Fragen zu beantworten, "wie" der SDL-Prozess funktioniert. Im Gegensatz zum vorherigen Abschnitt, der auf nackten Zahlen basiert (bei Microsoft werden Schwachstellenberichte und Sicherheitsbulletins sehr genau verfolgt), basiert dieser Abschnitt auf subjektiven Daten, d. h. auf Beobachtungen und Meinungen von Mitgliedern des SWI-Teams.

Effektivität von SDL-Elementen

Der SDL besteht aus vielen Komponenten-Unterprozessen, die über den gesamten Softwareentwicklungszyklus verteilt sind. Das SDL-Team sollte die Unterprozesse hinsichtlich ihrer Effektivität priorisieren: welche bringen den größten Nutzen und welche wurden ausprobiert, jedoch als weniger hilfreich empfunden.

Das gesamte SWI-Team war sich einig, dass die Bedrohungsmodellierung die wichtigste SDL-Komponente ist. Offensichtlich wird die Bedrohungsmodellierung nicht alleine angewendet, da sie den Entwurf, die Codeüberprüfungen und die Tests beeinflusst. Außerdem wäre ein Prozess, der die Bedrohungsmodellierung nur implementiert, anschließend als Reaktion auf die Modelle jedoch keine Aktionen folgen lässt (z. B. da die Effektivität der gefundenen Verbesserungen nicht getestet wird), völlig uneffektiv. In Statistiken, in denen nur gezählt wird, wie häufig Fehler auftreten, wird die Rolle der Bedrohungsmodellierung oft unterbewertet, da durch viele der Beiträge der Bedrohungsmodellierung sichergestellt werden soll, dass zu Sicherheitsschwachstellen führende Fehler erst gar nicht auftreten. Jedoch ist die Rolle der Bedrohungsmodellierung im Prozess zur Entwicklung sicherer Software so wichtig, dass sie ganz klar an erster Stelle in der Liste steht.

Da der SDL bei Microsoft noch immer ein relativ neuer Prozess ist, wurde bisher noch keine Komponente des Prozesses entfernt. Jedoch wird eine Erkenntnis für erfahrene Sicherheitsexperten keine Überraschung sein: Penetrationstests sind nicht das Mittel, um perfekte Sicherheit zu gewährleisten. Penetrationstests sind ein Element der FSR für die Hauptversion einer Software. Jedoch konzentrieren sich die Aktivitäten der Produktteams über den gesamten Zyklus nicht auf Penetrationstests, sondern auf Bedrohungsmodellierung, Codeüberprüfungen, die Verwendung von automatisierten Tools und Fuzztests. Diese Maßnahmen sind beim Verhindern oder Entfernen von Sicherheitsfehlern viel gründlicher als die klassischen Ad-hoc-Belastungstests. Das FSR-Element in Bezug auf Penetrationstests eignet sich eher zum Feststellen, ob die Software veröffentlicht werden kann, als zum Finden und Beheben von Sicherheitsfehlern. Wenn der FSR-Penetrationstest viele Sicherheitsfehler offenbart, wurden vorhergehende Phasen nicht ausreichend effektiv durchgeführt. In diesem Falle sollten Sie nicht einfach die gefundenen Fehler beheben und die Software veröffentlichen, sondern die Aktivitäten erneut durchführen, die in vorherigen Phasen eigentlich bereits abgeschlossen sein sollten.

Tools, Tests und Codeüberprüfungen

Tools zur statischen Analyse, Fuzztests und Codeüberprüfungen ergänzen sich gegenseitig. Microsoft hat sehr viel in Tools zur statischen Codeanalyse investiert. Die Verwendung dieser Tools ist ein wesentlicher Teil des SDL. Diese Tools helfen beim Auffinden vieler Codierungsfehler, die Sicherheitsschwachstellen verursachen können, besonders Pufferüberläufe. Jedoch finden die Tools nach dem aktuellen Stand der Technik nicht alle Fehler. Manuelle Codeüberprüfungen sind für den SDL noch immer zum Erkennen von Fehlern erforderlich, nach denen die Tools nicht suchen, und zum Erkennen von Möglichkeiten, wie diese Tools verbessert werden können. Der in den Referenzen genannte MSDN-Artikel von Michael Howard enthält eine Übersicht über den allgemeinen Ansatz zum Durchführen von Codesicherheitsüberprüfungen, der den Entwicklern bei Microsoft beigebracht wird.

Erst in letzter Zeit werden Fuzztests im SDL besonders hervorgehoben, jedoch sind die bisherigen Ergebnisse äußerst ermutigend. Im Gegensatz zu den Tools zur statischen Codeanalyse müssen Tools für Fuzztests für jedes Dateiformat und/oder Netzwerkprotokoll erstellt (oder zumindest konfiguriert) werden. Deshalb sind sie häufig zum Auffinden von Fehlern in der Lage, die von Tools zur statischen Analyse nicht gefunden werden. Mithilfe von Bedrohungsmodellen können die Produktteams Schnittstellen und Formate für die Tests einfach priorisieren. Die Ergebnisse der Fuzztests sind nicht absolut deterministisch (die Tools führen eine endliche Zahl an Durchläufen durch und es kann nicht garantiert werden, dass sie alle Fehler finden), jedoch hat die Erfahrung gezeigt, dass durch eine annehmbare Anzahl von Fuzztests wahrscheinlich alle "interessanten" Fehler gefunden werden, die andernfalls möglicherweise als Sicherheitsschwachstellen ausgenutzt werden könnten.

Investitionen

Obligatorische Sicherheitsschulungen sind für ein Unternehmen von der Größe der Microsoft-Entwicklungsbelegschaft eine große Investition. Die Schulungen werden in einer Kombination aus persönlichen (von einem Schulungsleiter durchgeführten) Klassen und Onlinematerialien vermittelt. Das Onlinematerial ist eine besonders wertvolle Möglichkeit, um kleinen Entwicklerteams, die sich an Standorten befinden, die nicht in der Nähe des Microsoft-Hauptsitzes sind, Schulungen bereitzustellen. Für Teams, die sich auf Security Pushs oder andere Schlüsselaktivitäten vorbereiten, hat sich das Live-Training als besonders effektiv erwiesen, wenn alle Mitglieder daran teilnehmen. In diesen Fällen hat es sich nach den Erfahrungen bei Microsoft gezeigt, dass die Lernerfolge des Teams nicht nur in den Schulungsräumen erzielt werden, sondern auch bei der Durchführung des Security Pushs. Die Sicherheitsschulungen (normalerweise Halbtagsschulungen) sind deshalb besonders effektiv, da sich alle Teilnehmer der Arbeitsgruppe auf Sicherheit konzentrieren.

In den letzten Jahren wurde das Thema Sicherheit bei Microsoft immer wichtiger, und in gleichem Maße ist das zentrale Sicherheitsteam (SWI-Team) gewachsen. Absichtlich ist das Team im Vergleich zur gesamten Entwicklerbelegschaft von Microsoft eher klein und hebt "skalierbare" Ansätze hervor, um so sicherzustellen, dass die Verantwortlichkeit und die Ressourcen zum Herstellen sichererer Software in den Produktteams verbleiben. Dieser Fokus auf Skalierung spiegelt sich in einigen Methoden wider, z. B. im Hervorheben von Schulungen und Tools, im Bereitstellen von Sicherheitsratgebern, die das Produktteam dabei unterstützen, dass es seine Probleme eigenständig lösen kann (anstatt die Probleme für das Team zu lösen), und im Durchführen von Überprüfungen (einschließlich der FSR), um dem Produktteam Feedback über den Fertigstellungsgrad der Software zu geben.

Ergebnisse

Der ultimative Test für den SDL ist der Umfang, in dem es Schwachstellen in Microsoft-Software entfernt und entgegenwirkt. Die bisherigen Erfahrungen (siehe Abschnitt 4) zeigen, dass der SDL diesen Test besteht. Des Weiteren wertet Microsoft von externer Seite berichtete Schwachstellen bezüglich ihres Einflusses auf Softwareversionen aus, die sich in der Entwicklung befinden. Erfahrungen der letzten Zeit haben gezeigt, dass für neue Versionen geplante oder in diesen implementierte Sicherheitsmaßnahmen Angriffe blockieren, die sich für ältere Versionen immer öfter als effektiv erwiesen haben. Das kürzlich veröffentlichte Service Pack 2 für Windows XP wurde auf diese Weise überprüft, und für geplante Sicherheitsänderungen, die jedoch noch nicht implementiert oder öffentlich vorgestellt wurden, hat sich herausgestellt, dass sie eine bemerkenswerte Anzahl an Schwachstellen eliminieren, die von Microsoft-externen Sicherheitsexperten über vorherige Versionen von Windows berichtet wurden.

 

Schlussfolgerung

Die Erfahrungen bei Microsoft weisen darauf hin, dass der SDL das Auftreten von Sicherheits-Schwachstellen effektiv vermindert. Die erste Implementierung des SDL (in Windows Server 2003, Service Pack 3 für SQL Server 2000 und Service Pack 3 für Exchange 2000 Server) führte zu deutlichen Verbesserungen der Softwaresicherheit, und für spätere Softwareversionen scheinen sich aufgrund von Weiterentwicklungen am SDL weitere Verbesserungen anzudeuten.

Die inkrementelle Implementierung der einzelnen SDL-Elemente hat zu inkrementellen Verbesserungen geführt. Das deuten wir als Zeichen für einen effektiven Prozess. Der Prozess ist nicht perfekt und befindet sich noch immer in der Entwicklung – und es ist unwahrscheinlich, dass er in absehbarer Zukunft Perfektion erreichen oder sich nicht mehr weiterentwickeln wird.

Die Entwicklung und Implementierung des SDL ist für Microsoft eine große Investition und hat die Art und Weise, in der Software entworfen, entwickelt und getestet wird, entscheidend verändert. Die wachsende Bedeutung von Software für die Gesellschaft hebt die Notwendigkeit für Microsoft und die Industrie als Ganzes hervor, die Sicherheit von Software laufend zu verbessern. Deshalb wurden dieser Artikel über den SDL und Bücher über spezielle Techniken (siehe Referenzen) veröffentlicht, um die Erfahrungen von Microsoft mit der Softwareindustrie zu teilen.

 

Danksagung

Die erste Entwicklung dieses Dokuments begann Ende 2002 als gemeinsame Anstrengung der aktuellen Autoren. Das Dokument wurde parallel zur Weiterentwicklung des SDL aktualisiert, und die aktuelle Version wurde über den Sommer und Herbst 2004 vorbereitet. Die Autoren möchten den Mitgliedern des Microsoft SWI-Teams Matt Thomlinson, Matt Lyons, Jamil Villani und Eric Bidstrup für die Definition und die Verfeinerungen des SDL danken. Neben den genannten Mitarbeitern haben uns Scott Charney und Phil Reitinger (Microsoft), sowie Jeannette Wing (Carnegie Mellon University) mit ihren Kommentaren zu den Entwürfen sehr geholfen. Außerdem möchten die Autoren Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri und James Whittaker für ihre Kommentare und Vorschläge zu diesem Artikel danken.

 

Referenzen

Trustworthy Computing White Paper (in englischer Sprache) von Craig Mundie

Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users (in englischer Sprache) von Michael Howard, MSDN Magazine, November 2004

Expert Tips for Finding Security Defects in Your Code (in englischer Sprache) von Michael Howard, MSDN Magazine, November 2003

Writing Secure Code (in englischer Sprache) von Michael Howard und David LeBlanc, Zweite Ausgabe, Microsoft Press, Redmond, Washington, 2003

Threat Modeling (in englischer Sprache) von Frank Swiderski und Window Snyder, Microsoft Press, Redmond, Washington, 2004

 

Hinweise

Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.

Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Ohne Einschränkung der Rechte gemäß dem Urheberrecht darf ohne ausdrückliche schriftliche Genehmigung der Microsoft Corporation kein Teil dieser Unterlagen für irgendwelche Zwecke vervielfältigt, gespeichert oder übertragen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen oder anderweitig) und zu welchem Zweck dies geschieht.

Microsoft Corporation kann Besitzer von Patenten oder Patentanträgen, Marken, Urheberrechten oder anderen Rechten über geistiges Eigentum sein, die den Inhalt dieses Dokuments betreffen. Die Bereitstellung dieses Dokuments erteilt keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder anderem geistigen Eigentum, ausgenommen, dies wurde explizit durch einen schriftlich festgehaltenen Lizenzvertrag mit der Microsoft Corporation vereinbart.

© 2005 Microsoft Corporation. Alle Rechte vorbehalten. Für bestimmte Teile dieses Whitepapers gilt: © 2004 Institute of Electrical and Electronics Engineers, Incorporated. Alle Rechte vorbehalten.

Microsoft, MSDN, Windows und Windows Server sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.