Skip to main content

Trainings und Tools zum SDL (Phase 1 bis 3)

Microsoft hat eine Reihe von Trainingsmaterialien und Tools veröffentlicht, die Sie in den verschiedenen Phasen des Software Development Lifecycle (SDL) bei der Arbeit unterstützen.

1. Phase: Training

Für die Trainingsphase gibt es naturgemäß keine Tools, aber Microsoft hat verschiedene Informationen für die weiteren Phasen bereitgestellt. Das "Security Development Lifecycle Developer Starter Kit" enthält Trainingsmaterialien für die Phasen Design, Implementation und Verification.

Einen Überblick zum SDL finden Sie in ebenfalls in dieser Artikelserie oder in dieser Präsentation "Introduction to the Microsoft Security Development Lifecycle (SDL)". Informationen über alle Phasen des SDL enthält das Whitepaper "Simplified Implementation of the Microsoft SDL", während speziell die Trainingsphase im Whitepaper "Essential Software Security Training for the Microsoft SDL" behandelt wird.

2. Phase: Requirements

Für die Anforderungsphase stellt Microsoft als Einführung in das Thema "Datenschutz" die Präsentation "Privacy in Software Development" zur Verfügung.

  • Für den ersten Schritt, "Establish Security and Privacy Requirements", gibt es zusätzliche Informationen im Anhang der SDL Process Guidance: "Security Definitions for Vulnerability Work Item Tracking".
  • Dort finden Sie auch Beispiele für den zweiten Schritt, "Define Quality Gates/Bug Bars", und zwar für eine Privacy Bug Bar und eine Security Bug Bar. Wie man diese in den Microsoft Team Foundation Server 2010 integriert, beschreibt ein Security Brief aus dem MSDN Magazine.
  • Auch für den dritten Schritt, "Perform Security and Privacy Risk Assessment", gibt es weiterführende Hinweise: Das "SDL Privacy Questionnaire" im Anhang der SDL Process Guidance ist quasi eine Checkliste zum Abfragen aller für den Datenschutz relevanten Punkte. Der "SDL Optimization Model Self-Assessment Guide" wartet ebenfalls mit einer Checklisten-Funktion auf. Wenn Sie sich nicht sicher sind, ob Sie alle möglichen Punkte bedacht haben, sind diese Listen sehr hilfreich.

Als Tools für alle drei Schritte der Anforderungsphase stehen Process Templates für Visual Studio Team System (VSTS) und Team Foundation Server (TFS) sowohl für konventionelle als auch agile Entwicklung zur Verfügung.

3. Phase: Design

Einführungen in die Designphase liefern die Präsentationen "Basics of Secure Design, Development and Test" und "Introduction to Microsoft SDL Threat Modeling". Die "SDL Quick Security References" enthalten Informationen zu den für Entwickler von Desktop-Anwendungen nur am Rande interessanten Themen Cross-Site Scripting und SQL Injection sowie zur auch für Desktop-Anwendungen relevanten Preisgabe sensitiver Informationen. Das "SDL Developer Starter Kit" enthält Trainingsmaterial zu den Themen Secure Design Principles, Threat Modeling Principles und Threat Modeling Tool Principles sowie SQL-Injection- und Cross-Site-Scripting-Schwachstellen (die hauptsächlich für Webentwickler interessant sind) und die auch und gerade für Desktop-Anwendungen gefährlichen Buffer Overflow-Fehler.

3.1 Design-Anforderungen

Speziell für den ersten Schritt der Design-Phase, "Establish Design Requirements", gibt es weiteres Material: Die " Privacy Guidelines for Developing Software Products and Services" geben Hinweise, was im Hinblick auf den Datenschutz alles beachtet werden muss. Mit einer einfachen Faustregel decken Sie i.A. einen großen Teil dieser Anforderungen ab: Speichern Sie so wenig vertrauliche Daten wie möglich und sichern Sie die gespeicherten Daten so gut wie möglich vor unbefugten Zugriffen, oder kurz: "So wenig Daten wie möglich, so sicher wie möglich".

Ein Anhang in der SDL Process Guidance befasst sich mit "Firewall Rules and Requirements", was Sie als Entwickler von Desktop-Anwendungen nur am Rande betrifft, hier sind i.A. die Administratoren gefordert: Die Netzwerkadministratoren fangen einen Großteil der Angriffe bereits mit der Firewall und weiteren Schutzsystemen zwischen lokalem Netz und Internet ab, die lokalen Administratoren sichern die einzelnen Rechner vor Angriffen aus dem lokalen Netz sowie denen, die die vorgeschaltete Firewall überwunden haben. Aber das braucht Sie im Grunde nicht weiter zu kümmern, denn wenn Ihr Programm sicher ist, ist jeder Angriff darauf bzw. darüber zwecklos, ganz egal, woher er kommt.

Ein Security Brief befasst sich mit "Cryptographic Agility", der Frage, wie agile Entwicklung Kryptographie nutzen kann. Und ein weiterer Artikel hat "Documenting and Evaluating the Security Guarantees of Your Apps" zum Thema. Vereinfacht geht es um die Frage, ob die eingesetzten Schutzmaßnahmen überhaupt ihr Ziel erreichen und die Software sicherer machen. Bei allen Schutzmaßnahmen besteht die Gefahr, dass sie falsch implementiert oder angewendet werden.

3.2 Ermitteln und Minimieren der Angriffsfläche

Auch für den zweiten Schritt der Designphase, "Attack Surface Analysis/Reduction", gibt es spezielles Trainingsmaterial. Ein Artikel befasst sich mit der Abwehr zukünftiger Angriffe durch die Reduzierung der Angriffsfläche (vereinfacht ausgedrückt: Was nicht da bzw. nicht erreichbar ist, kann auch nicht angegriffen werden). Ein weiterer Artikel beschreibt, wie die Angriffsfläche durch Minimierung des nicht vertrauenswürdigen Benutzern zugänglichen Codes minimiert wird. Als Entwickler von Desktop-Anwendungen betrifft sie das meist nur indirekt, und zwar wenn die Benutzer mit Ihrem Programm Dateien aus mehr oder weniger zweifelhaften Quellen öffnen. Enthält Ihr Programm eine Schwachstelle, kann die durch so eine Datei ausgenutzt werden. Außer der besten Lösung, gar keine Schwachstelle im Programm zu haben, hilft hier nur das standardmäßige Ausschalten wenig genutzter Funktionen zur Minimierung der Angriffsfläche. Was aber gar nichts nutzt, wenn die Schwachstelle sich z.B. im Code zum Interpretieren der geöffneten Datei befindet, denn diese Funktion muss das Programm ja immer bereitstellen.

3.3 Bedrohungsmodellierung

Im dritten Schritt geht es ums "Threat Modeling", die Bedrohungsmodellierung. Auch hierzu gibt es eine Reihe von Trainingsmaterial: Ein Artikel beschreibt die Suche nach Designfehlern mit dem STRIDE-Ansatz, ein weiterer Artikel liefert einen Überblick über die Bedrohungsmodellierung an Hand eines fiktiven Gesprächs. Ein Security Brief schließlich erklärt, wie die Bedrohungsmodellierung den Sicherheitsprozess verbessert. Zur Unterstützung der Bedrohungsmodellierung stellt Microsoft das Threat Modeling Tool als Erweiterung für Visio zur Verfügung. Eine Einführung in seine Nutzung liefert ein Security Brief im MSDN Magazine.

Ein Tool der etwas anderen Art ist das Elevation of Privilege (EoP) Card Game, dass wohl eher in die Kategorie "Training" fällt: Ein Kartenspiel für 3 bis 6 Mitspieler zur spielerischen Erkundung von Privilegien-Eskalationen.

In der zweiten Folge gibt es Informationen zu Trainingsmaterialien und Tools für die restlichen Phasen des SDL: "Implementation", "Verification" und "Release". Für die letzte Phase, "Response", gibt es keine speziellen Tools.


 

Autor des Artikels

Dipl.-Inform. Carsten Eilers ( www.ceilers-it.de) ist als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz tätig und als Autor verschiedener Artikel und des Buches "Ajax Security" bekannt.  Seinen Blog finden Sie hier.

 



These postings are provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use. The content of these security articles are the own personal opinions from Carsten Eilers.

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?