Security Briefs

Die MSF-Agile+SDL-Prozessvorlage für TFS 2010

Bryan Sullivan

Alle, die dieses Magazin regelmäßig lesen, kennen Microsoft Team Foundation Server (TFS) und die Produktivitätsvorteile, die er Entwicklungsteams bietet. (Wenn Sie TFS nicht kennen, können Sie sich im Artikel von Chris Menegay in unserer Visual Studio 2005 Guided Tour informieren. Dort wird zwar eine ältere Version behandelt, Sie erhalten aber dennoch eine hilfreiche Übersicht über die Funktionen, die Sie in TFS nutzen können.)

Wenn Sie TFS selbst nutzen, kennen Sie wahrscheinlich auch die Microsoft Solutions Framework (MSF) for Agile Software Development-Prozessvorlage – besser bekannt als MSF-Agile –, die mit TFS ausgeliefert wird. Im Artikel dieses Monats wird die neue MSF-Agile+Security Development Lifecycle (SDL)-Prozessvorlage vorgestellt. MSF-Agile+SDL baut auf der MSF-Agile-Vorlage auf und fügt dem Entwicklungsprozess SDL-Sicherheits- und -Datenschutzfunktionen hinzu.

Sie können die MSF-Agile+SDL-Vorlage für Visual Studio Team System 2008 oder 2010 über microsoft.com/sdl herunterladen. Vor dem Herunterladen möchten Sie jedoch vielleicht wissen, zu welchem Zweck sie erstellt wurde. Fangen wir also an.

SDL-Aufgaben

Das Herzstück des SDL sind die Sicherheitsanforderungen und -empfehlungen – Aktivitäten, die Entwicklungsteams während des gesamten Entwicklungslebenszyklus ausführen müssen, um einen besseren Sicherheitsstandard und einen besseren Datenschutz im endgültigen Produkt zu implementieren. Zu diesen Anforderungen zählen Maßnahmen in Bezug auf Richtlinien wie Erstellen eines Reaktionsplans für Sicherheitsverletzungen sowie technische Maßnahmen wie die Bedrohungsmodellierung und die Analyse von statischen Sicherheitsschwachstellen. Alle diese Maßnahmen werden in der MSF-Agile+SDL-Vorlage in Form von SDL-Arbeitsaufgaben wiedergegeben.

Der vielleicht größte Unterschied zwischen SDL-Aufgaben und den standardmäßigen Arbeitsaufgaben, bei denen es sich um funktionale Aufgaben handelt, besteht darin, dass die Projektteammitglieder nicht selbst die SDL-Aufgaben erstellen. Einige SDL-Aufgaben werden zusammen mit der Projektteamerstellung automatisch erstellt. Dabei handelt es sich um relativ einfache, einmalige Sicherheitsaufgaben, wie das z. B. Benennen eines Teammitglieds, das als primärer Ansprechpartner für Sicherheitsfragen fungieren soll. Andere SDL-Aufgaben werden von der Prozessvorlage als Reaktion auf Benutzeraktionen erstellt. (Genauer gesagt werden sie automatisch vom SDL-Agile-Controllerwebservice erstellt, der in der TFS-Anwendungsebene bereitgestellt wird.)

Immer, wenn ein Benutzer dem Projekt eine neue Iteration hinzufügt, fügt die Vorlage dem Projekt neue SDL-Aufgaben hinzu, die die Sicherheitsaufgaben für diese Iteration umfassen. Ein gutes Beispiel für eine iterationsbasierte SDL-Aufgabe ist die Bedrohungsmodellierung: Das Team muss die Änderungen an der Iteration bewerten, um potentielle neue Bedrohungen und Korrekturmaßnahmen zu identifizieren.

Wenn ein Benutzer schließlich ein neues Visual Studio-Projekt oder eine neue Website in das Team Source Control-Repository eincheckt, werden SDL-Aufgaben von der Vorlage hinzugefügt, in denen die Sicherheitsaufgaben für speziell dieses Projekt festgelegt sind. Immer, wenn z. B. ein neues C- oder C++-Projekt hinzugefügt wird, werden SDL-Aufgaben erstellt, um die Verwendung der richtigen Einstellungen für den Pufferüberlauf-Verteidigungscompiler und -linker sicherzustellen, wie z. B. das Kennzeichen /dynamic­base für die zufällige Anordnung des Adressraumlayouts (Address Space Layout Randomization, ASLR) und das Kennzeichen /gs für die Puffersicherheitsüberprüfung.

Die Vorlage erkennt selbstständig den Unterschied zwischen nativen C/C++-Projekten und Microsoft .NET Framework-Projekten und fügt keine ungültigen Anforderungen hinzu. Die Kennzeichen /dynamicbase und /gs flags sind im C#-Code bedeutungslos, sodass das solche SDL-Aufgaben nicht für C#-Projekte erstellt werden. Stattdessen werden C#-Projekten .NET-spezifische Sicherheitsaufgaben zugeordnet, wie z. B. das Prüfen der Verwendung von AllowPartiallyTrustedCallersAttribute. Ebenso kann die Vorlage zwischen Client-/Serveranwendungen und eigenständigen Desktopanwendungen auf der einen und Websites und Webdiensten auf der anderen Seite unterscheiden und fügt nur die passenden SDL-Aufgaben hinzu.

SDL-Aufgaben und -Ausnahmen

Die Status- und Grund-Workflowübergänge für SDL-Aufgaben unterscheiden sich auch von denen funktionaler Aufgaben. Eine Aufgabe kann aus verschiedenen Gründen als geschlossen markiert werden: sie ist abgeschlossen, wurde aus dem Projekt ausgeschlossen, an eine spätere Iteration verwiesen oder ist sogar obsolet und nicht mehr für das Projekt relevant. Für SDL-Aufgaben gilt nur der Grund „Abgeschlossen“.

Teams, die sich an den SDL halten, können nicht einfach Sicherheits- und Datenschutzanforderungen bei ihren Projekten ignorieren. Funktionale Anforderungen können aus technischen oder geschäftlichen Gründen je nach Bedarf einbezogen oder ausgeschlossen werden, aber Sicherheitsanforderungen müssen einem höheren Standard entsprechen. Es ist nicht möglich, eine SDL-Aufgabe zu überspringen, sondern es muss auf einer höheren Prozessebene angesetzt werden, wenn dies erreicht werden soll.

Wenn ein Team, aus welchen Gründen auch immer, eine erforderliche SDL-Aufgabe nicht abschließen kann, muss sie den zuständigen Sicherheitsbeauftragten um die Erteilung einer Ausnahme für diese Aufgabe bitten. Der Sicherheitsbeauftragte eines Teams wird vom Team oder seinem Management beim Projektstart ausgewählt. Diese Person sollte über Erfahrungen in der Anwendungssicherheit und im Bereich Datenschutz verfügen und idealerweise nicht direkt am Projekt mitarbeiten – es sollte sich nicht um einen der Projektentwickler, Programmmanager oder Tester handeln.

Bei Microsoft gibt es eine zentrale Gruppe von Sicherheitsbeauftragten, die der Abteilung Trustworthy Computing Security angehören. Diese Sicherheitsbeauftragten arbeiten direkt mit den einzelnen Produktteams zusammen. Wenn Ihr Unternehmen über Ressourcen verfügt, um selbst eine Gruppe von spezialisierten Sicherheitsbeauftragten zusammenzustellen, ist dies optimal. Ist dies nicht der Fall, sollte die Person mit der besten Erfahrung in Sachen Sicherheit ausgewählt werden.

Der Sicherheitsbeauftragte entscheidet, welche Ausnahmeanforderungen für eine SDL-Aufgabe akzeptiert und welche abgelehnt werden. Das Team erstellt eine Ausnahmeanforderung durch Festlegen des SDL-Aufgabenstatus auf „Exception Requested“ (Ausnahme angefordert) und durch Ausfüllen der Felder „Justification“ (Begründung), „Resolution Plan“ (Lösungsplan) und „Resolution Timeframe“ (Lösungszeitrahmen). Jede SDL-Aufgabe verfügt außerdem über das schreibgeschützte Feld „Exception Rating“ (Ausnahmeeinstufung), das das subjektive Sicherheitsrisiko bei einem Nichterfüllen dieser SDL-Anforderung wiedergibt. Der Wert kann dabei von 4 (kleinstes Risiko) bis 1 (kritisch; größtes Risiko) reichen. Der Sicherheitsbeauftragte wägt zwischen den Argumenten des Teams und der Ausnahmeeinstufung ab und schließt die SDL-Aufgabe entweder mit „Reason of Approved“ (Grund für Genehmigung) oder aktiviert sie mit „Reason of Denied“ (Grund für Ablehnung) erneut.

Auch wenn die Ausnahmeanforderung akzeptiert wird, ist dies aber keine Entscheidung für immer. Hier kommt das Feld „Resolution Timeframe“ (Lösungszeitrahmen) ins Spiel. Teams fordern in der Regel Ausnahmen für eine festgelegte Anzahl an Iterationen an – in der Regel nur eine Iteration, aber manchmal bis zu drei. Nachdem die angegebene Anzahl an Iterationen ausgeführt wurde, läuft die Ausnahme in der Prozessvorlage ab, und die SDL-Aufgabe wird erneut aktiviert.

Sicherheitsmängel

Nachdem sichergestellt wurde, dass alle Anforderungen zur Sicherheit und zum Datenschutz erfüllt wurden, besteht die nächste wichtige Funktion des SDL darin, zu gewährleisten, dass die Produkte nicht mit bekannten Sicherheitsmängeln ausgeliefert werden. Das separate Nachverfolgen von Sicherheitsmängeln und funktionalen Mängeln ist für die Sicherheitsintegrität Ihrer Produkte von größter Bedeutung.

Im Gegensatz zu SDL-Aufgaben wird bei der MSF-Agile+SDL-Vorlage keine zweite SDL-Fehler/Mangel-Arbeitsaufgabe hinzugefügt, um zwischen Sicherheitsmängeln und funktionalen Mängeln zu unterscheiden. Dagegen werden dem bereits bestehenden Fehler/Mangel-Arbeitsaufgabentyp die Felder „Security Cause“ (Ursache) und „Security Effect“ (Auswirkung) hinzugefügt. Immer, wenn ein Teammitglied einen neuen Mangel eingibt, kann es die Werte dieser Felder auf dem Standardwert „Not a Security Bug“ (Kein Sicherheitsmangel) belassen, sofern der Mangel ein rein funktionaler Mangel ohne Sicherheitsaspekte ist. Wenn der Mangel jedoch eine potentielle Sicherheitsgefahr beinhaltet, muss der Berichtende unter „Security Cause“ (Ursache) einen der folgenden Werte auswählen:

• Arithmetic error (Arithmetischer Fehler)
• Buffer overflow/underflow (Pufferüberlauf/-unterlauf)
• Cross-Site Scripting (Siteübergreifende Skripte)
• Cryptographic weakness (Kryptografische Mängel)
• Directory traversal
• Incorrect/no error messages (Falsche/keine Fehlermeldungen)
• Incorrect/no pathname canonicalization (Falsche/keine Pfadnamenkanonisierung)
• Ineffective secret hiding (Uneffektives Verbergen geheimer Zeichen)
• Race condition (Racebedingung)
• SQL/script injection (SQL/Skripteinschleusung)
• Unlimited resource consumption (denial of service) (Unbegrenzte Ressourcenauslastung, Denial-of-Service)
• Weak authentication (Schwache Authentifizierung)
• Weak authorization/inappropriate permission or ACL (Schwache Authentifizierung/ungenügende Berechtigungen oder ACL)
• Other (Sonstiges)

Der Berichtende legt auch eine Auswirkung in Form eines STRIDE-Werts fest:

• Spoofing
• Tampering (Manipulieren)
• Repudiation (Nichtanerkennung)
• Information Disclosure (Offenlegung von Informationen)
• Denial-of-Service
• Elevation of Privilege (Rechteerweiterungen)

Der Berichtende kann darüber hinaus auch den Umfang (Scope) des Mangels angeben. Damit sind zusätzliche subjektive Informationen zum Mangel gemeint, die bei der Einordnung in einen Schweregrad helfen. Welche Werte unter „Scope“ (Umfang) zur Verfügung stehen, hängt vom ausgewählten Wert unter „Security Effect“ (Auswirkung) ab. Wenn Sie z. B. unter „Security Effect“ (Auswirkung) den Eintrag „Elevation of Privilege“ (Rechteerweiterungen) wählen, lauten die möglichen Werte für „Scope“ (Umfang):

• (Client) Remote user has the ability to execute arbitrary code or obtain more privilege than intended. ((Client) Der Remotebenutzer kann willkürlichen Code ausführen oder mehr Berechtigungen erhalten als beabsichtigt.)
• (Client) Remote user has the ability to execute arbitrary code with extensive user action. ((Client) Der Remotebenutzer kann willkürlichen Code mit umfassenden Benutzeraktionen ausführen.)
• (Client) Local low-privilege user can elevate himself to another user, administrator or local system. ((Client) Ein lokaler Benutzer mit geringfügigen Berechtigungen kann sich erweiterte Berechtigungen eines anderen Benutzers, Administrators oder lokalen Systems zuweisen.)
• (Server) Remote anonymous user has the ability to execute arbitrary code or obtain more privilege than intended. ((Server) Ein anonymer Remotebenutzer kann willkürlichen Code ausführen oder mehr Berechtigungen erhalten als beabsichtigt.)
• (Server) Remote authenticated user has the ability to execute arbitrary code or obtain more privilege than intended. ((Server) Ein authentifizierter Remotebenutzer kann willkürlichen Code ausführen oder mehr Berechtigungen erhalten als beabsichtigt.)
• (Server) Local authenticated user has the ability to execute arbitrary code or obtain more privilege than intended. ((Server) Ein lokaler authentifizierter Benutzer kann willkürlichen Code ausführen oder mehr Berechtigungen erhalten als beabsichtigt.)

Sie sehen, dass es bei den Schweregradeinstufungen für Mängel der Kategorie „Elevation of Privilege“ (Rechteerweiterungen) – also die Merkmale, durch die eine Rechteerweiterung als gravierend eingestuft wird – um bestimmte Bedingungen geht, wie z. B. den Ort des Angriffs (Client oder Server) und die Authentifizierungsebene des Angreifers (anonym oder authentifiziert). Wenn Sie jedoch eine andere Auswirkung wählen, wie Denial-of-Service, ändern sich die Auswahlmöglichkeiten unter „Scope“ (Umfang) so, dass sie den Schweregrad für diese Auswirkung widerspiegeln:

• (Client) Denial of service that requires reinstallation of system and/or components ((Client) Denial-of-Service, der die Neuinstallation des Systems und/oder von Komponenten erfordert)
• (Client) Denial of service that requires reboot or causes blue screen/bug check ((Client) Denial-of-Service, der einen Neustart erfordert oder einen blauen Bildschirm/eine Mängelprüfung verursacht)
• (Client) Denial of service that requires restart of application ((Client) Denial-of-Service, der einen Neustart der Anwendung erfordert)
• (Server) Denial of service by anonymous user with small amount of data ((Server) Denial-of-service durch anonymen Benutzer mit geringen Datenmengen
• (Server) Denial of service by anonymous user without amplification in default/common install ((Server) Denial-of-service durch anonymen Benutzer ohne Erweiterung der standardmäßigen/üblichen Installation)
• (Server) Denial of service by authenticated user that requires system reboot or reinstallation ((Server) Denial-of-Service durch authentifizierten Benutzer, der einen Neustart des Systems oder eine Neuinstallation erfordert)
• (Server) Denial of service by authenticated user in default/common install ((Server) Denial-of-service durch authentifizierten Benutzer in der standardmäßigen/üblichen Installation)

Nachdem die Werte für „Security Cause“ (Ursache), „Security Effect“ (Auswirkung) und „Scope“ (Umfang) eingegeben wurden, verwendet die Vorlage diese Daten zum Berechnen des Mindest-Schweregrads für den Mangel. Der Benutzer kann für den tatsächlichen Mangel einen höheren Schweregrad als den Mindest-Schweregrad einstellen – er kann den Mangel z. B. auf „1–Critical“ (1–Kritisch) statt „2–High“ (2–Hoch) festlegen –, aber niemals anders herum. Dies mag übervorsichtig klingen, verhindert aber Versuche, den Schweregrad von Mängeln herabzustufen, um Liefertermine oder kurzfristige Fristen einzuhalten.

Wenn Sie mehr über die Gründe für eine objektivere Mangeleinstufung erfahren möchten, lesen Sie den Security Briefs-Artikel von März 2010 „Hinzufügen einer Bewertungsmatrix für Sicherheitsmängel in Microsoft Team Foundation Server 2010“ (msdn.microsoft.com/magazine/ee336031). Der Prozess für das Hinzufügen einer Mangelbewertungsmatrix, den ich diesem Artikel beschrieben habe, wurde bereits in die MSF-Agile+SDL-Vorlage integriert.

Schließlich gibt es ein weiteres optionales Feld in der Fehler/Mangel-Arbeitsaufgabe. Über das Feld „Origin“ (Ursprung) können Sie den Namen des automatisierten Sicherheitstools angeben, das den Mangel zum ersten Mal gefunden hat, oder den Standardwert „User“(Benutzer) belassen, wenn der Benutzer den Mangel über eine manuelle Codeprüfung oder über Tests gefunden hat.

Im Laufe der Zeit werden Sie genug Daten gesammelt haben, um herauszufinden, welches Ihrer Testtools die beste Arbeit macht. Um diese Bewertung zu vereinfachen, umfasst die MSF-Agile+SDL-Vorlage einen Excel-Bericht namens „Bugs by Origin“ (Mängel nach Ursprung), der eine Liste der Sicherheitsmängel in Abhängigkeit des Felds „Origin“ (Ursprung) anzeigt.

Sie können diesen Bericht anpassen, um die Daten anhand von „Severity“ (Schweregrad), „Security Cause“ (Ursache) oder „Security Effect“ (Auswirkung) zu filtern. So können Sie leicht herausfinden, welche Tools sich am besten zum Auffinden von siteübergreifendem Skripting oder schwerwiegenden „Elevation of Privilege“-Mängeln usw. eignen.

Mängelworkflow

Genauso wenig, wie Sie SDL-Aufgaben ignorieren können, können Sie Mängel mit Sicherheitsrisiken (also Mängel, die unter „Security Effect“ (Auswirkung) einen anderen Status als „Not a Security Bug“ (Kein Sicherheitsmangel) aufweisen) ignorieren. Das Team muss eine Ausnahme anfordern, wenn Sicherheitsmängel mit einem Schweregrad von „3 – Moderate“ (3 – Mittel) oder höher nicht (sofort) behoben werden können.

Der Prozess hierfür ähnelt dem Prozess für die Ausnahmeanforderung bei SDL-Aufgaben: ein Teammitglied legt den Status auf „Exception Requested“ (Ausnahme angefordert) fest und macht Angaben in den Feldern „Justification“ (Begründung), „Resolution Plan“ (Lösungsplan) und „Resolution Timeframe“ (Lösungszeitrahmen). Der Sicherheitsbeauftragte des Teams schaut sich die Ausnahmeanforderung an und genehmigt diese (Status wird auf „Closed“ (Geschlossen) mit einer Angabe unter „Reason of Approved“ (Grund für Genehmigung) festgelegt) oder lehnt sie ab (Status wird auf „Active“ (Aktiv) mit einer Angabe unter „Reason of Denied“ (Grund für Ablehnung) festgelegt).

Sicherheitsbezogene Abfragen und das Sicherheits-Dashboard

Die MSF-Agile+SDL-Vorlage umfasst auch mehrere neue Teamabfragen, um das Befolgen des Prozesses zu vereinfachen. Diese neuen Abfragen werden im Ordner „Security Queries“ in Team Explorer angezeigt und lauten wie folgt:

• Active Security Bugs
• My Security Bugs
• Resolved Security Bugs
• Open SDL Tasks
• My SDL Tasks
• Open Exceptions (umfasst Aufgaben und Mängel und ist besonders hilfreich für Sicherheitsbeauftragte)
• Approved Exceptions
• Security Exit Criteria

Die meisten dieser Abfragen sind selbsterklärend, nur die Abfrage „Security Exit Criteria“ erfordert eine genauere Erklärung. Um die SDL-Vorgaben für eine bestimmte Iteration zu erfüllen, muss das Team alle folgenden Aktivitäten abgeschlossen haben:

• Alle Every-Sprint- und sich wiederholenden SDL-Aufgaben für diese Iteration müssen abgeschlossen sein oder eine vom Sicherheitsbeauftragten genehmigte Ausnahme aufweisen.
• Es dürfen keine abgelaufenen oder SDL-Bucket-Aufgabenanforderungen vorliegen.
• Alle Mängel mit Sicherheitsrisiken vom Schweregrad „3 – Moderate“ (3 – Mittel) oder höher müssen geschlossen sein oder eine vom Sicherheitsbeauftragten des Teams genehmigte Ausnahme aufweisen.

Die Begriffe „Every-Sprint“, „One-Time“ und „Bucket“ beziehen sich in diesem Kontext auf das SDL-Agile-Konzept, mit dem Anforderungen abhängig von ihrer Anforderungshäufigkeit organisiert werden (d. h., mit welcher Häufigkeit sie fertig gestellt werden müssen). Every-Sprint-Anforderungen sind wiederkehrende Anforderungen und müssen in jeder Iteration erfüllt werden. One-Time-Anforderungen sind nicht wiederkehrend und müssen nur ein Mal erfüllt werden. Bucket-Anforderungen sind wiederkehrende Anforderungen, die aber nur ein Mal alle sechs Monate erfüllt werden müssen.

Eine ausführliche Beschreibung dieses Klassifizierungssystems sprengt den Rahmen dieses Artikels, aber wenn Sie mehr über dieses System wissen möchten, finden Sie in dem MSDN Magazine-Artikel „Agiler SDL: Optimieren der Sicherheitsmethoden für agile Entwicklung“ aus der Ausgabe von November 2008 die entsprechenden Informationen.

Der Zweck der Abfrage „Security Exit Criteria“ besteht darin, Teammitgliedern eine einfache Möglichkeit zu bieten, mit der sie prüfen können, wie viele Punkte sie im Rahmen von SDL noch abarbeiten müssen. Wenn Sie eine SharePoint-Site für das MSF-Agile+SDL-Teamprojekt bei der Erstellung konfigurieren (wird normalerweise automatisch vorgenommen), werden auch die Ergebnisse der Abfrage „Security Exit Criteria“ im Sicherheits-Dashboard des Teamprojekts angezeigt.

Das neue Sicherheits-Dashboard ist nur für MSF-Agile+SDL-Projekte verfügbar (siehe Abbildung 1). Standardmäßig umfasst es die Abfragen „Security Exit Criteria“, „Open SDL Tasks“, „Open Exceptions“ und „Security Bugs“, aber diese können bei Bedarf angepasst werden. Das Sicherheits-Dashboard ist auch als Standard-Projektportalseite für alle MSF-Agile+SDL-Projekte festgelegt. Wenn Sie ein anderes Standard-Dashboard verwenden möchten, können Sie einfach die Dashboard-Dokumentbibliothek öffnen, das zu verwendende Dashboard und dann die Option „Set as Default Page“ wählen.

Abbildung 1 Sicherheits-Dashboard von MSF-Agile+SDL

Standardmäßig umfasst es die Abfragen „Security Exit Criteria“, „Open SDL Tasks“, „Open Exceptions“ und „Security Bugs“, aber diese können bei Bedarf angepasst werden. Das Sicherheits-Dashboard ist auch als Standard-Projektportalseite für alle MSF-Agile+SDL-Projekte festgelegt. Wenn Sie ein anderes Standard-Dashboard verwenden möchten, können Sie einfach die Dashboard-Dokumentbibliothek öffnen, das zu verwendende Dashboard und dann die Option „Set as Default Page“ wählen.

Eincheckrichtlinien

Die letzte Funktion der MSF-Agile+SDL-Prozessvorlage ist eine Gruppe von SDL-Eincheckrichtlinien. Diese Richtlinien helfen dabei, Entwickler am Einchecken von Code zu hindern, der gegen bestimmte SDL-Anforderungen verstößt und daher zu Sicherheitsverletzungen führen kann. Die verfügbaren SDL-Eincheckrichtlinien werden in Abbildung 2 gezeigt.

Abbildung 2 Eincheckrichtlinien von MSF-Agile+SDL

SDL-Eincheckrichtlinie	Beschreibung
SDL Banned APIs	Stellt sicher, dass die Compileroption zum Behandeln der Warning C4996 (Verwenden einer veralteten Funktion) als Fehler eingestuft wird. Da die meisten Laufzeitbibliotheks-Funktionen, die potentiell zu Pufferüberläufen führen können (z. B. strcpy, strncpy und gets), zugunsten sicherer Alternativen (strcpy_s, strncpy_s bzw. gets_s) aufgegeben wurden, kann diese Eincheckrichtlinie die Widerstandsfähigkeit der Anwendung gegenüber Pufferüberlaufangriffen erheblich verbessern.
SDL Buffer Security Check	Stellt sicher, dass die Compileroption für die Aktivierung der Puffersicherheitsüberprüfung (/GS) aktiviert ist. Mit dieser Option wird der Stack des kompilierten Programms neu organisiert, um einen Sicherheitscookie oder Canary-Wert zu integrieren, der die Schwierigkeit für einen Angreifer erhöht, einen verlässlichen Exploit für die Stapelüberlauf-Schwachstelle zu schreiben.
SDL DEP and ASLR	Stellt sicher, dass die Linkeroptionen „Datenausführungsverhinderung“ (/NXCOMPAT) und „Zufällige Basisadresse“ (/DYNAMICBASE) aktiviert sind. Mit diesen Optionen wird die Adresse, an der die Anwendung in den Speicher geladen wird, zufällig festgelegt, wodurch kein Code im Speicher ausgeführt wird, der eigentlich Daten zugewiesen werden soll. Vor allem in Kombination bieten diese beiden Optionen starke, tiefgreifende Maßnahmen gegen Pufferüberlaufangriffe.
SDL Safe Exception Handlers	Stellt sicher, dass die Linkeroption /SAFESEH aktiviert ist. Mit dieser Option wird verhindert, dass Angreifer böswillige Ausnahmehandler definieren, die zu einer Störung des Systems führen können. Mit /SAFESEH wird eine Tabelle der legitimen Ausnahmehandler zur Verbindungszeit erstellt. Die Ausführung anderer Ausnahmehandler wird nicht zugelassen.
SDL Uninitialized Variables	Stellt sicher, dass die Compilerwarnebene auf Ebene 4 (/W4), die strengste Ebene, festgelegt ist. Mit dieser Option wird Code markiert, bei dem Variablen möglicherweise ohne Initialisierung verwendet werden, was zu möglichen Exploits führen kann.

Das Aktivieren einer oder aller SDL-Eincheckrichtlinien ist ganz einfach. Klicken Sie in Team Explorer mit der rechten Maustaste auf ein Teamprojekt, und wählen Sie die Option „Quellcodeverwaltung“ aus dem Kontextmenü. Wählen Sie die Registerkarte „Eincheckrichtlinie“, und fügen Sie die SDL-Richtlinien hinzu, die Sie erzwingen möchten (siehe Abbildung 3). Es ist dabei wichtig zu bedenken, dass die Erzwingung der Eincheckrichtlinie auf dem Clientcomputer durchgeführt wird, und nicht auf dem TFS-Server, sodass Sie die SDL-Eincheckrichtlinien auf dem Computer jedes Entwicklers installieren müssen.

Abbildung 3 Hinzufügen von Eincheckrichtlinien

Zusammenfassung

Jede sichere und effektive Entwicklungsmethodologie muss leicht zu automatisieren und leicht zu verwalten sein. Die MSF-Agile+SDL-Prozessvorlage hilft erheblich dabei, diese Anforderungen zu erfüllen. Wenn Sie bereits die MSF-Agile-Prozessvorlage verwenden, die mit TFS ausgeliefert wird, kennen Sie sich quasi bereits mit der Verwendung der MSF-Agile+SDL-Vorlage aus – sie bildet eine strikte Obermenge der MSF-Agile-Vorlage. Laden Sie sie von microsoft.com/sdl herunter, und erstellen Sie ab heute Produkte, die noch mehr Sicherheit und Datenschutz bieten.

Bryan Sullivan ist Sicherheitsprogramm-Manager beim Microsoft Security Development Lifecycle-Team und hat sich auf Webanwendungen und .NET-Sicherheitsaspekte spezialisiert. Er ist auch der Autor von „Ajax Security“ (Addison-Wesley, 2007).

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Michael Howard