Der Sicherheits-Entwicklungszyklus bei Microsoft

  • Artikel

Wie wird's gemacht?

Veröffentlicht: 15. Dez 2005

Von Michael Howard

Es gibt zwei Ziele, die sich Microsoft mit SDL gesetzt hat: Verkleinern der Anzahl von sicherheitsrelevanten Entwurfs- und Codemängeln sowie Verringern des Schweregrads gegebenenfalls verbleibender Mängel. Dies entspricht unserem oft zitierten Grundsatz: "Secure by Design, Secure by Default, Secure in Deployment and Communication" (kurz: SD3+C) ("Sicherheit im Entwurf, Sicherheit als Standard, Sicherheit bei Bereitstellung und Kommunikation"). SDL behandelt im Wesentlichen die ersten beiden Forderungen dieses Grundsatzes. "Secure by Design" bedeutet, dass die Sicherheit von Code und Entwurf von vornherein gewährleistet wird. "Secure by Default" berücksichtigt, dass dies eigentlich nicht möglich ist. In Wirklichkeit werden Sie nie erreichen, dass Code zu 100 % fehlerfrei ist. Mehr dazu jedoch später, wenn ich die Verringerung der Angriffsfläche behandle.

In diesem Artikel wird SDL bei der Software-Entwicklung erläutert. Ich werde erklären, wie Sie sich einige der von Microsoft beim Implementieren von SDL gewonnenen Erkenntnisse und Konzepte für die eigene Softwareentwicklung zunutze machen können. SDL ist im Hinblick auf die Vorgehensweise bei der Softwareentwicklung prozessagnostisch. Ob Sie nun ein Wasserfallmodell, ein spiralförmiges Modell oder ein flexibles Modell verwenden, spielt keine Rolle: Sie können in jedem Fall die Prozessverbesserungen von SDL nutzen. Im Zuge von SDL werden die Vorgänge in einem Softwareentwicklungs-Unternehmen durch die Integration von Maßnahmen für verbesserte Software-Sicherheit angepasst. Wirklich neu und bedeutsam bei SDL ist die Verbesserung der Softwarequalität durch Vermeiden von Sicherheitsmängeln.

SDL fügt einem beliebigen Softwareentwicklungsprozess Sicherheitsüberprüfungen und -maßnahmen hinzu. Abbildung 1 stellt dar, wie SDL in einem "generischen" Prozess umgesetzt wird. Wenn es Sie glücklich macht, wickeln Sie SDL um eine Spirale oder lassen Sie es einen Wasserfall hinunterfließen.

Ich werde alle wichtigen Phasen behandeln und kurz darstellen, wie Sie SDL in Ihrer Organisation implementieren können.

Auf dieser Seite

Unternehmensführung und Mitarbeiterschulung Unternehmensführung und Mitarbeiterschulung
Die Entwurfsphase Die Entwurfsphase
Bedrohungsmodellierung Bedrohungsmodellierung
Die Entwicklungsphase Die Entwicklungsphase
Sicherheitstests Sicherheitstests
Security Push Security Push
Abschließende Sicherheitsüberprüfungen Abschließende Sicherheitsüberprüfungen
Die Sicherheitsantwort Die Sicherheitsantwort
Funktioniert SDL? Funktioniert SDL?
Der Autor Der Autor

Unternehmensführung und Mitarbeiterschulung

Ich werde oft gefragt, warum SDL bei Microsoft so erfolgreich ist. Die Antwort ist sehr einfach: Unterstützung durch die Unternehmensführung, Mitarbeiterschulung und Know-how. Bill Gates' und Steve Ballmers Engagement für SDL hat sich als ebenso bedeutend herausgestellt wie ein geschultes Softwareentwicklungsteam.

In der Unternehmensführung müssen eine oder mehrere Personen zu Ansprechpartnern in Sachen Sicherheit ernannt werden. Zu deren Aufgabenbereich gehört es, stets über die aktuellsten Sicherheitsprobleme informiert zu sein, Sicherheit bei der Softwareentwicklung voranzutreiben und im Falle schwieriger Sicherheitsfragen die richtigen Entscheidungen zu treffen. Die Führungsperson(en) sollte(n) die Vielzahl an Newsgroups für Sicherheitsfragen im Auge behalten, wie z. B. Bugtraq (http://www.securityfocus.com/).

Wenn Softwareentwickler keine Kenntnisse in Sicherheitsgrundlagen, häufigen Sicherheitsmängeln, Grundlagen zum sicheren Entwurf oder zu Sicherheitstests besitzen, sind sie wahrscheinlich nicht in der Lage, sichere Software zu erstellen. Dies sei hier erwähnt, da Softwareentwickler im Allgemeinen Sicherheitsfragen nicht genügend Aufmerksamkeit zukommen lassen. Unter Umständen verfügen sie über eine umfassende Kenntnis der Sicherheitsfunktionen, benötigen jedoch ein besseres Verständnis davon, wie Funktionen allgemein sicher entwickelt und bereitgestellt werden können. Leider kann mit dem Begriff "Sicherheit" zweierlei gemeint sein, da es sich um verschiedene Seiten einer Medaille handelt. Bei Sicherheitsfunktionen dreht sich alles um die Funktionsweise, beispielsweise die der internen Vorgänge der Sandbox von Java oder der Common Language Runtime (CLR), oder es geht um Verschlüsselungsalgorithmen wie DES oder RSA. Während dies interessante und nützliche Themen sind, hilft die Erkenntnis, dass es sich beim Verschlüsselungsalgorithmus DES um ein 16-faches Feistel-Netzwerk handelt, nicht wirklich beim Erstellen sichererer Software. Die Beschränkungen von DES und die Tatsache, dass seine Schlüsselgröße für heutige Bedrohungen erheblich zu klein ist, sind nützliche Erkenntnisse. Solche Informationen gehören zu den wichtigen Grundlagen für das Erstellen von sicheren Funktionen.

Tatsächlich von Bedeutung ist die Tatsache, dass an den meisten Schulen, Universitäten und Fachhochschulen Sicherheitsfunktionen durchaus behandelt werden. Das Erstellen sicherer Software wird jedoch nicht gelehrt. Das bedeutet, dass an diesen Schulen Jahr für Jahr wie am Fließband eine Heerschar von Softwareentwicklern ausgebildet werden, die glauben, dass sie über das Erstellen sicherer Software Bescheid wissen, weil Sie gelernt haben, wie eine Firewall funktioniert. Kurz gesagt, Sie können sich nicht unbedingt darauf verlassen, dass jemand, den Sie einstellen, eine Sicherheitsverteidigung für Ihre Software erstellen kann, wenn Sie sich nicht nach seinen Erfahrungen und seinem Wissen zu diesem bestimmten Thema erkundigen.

Eine der vielen guten Quellen für Online-Sicherheitsschulungen und angeleitete Schulungen ist Microsoft eLearning (http://www.microsoftelearning.com/security/). Der Sicherheitsleitfaden für Entwickler wurde aus Teilen der Sicherheitsgrundlagen zusammengestellt, die bei Microsoft zur Verfügung stehen.

Sie sollten sich auch ein paar gute Bücher über Softwaresicherheit zulegen. In Abbildung 2 sind einige aufgeführt.

In einigen Unternehmensbereichen von Microsoft wurden Buchclubs eingerichtet, in denen jeweils ein Kapitel eines bestimmten Buches gelesen und anschließend gemeinsam diskutiert wird. Um ihre Kenntnisse zu erweitern, suchen diese Personen in bekannten Sicherheitsportalen, wie z. B. Bugtraq, nach Beispielen für Mängel und Entwurfsprobleme.

Ziehen Sie in Betracht, dass Mitarbeiter aus dem Bereich Sicherheit entsprechende Themen vorstellen, einschließlich häufiger Sicherheitsmängel im Code (Pufferüberlauf, siteübergreifende Skripts, SQL Injection, Ganzzahlarithmetik, schwache Verschlüsselung usw.), sicheren Entwürfen, Bedrohungsmodellen und Sicherheitstests. Um den Erläuterungen weiter Detailfülle und Relevanz zu verleihen, können Sie Mängel in selbst geschriebenem Code suchen und diese als Beispiele für andere Entwickler heranziehen.

Schließlich sollten Mitarbeiter in der Softwareentwicklung ermutigt werden, Ihre Fähigkeiten wenigstens einmal im Jahr selbständig oder bei entsprechenden Veranstaltungen durch Betreuer zu erweitern. Dies sollte zudem dokumentiert werden, damit niemand unberücksichtigt bleibt. Es ist von großer Bedeutung, dass das Personal immer auf dem neuesten Stand in Sachen Sicherheit ist, da sich das Wissen in diesem Bereich ständig erweitert. Ein Fehler, der heute noch gewöhnlich erscheint, kann sich morgen als bedeutende Sicherheits-Schwachstelle herausstellen.

Die Entwurfsphase

Die beste Gelegenheit, den Sicherheitsentwurf eines Produkts zu beeinflussen, ist zu einem frühen Zeitpunkt des Produktionszyklus. Gemeint ist die Phase, in der Architekten, Entwickler und Designer gewöhnlich die meisten Funktionen entwerfen. Zu Beginn eines Entwurf steht typischerweise eine sehr kurze Beschreibung der gewünschten Funktionalität (manchmal in Form einer kurzen Übersicht über die Funktionen), gefolgt von einer Funktionsspezifikation, durch die die Funktion vom Standpunkt des Kunden aus beschrieben wird. Anschließend wird eine Entwurfsspezifikation erstellt, welche die technischen Einzelheiten enthält, die die Art und Weise der Funktionsimplementierung kurz darstellen.

Wenn Sie eine flexible Entwicklungsmethode verwenden, können Sie sich einfach für die kürzere Übersicht auf einer Seite entscheiden, die jedoch die Sicherheitsaspekte der Komponente umfassen sollte. Funktionsspezifikationen beschreiben gegebenenfalls die Sicherheitsfunktionen, die dem Kunden direkt zugänglich sind. Dazu zählt z. B. eine Endbenutzer-Authentifizierung für den Zugriff auf bestimmte Daten oder zusätzliche Funktionen. Entwurfsspezifikationen beschreiben, wie Sicherheitsfunktionen implementiert werden und wie die Implementierung aller Funktionen als sichere Funktionen gewährleistet wird. Beachten Sie, dass mit "sicheren Funktionen" nicht Sicherheitsfunktionen gemeint sind. Sichere Funktionen werden definiert, damit alle Funktionen auch wirklich mit dem Augenmerk auf Sicherheit entwickelt werden. Dazu zählen z. B. die strikte Verwendung von Verschlüsselungs-APIs, die möglichst durchgängige Verwendung von verwaltetem Code, die genaue Überprüfung der Gültigkeit von Daten vor deren Verarbeitung und einige andere Überlegungen. Beim Entwerfen von Funktionen ist es von entscheidender Bedeutung, Sicherheitsaspekte sorgfältig abzuwägen, damit diese nicht gegen Ende des Entwurfsprozesses mit Gewalt in das Produkt "hineingepresst" werden müssen.

Sämtliche Funktions- und Entwurfsspezifikationen sollten unabhängig von der Dokumentgröße einen Abschnitt enthalten, in dem die Auswirkungen der Komponente auf die Sicherheit beschrieben werden. Informationen zum Inhalt dieses Abschnitts finden Sie im RFC 3552, "Guidelines for Writing RFC Text on Security Considerations" (in englischer Sprache).

Ein wichtiger Teil des Entwurfsprozesses ist eine Vorstellung davon, wie die Angriffsfläche der Anwendung oder Komponente verringert werden kann. Offene UDP-Ports zum Internet, auf die anonyme Benutzer zugreifen können, stellen eine größere Angriffsfläche dar als z. B. offene TCP-Ports, deren Zugriff auf einen bestimmten Satz von IP-Adressen beschränkt ist. Ich möchte dieses Thema hier nicht weiter behandeln und verweise stattdessen auf meinen Artikel über die Verringerung der Angriffsfläche, "Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users" (in englischer Sprache) im MSDN®Magazine, November 2004. Abbildung 3 soll als Kurzreferenz dienen, um die Angriffsfläche von Code zu verringern.

Bedrohungsmodellierung

Die Bedrohungsmodellierung muss während des Entwurfsprozesses für das Produkt fertig gestellt werden. Ein Team kann kein sicheres Produkt erstellen, ohne zu wissen, was durch das Produkt geschützt werden soll (persönliche Daten des Kunden wie Kreditkartennummern, ganz zu schweigen von seinem Computer). Darüber hinaus muss das Team über die mit dem Produkt verbundenen Bedrohungen und Schwachstellen ebenso informiert sein wie über Einzelheiten darüber, wie das Produkt diese Bedrohungen mindert. Zudem sind Bedrohungen und Schwachstellen von Bedeutung, die in der Bereitstellungsumgebung für das Produkt existieren und die während der Interaktion und Kopplung mit anderen Produkten oder Systemen in realen End-to-End-Lösungen auftreten. Aus diesem Grund darf ein Produktentwurf ohne Bedrohungsmodell nicht als vollständig angesehen werden. Bedrohungsmodelle sind wichtige Komponenten der Entwurfsphase und beziehen sich sowohl auf die Funktions- als auch die Entwurfsspezifikationen eines Produkts, um zugleich Schwachstellen und deren Vermeidung zu beschreiben.

Ein Verständnis der Bedrohungen für die Software ist ein entscheidender Schritt auf dem Weg zu einem sicheren Produkt. Zu viele Entwickler implementieren für ihre Anwendung Sicherheitstechnologie auf die Schnelle und erklären diese Anwendung dann für sicher. Der Code ist jedoch nicht sicher, solange die entsprechenden Maßnahmen nicht tatsächlich reale Bedrohungen auflösen können. Das ist das Ziel einer Bedrohungsmodellierung. Um von diesem Prozess in weniger als 30 Minuten einen informativen Eindruck zu gewinnen, empfehle ich Ihnen den Weblogeintrag "Guerrilla Threat Modeling" (in englischer Sprache) von meinem Kollegen Peter Torr.

Die Entwicklungsphase

Während der Entwicklungsphase sollten Sie zum Implementieren eines sicheren Entwurfs auch Sicherheitstools und -checklisten sowie "Best Practices" für das Schreiben von sicherem Code implementieren. Denken Sie daran: Ein zuvor sicherer Entwurf kann durch eine schwache Implementierung schnell unsicher werden.

Bevor ich darauf zu sprechen komme, möchte ich noch etwas Wichtiges betonen. Die Sicherheit von Software kann durch Sicherheitstools nicht gewährleistet werden. Diese sind nützlich, jedoch kann Code nur mithilfe von Tools nicht geschützt werden. Gut geschulte Arbeitskräfte, welche diese Tools zum Durchsetzen von Richtlinien verwenden, sind eben durch nichts zu ersetzen. Die aktuelle Version von Visual Studio 2005 Team System Developer's Edition umfasst einige äußerst nützliche Sicherheitstools:

PREfast: Tool zur statischen Analyse von C/C++-Code. Es ist in der Lage, einige heikle Sicherheitsmängel ebenso zu finden wie einige ziemlich offensichtliche Fehler.

Standard Annotation Language (SAL): Von allen Tools bei Visual Studio 2005 ist dies die erstaunlichste Technologie, da mit ihr einige sehr versteckte Fehler gefunden werden können. Betrachten Sie einmal eine Funktion wie diese:

void *function(
    char *buffer, 
    DWORD cbBufferLength);

Sicher wissen Sie, dass buffer an dwBufferLength gebunden ist. Die Länge von buffer wird durch cbBufferLength festgelegt. Der Compiler verfügt jedoch nicht über diese Information, da er nur einen Zeiger und eine 32-Bit-Ganzzahl ohne Vorzeichen erkennt. Mit SAL können die zwei verknüpft werden. Der Header, der diesen Funktionsprototyp enthält, könnte also wie folgt aussehen:

void *function(
    _in_bytecount(cbBufferLength) char *buffer, 
    DWORD cbBufferLength);

Beachten Sie, dass die endgültige Syntax für SAL sich vor Veröffentlichung von Visual Studio 2005 noch einmal ändern kann.

FxCop: Vielleicht haben Sie bereits von FxCop gehört - einem Tool für die Suche nach Mängeln, einschließlich Sicherheitsmängeln in verwaltetem Code. FxCop kann unter https://www.gotdotnet.com/ heruntergeladen werden. Die Visual Studio 2005 enthaltene Version ist jedoch vollständig integriert und in der Lage, auch nach einigen neueren Problemen zu suchen.

Application Verifier (AppVerifier): AppVerifier ist ein Laufzeittool, dass für eine aktive Anwendung ausgeführt wird. Mit AppVerifier können Speicherprobleme zur Laufzeit abgefangen werden, einschließlich Heap-Überläufen.

Zu weiteren Tools und Anforderungen bei Microsoft zählen:

  • Sämtlicher unverwalteter C/C++-Code muss mit der /GS-Stapelüberlaufserkennung kompiliert werden.

  • Sämtlicher unverwalteter C/C++-Code muss mit der /SafeSEH-Option verknüpft werden.

  • Sämtlicher RPC-Code muss mit dem MIDL-Flag /robust kompiliert werden.

  • Von FxCop und PREfast erkannte Sicherheitsprobleme müssen behoben werden.

  • Die in Abbildung 4 aufgeführten Funktionen sind für neuen Code gesperrt und sollten mit der Zeit aus Legacycode entfernt werden.

Informationen zum Strsafe-Zeichenfolgenersetzungscode finden Sie unter "Strsafe.h: Safer String Handling in C" (in englischer Sprache). Die Safe C-Bibliothek ist der neue, in Visual Studio 2005 integrierte Ersatz für die C-Laufzeitbibliothek. Weitere Informationen finden Sie unter "Safe! Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries" (in englischer Sprache).

Sicherheitstests

Eine sehr nützliche Testmethode für die Suche nach Sicherheitsmängeln ist "Fuzzing", bei dem gültige Daten erfasst und umgewandelt werden, um dann eine Anwendung beim Verarbeiten dieser Daten zu überwachen. Im einfachsten Fall können Sie eine Bibliothek mit gültigen Dateien erstellen, die von der Anwendung verarbeitet werden. Anschließend beschädigen Sie gezielt eine Datei und versuchen, diese mit der Anwendung abzuspielen oder darzustellen. Führen Sie die Anwendung unter Application Verifier mit aktivierter Heap-Überprüfung aus, um weitere Fehler einfacher finden zu können. Beispiele für das Umwandeln von Daten sind u. a.:

  • Austausch zufälliger Bytes in einer Datei

  • Schreiben einer zufälligen Folge von Bytes zufälliger Größe an einer zufälligen Stelle in der Datei

  • Suche nach bekannten Ganzzahlen, um das Vorzeichen zu ändern oder deren Größe, so dass diese zu klein oder zu groß sind

  • Suche nach ASCII- oder Unicodezeichen, um das nachgestellte NULL-Zeichen in ein von NULL verschiedenes Zeichen umzuwandeln.

Michael Sutton und Adam Greene haben bei Blackhat USA 2005 eine interessante Vorlesung über Fuzzing gehalten. Sie können diese hier nachlesen: The Art of File Format Fuzzing (in englischer Sprache). Ejovi Nuwere und Mikko Varpiola haben ebenfalls eine interessante Präsentation über Fuzzing für das Netzwerkprotokoll VoIP vorgelegt, die Sie unter The Art of SIP Fuzzing and Vulnerabilities Found in VoIP (in englischer Sprache) nachlesen können.

Security Push

Bei einem Security Push konzentriert sich ein Team vollständig auf das Aktualisieren von Bedrohungsmodellen, Überprüfen von Code, Durchführen von Tests und Dokumentations-Scrubbing. Beachten Sie, dass ein Security Push keine schnelle Korrektur für einen Prozess darstellt, bei dem die Sicherheit nachlässig behandelt wurde. Es handelt sich vielmehr um eine gemeinsame Anstrengung, die Gültigkeit der Dokumentation zur Sicherheitsarchitektur zu bestätigen, nach Änderungen während des Entwicklungsprozesses zu suchen und gegebenenfalls verbleibende Sicherheits-Schwachstellen zu ermitteln und zu beheben. Es ist nicht möglich, Software-Sicherheit nur mithilfe eines Security Pushs zu gewährleisten.

Es gibt keinen einfachen Weg, den Zeitaufwand für einen Security Push zu ermitteln. Dieser Aufwand hängt letzten Endes von der Menge an Code ab, der auf seine Sicherheit hin überprüft werden muss, da alle Security Pushs bisher durch die Codemenge begrenzt wurden. Teams wird dringend empfohlen, während des gesamten Entwicklungsprozesses Sicherheits-Codeüberprüfungen durchzuführen, sobald der Code einigermaßen stabil ist, da die Qualität von Codeüberprüfungen verringert wird, wenn in einem gegebenen Zeitraum zu viele solcher Überprüfungen durchgeführt werden.

Als Faustregel gilt, dass kritischer Code mithilfe von Heuristiken wie Freigabe im Internet, Behandlung vertraulicher oder personenbezogener Informationen usw. ermittelt wird. Dieser Code wird dann mit der höchsten Priorität gekennzeichnet. Der Code muss während des Security Pushs überprüft werden, und der Security Push darf ohne diese Codeüberprüfung nicht abgeschlossen werden. Weisen Sie jeder Codedatei einen Namen zu, dem Code vor dem Security Push hingegen Namen und Priorität.

Abschließende Sicherheitsüberprüfungen

Wenn die Fertigstellung des Projekts bevorsteht, ist eine entscheidende Frage zu klären: "Ist die Sicherheit der Software gewährleistet, so dass diese an Kunden ausgeliefert werden kann?" Die abschließende Sicherheitsüberprüfung (Final Security Review, FSR), die vom zentralen Sicherheitsteam mit Unterstützung des Produktteams durchgeführt wird, beantwortet diese Frage. Gewöhnlich nimmt sie einige Monate in Anspruch, bevor die Software fertig gestellt ist. Zu den hiermit verbundenen Aufgaben zählen:

  • Das Ausfüllen eines Fragebogens, der das Sicherheitsteam beim Bündeln seiner Anstrengungen unterstützt. Zu diesen Fragen könnten beispielsweise die folgenden gehören:

  • Sind ActiveX-Steuerelemente vorhanden, die für die Skripterstellung als sicher gekennzeichnet sind?

Stellen Sie eine Liste aller Protokolle zusammen, für die Sie ein Fuzzing durchgeführt haben.

  • Akzeptiert die Komponente nicht authentifizierte Verbindungen?

  • Verwendet die Komponente UDP?

  • Verwendet die Komponente eine ISAPI-Anwendung oder ein ISAPI-Filter?

  • Wird ein Teil des Codes im Systemkontext ausgeführt? Wenn ja, warum?

  • Werden im Setupcode ACLs festgelegt?

  • Überprüfen Sie Fehler, die anscheinend nicht behoben werden können, und stellen Sie sicher, dass es sich nicht um falsch gekennzeichnete Sicherheitsmängel handelt.

  • Analysieren Sie Sicherheitsmängel anderer Versionen des Produkts sowie von Konkurrenzprodukten, um sicherzustellen, dass alle diese Probleme behandelt wurden. Eine häufig gestellt Frage lautet: "Wie wurde die Bedrohung durch diese große Kategorie von Sicherheitsproblemen gemindert?"

  • Führen Sie für besonders gefährdete Komponenten Belastungstests durch, möglicherweise durch ein Fremdunternehmen.

Die Sicherheitsantwort

Dieser Prozess besteht aus zwei wesentlichen Aufgaben. Zum einen die Behandlung vorhandener Sicherheitsmängel und die Arbeit mit Personen, die Sicherheitsprobleme im Code entdecken. Die andere Aufgabe besteht darin, aus diesen Fehlern zu lernen. Microsoft hat engagierte Mitarbeiter, deren Arbeit darin besteht, Mängelursachen-Analysen durchzuführen. Mit diesen Dokumenten wird dann über das weitere Vorgehen bei SDL entschieden. Jedes Dokument nach Abschluss enthält:

  • Name und Version der Datei

  • Handelt es sich um ein Entwurfsproblem?

  • Handelt es sich um ein Codeproblem?

  • Quelltextvergleich bei einem Codefehler

  • Hat der Fehler Auswirkungen auf andere Versionen des Produkts? Wenn ja, warum? Wenn nein, warum nicht? (Beide Fragen sind durchaus sinnvoll.)

  • Mit welchen Tests hätte dieser Mangel erkannt werden können?

  • Mit welchen Tools hätte dieser Mangel erkannt werden können?

  • Müssen Schulungen, Tools oder Prozesse geändert werden, um diese Probleme zu erkennen?

Mithilfe dieser Antworten wird anschließend der Sicherheitsentwicklungszyklus überarbeitet. Bei Microsoft wird der SDL zweimal im Jahr aktualisiert, am 1. Januar und am 1. Juli.

Funktioniert SDL?

Die große Frage lautet also: "Funktioniert SDL? Führt der Einsatz von SDL-Methoden zur Entwicklung von sichererer Software?" Die Antwort darauf ist ganz eindeutig: "Ja!" Die Anzahl von Sicherheitsmängeln konnte mit SDL um ungefähr 50 bis 60 % verringert werden. Es ist ganz einfach eine Tatsache, dass jedes Produkt, das mit SDL in Berührung gekommen ist, weniger Sicherheitsmängel aufweist. Punkt. Und das ist sicher ein Argument, auch weiterhin SDL zu verwenden.

Der Autor

Michael Howard ist Senior Security Program Manager bei Microsoft, spezialisiert auf die Verbesserung von sicheren Prozessen und auf optimale Methoden ("Best Practice"). Er ist Mitautor von 19 Deadly Sins of Software Security (McGraw-Hill Osborne, 2005) und Processes to Produce Secure Software (Dept. of Homeland Security National Cyber Security Division).

Aus der Ausgabe November 2005 des MSDN Magazine.