Skip to main content

Security Development Lifecycle

Sicherheit kann man nicht nachträglich über das fertige Programm überstülpen, sie muss von Anfang an bei der Entwicklung berücksichtigt werden. Dies hat Microsoft vor einigen Jahren sehr richtig erkannt und 2004 durch die Einführung des Security Development Lifecycle (SDL) im Rahmen des Trustworthy Computing praktisch umgesetzt. Das erste vollständig nach dem SDL entwickelte System war Windows Vista, in dem nach einem Jahr 45 Prozent weniger Schwachstellen als in Windows XP gefunden wurden. Ein deutlicher Beweis dafür, dass sich sichere Entwicklung auszahlt. Einen Rückblick auf die vergangenen sechs Jahre Security Development Lifecycle liefert Microsoft in einem Statusbericht.

Die Grundsätze des SDL

Der SDL geht von vier "Best Practices" als Grundlage aus:

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

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

Secure by Deployment
Das fertige Programm wird so ausgeliefert, dass es möglichst optimal installiert und eingerichtet wird. Das bedeutet, dass die Dokumentation und die Standardeinstellungen des Installationsprogramms gezielt auf eine sichere Installation ausgerichtet werden, umfasst aber auch z.B. Schulungen für Administratoren und Benutzer.

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

Die Phasen des SDL

Microsoft hat einen vereinfachten SDL veröffentlicht, der aus sieben Phasen besteht:

1. Training

Die erste Phase des SDL schafft die Voraussetzungen dafür, ihn überhaupt implementieren zu können. Sie besteht nur aus einem einzigen Schritt: Dem "Core Security Training". Alle Personen mit technischen Aufgaben wie Entwickler, Tester und Programm-Manager müssen bei Microsoft mindestens einmal im Jahr einen entsprechenden Kurs besuchen.

Der Grund dafür ist ganz einfach: Nur wenn Sie überhaupt wissen, welche Sicherheitsprobleme und Schwachstellen es gibt, können Sie sie in Ihrem Programm erkennen und vermeiden. Und da sich die Sicherheitswelt rasend schnell weiterdreht, reicht es nicht, einmal einen Kurs zu besuchen, um dann für alle Zeiten genug zu wissen. Stattdessen müssen Sie sich auf dem Laufenden halten, damit Ihr Programm nicht plötzlich Angriffen zum Opfer fällt, von denen Sie nie zuvor gehört haben. Ein gutes Beispiel haben Sie bereits im Rahmen dieser Reihe kennen gelernt: Das Binary Planting, denn Missbrauch unsicherer Suchpfade aus der Ferne.

2. Requirements

In der zweite Phase werden die Sicherheits- und Datenschutz-Anforderungen des Programms spezifiziert, sodass Sie optimal in das Projekt integriert werden können. Die Phase besteht aus drei Schritten:

  • Establish Security and Privacy Requirements
    Welche minimalen Sicherheits- und Datenschutz-Anforderungen muss das Programm in der vorgesehenen Arbeitsumgebung erfüllen? Überlegen Sie einfach, welche der drei Schutzziele der IT-Sicherheit durch Ihr Programm gefährdet werden können, dann wissen Sie auch, welche Anforderungen es erfüllen muss: Alle, die nötig sind, um diese Gefahren zu eliminieren.

    Außerdem wird in diesem Schritt ggf. der zuständige Sicherheitsexperte benannt und ein Tracking-System zum Verfolgen von Schwachstellen eingeführt. Der Experte werden Sie meist selber sein, und eine Art von Bugtracking-System ist immer wichtig - notfalls in Form einer Liste, in der Sie gefundene Fehler eintragen.
  • Define Quality Gates/Bug Bars
    Welche Sicherheits- und Datenschutz-Anforderungen muss das Programm mindestens erfüllen, damit es veröffentlicht werden kann?
    Damit sind z.B. Forderungen wie "Es darf bei der Veröffentlichung keine bekannten kritischen Schwachstellen geben" gemeint. Um diese zu erfüllen, müssen Sie wissen, welche Schwachstellen es überhaupt geben kann und welche davon kritisch sind.
  • Perform Security and Privacy Risk Assessment
    Mit Security Risk Assessments (SRAs) und Privacy Risk Assessments (PRAs) werden die funktionalen Aspekte des Programms identifiziert, die besonders sorgfältig untersucht werden müssen. Mit anderen Worten: Welche Funktionen lassen sich besonders leicht missbrauchen oder stellen bei einem Missbrauch eine besonders große Gefahr dar?

3. Design

In der dritten Phase wird die Sicherheitsarchitektur des Programms definiert und dokumentiert. Auch diese Phase besteht wieder aus drei Schritten:

  • Establish Design Requirements
    In diesem Schritt werden Sicherheits- und Datenschutz-Spezifikation erarbeitet: Wie können die benötigten Features des Programms sicher implementiert werden?
  • Attack Surface Analysis/Reduction
    Welche Angriffsflächen bietet das Programm, und wie können sie reduziert werden?
  • Threat Modeling
    Welchen Bedrohungen ist das Programm in der geplanten Einsatzumgebung ausgesetzt?

4. Implementierung

In der vierten Phase wird das Programm sicher implementiert, wieder in drei Schritten:

  • Use Approved Tools
    Eine Liste zulässiger Tools und zugehöriger Sicherheitsprüfungen und -meldungen, die regelmäßig aktualisiert wird, sorgt dafür, dass sichere Werkzeuge sicher verwendet werden. Das klingt "doppelt gemoppelt", ist es aber nicht: Zum einen gibt es das Konzept des "transitiven trojanischen Pferds", bei dem z.B. ein präparierter Compiler Schadcode in die damit erstellten Programme einfügt, zum anderen kann auch ein sicheres Tool unsicher eingesetzt werden, z.B. indem Compiler- oder Linkerwarnungen ignoriert oder falsch interpretiert werden.
  • Deprecate Unsafe Functions
    Manche Funktionen führen zu bekannten Schwachstellen, z.B. provozieren viele Kopierfunktionen in C Pufferüberlauf-Schwachstellen. Diese unsicheren Funktionen sollten Sie nicht mehr verwenden. Tools helfen ggf. dabei, diese im Quelltext zu finden.
  • Perform Static Analysis
    Eine statische Analyse des Codes vor dem Kompilieren stellt sicher, dass die Regeln für die sichere Entwicklung des Programms eingehalten wurden.

5. Verification

In der fünften Phase wird geprüft, ob alle aufgestellten Sicherheits- und Datenschutz-Anforderungen eingehalten werden. Auch diese Phase besteht wieder aus drei Schritten:

  • Perform Dynamic Analysis
    Bei der dynamischen Analyse wird während der Laufzeit des Programms geprüft, dass alle Funktionen wie vorgesehen arbeiten und es z.B. keine Buffer Overflows und Privilegienverletzungen gibt.
  • Fuzz Testing
    Beim Fuzzing wird das Programm mit zufällig erzeugten Eingaben getestet. Die meisten Fehler und sich daraus ergebenden Schwachstellen beim Verarbeiten von Daten werden entweder durch Zufall oder durch Fuzzing gefunden.
  • Attack Surface Review
    Im letzten Schritt wird die Angriffsfläche überprüft, um sicher zu stellen, dass sich während der Entwicklung nicht durch Änderungen am Entwurf oder der Implementierung neue, bisher nicht berücksichtigte Angriffspunkte ergeben haben.

6. Release

In der sechsten Phase wird das Programm für die Veröffentlichung vorbereitet. Wieder einmal in drei Schritten:

  • Incident Response Plan
    Der erste Schritt befasst sich vereinfacht mit der Frage: Was passiert, wenn etwas passiert?
    Zum einen muss es einen erreichbaren Ansprechpartner für Probleme geben, zum anderen Pläne, wie auf gefundene Schwachstellen, sowohl im eigenen Programm als auch in Komponenten von Drittherstellern reagiert werden soll.

    Für Sie bedeutet das: Sehen Sie eine E-Mail-Adresse vor, an die Schwachstellen gemeldet werden können, und überlegen Sie sich, wie sie auf so eine Meldung reagieren. Wenn Sie sich jetzt vorbereiten, brechen Sie später nicht in Panik aus, sondern können beruhigt ihrem vorbereiteten Plan auf die Schwachstelle reagieren.
  • Final Security Review
    Im "Final Security Review" (FSR) werden alle bisherigen sicherheitsrelevanten Aktivitäten ein letztes Mal überprüft: Wurden die gesetzten Ziele erreicht, sodass das Programm veröffentlicht werden kann?
  • Release/Archive
    Jetzt ist es geschafft: Das Programm kann veröffentlicht werden. Alle angefallenen Informationen und Daten wie Spezifikationen, Quelltexte, Binärdateien, Dokumentationen etc. müssen nun archiviert werden, damit im Fall später auftretender Probleme wie z.B. gefundenen Schwachstellen darauf zurückgegriffen werden kann. Verfahren Sie hier nach dem "Viel hilft viel"-Ansatz: Jede jetzt gelöschte Datei kann später die sein, die Ihnen bei der Korrektur einer Schwachstelle entscheidend geholfen hätte.

7. Response

Die siebte Phase bildet den Abschluss des SDL: Reagieren Sie auf nach der Veröffentlichung bekannt gewordene Schwachstellen. Microsoft hat zu diesen Zweck das Microsoft Security Response Center (MSRC) zur Identifikation, Überwachung und Lösung von sicherheitsrelevanten Vorfällen eingerichtet.

Eine vergleichbare Lösung mag für Ihr Programm ein zu großer Aufwand sein, aber eine speziell für solche Zwecke vorgesehen Seite Ihrer Website oder zumindest ein Abschnitt in der Seite mit der Programmbeschreibung sollte Ihnen die Sicherheit ihres Programms wert sein. Geben Sie dort die E-Mail-Adresse an, an die Schwachstellen gemeldet werden können, und informieren Sie über gefundene Schwachstellen, mögliche Workarounds und bereit stehende Patches oder Updates.

SDL for Agile

Der hier beschriebene SDL-Prozess lässt sichnicht 1:1 in der agilen Software-Entwicklung anwenden. Aus diesem Grund wurde ein Agile SDL-Prozess (SDL/A) entworfen, um auch agile Entwicklungsprozesse unterstützen zu können. Für jedes agile Software-Projekt ist die vorsichtige Integration von Sicherheitsaspekten ein sehr kritischer Punkt: Sicherheitsaspekte kosten Zeit und Aufwand und sind für agile Projekte, bei denen es auf minimalistischen Aufwand und kürzeste, häufige Release-Zyklen ankommt, der Teil wo sehr gezielt abgewogen werden muss, welche Elemente in jedem Sprint und welche Elemente nur einmal angewendet werden müssen.

Der wichtigste und größte Unterschied zwischem klassischen SDL und SDL for Agile besteht darin, dass der SDL for Agile nicht jede Anforderung für jede Version (oder jeden "Sprint") erfüllen muss. Jede SDL-Anforderung ist aber enthalten, weil so nachweislich ernste Sicherheits- oder Datenschutzrisiken verhindert werden können. Jedoch steht in einem kurzen Veröffentlichungszyklus einfach nicht genug Zeit zur Verfügung, um jede SDL-Anforderung zu erfüllen und trotzdem Features zu entwickeln. Deshalb definiert SDL/A drei Stufen der Anforderungshäufigkeit (d.h. wie oft die Anforderung erfüllt werden muss) – jede SDL-Anforderung wird in eine dieser drei Kategorien eingeordnet.

Die Every-Sprint-Anforderungen
Die erste Häufigkeitsebene für SDL/A ist die Every-Sprint-Ebene. Diese Anforderungen sind nicht verhandelbar und müssen in jedem Sprint erfüllt werden, unabhängig von der Sprintlänge. Aus diesen Anforderungen erwächst die höchste Belastung für die Entwicklungsteams, da sie häufig erfüllt werden müssen. Aus diesem Grund werden diese Anforderungen sehr sorgfältig gemäß zwei Faktoren ausgewählt:

  • Bedeutung der Anforderung: Wie viele Sicherheitsrisiken werden vermieden und wie kritisch sind diese Sicherheitsrisiken? Jede Anforderung ist wichtig. Ähnlich wie verschiedenen Sicherheitsrisiken eine unterschiedliche Gewichtung in der Fehlerliste zugeordnet ist, werden auch den Anforderungen, die dem Schutz vor diesen Sicherheitsrisiken dienen, verschiedene Gewichtungen zugewiesen.
  • Leichtigkeit, mit der eine Anforderung automatisiert werden kann: Selbst wenn es unwahrscheinlich ist, dass eine Anforderung einen weiteren Code Red-Angriff verhindert, ist sie wahrscheinlich in jedem Sprint erforderlich, sofern sie im Build-Prozess oder in der Richtlinie zum Einchecken von Code automatisiert werden kann.

Ein Beispiel für eine Anforderung, die in die Every-Sprint-Kategorie fällt, ist die Anforderung zur Verwendung der von ASP.NET bereitgestellten Verteidigung "ValidateRequest" gegen Cross Site Scripting (XSS). Die ValidateRequest-Anforderung erfüllt beide Kriterien für die Einbeziehung in jeden Sprint: Sie unterstützt Produkte bei der Abwehr höchst kritischer XSS-Angriffe und ist im Grunde kostenlos, da ValidateRequest standardmäßig aktiviert ist.

Ein weiteres Beispiel ist die Anforderung, ein Bedrohungsmodell für die Anwendung zu erstellen. Im Unterschied zu ValidateRequest kann die Bedrohungsmodellierung einen erheblichen Zeit- und Arbeitsaufwand bedeuten. Bedrohungsmodellierung ist jedoch der Grundpfeiler des SDL und darf nie ausgelassen werden. Bedrohungsmodellierung ist wesentlich für die Aufdeckung von Risiken auf der Entwurfsebene, die möglicherweise nur durch eine umfassende Umstrukturierung minimiert werden können, wenn sie zu einem späteren Zeitpunkt im Entwicklungszyklus entdeckt werden.

Die Onboarding-Anforderungen
Die zweite Gruppe der Anforderungen wird als Onboarding-Anforderungen bezeichnet. Dies sind Anforderungen, die Produktteams nur einmal zu Beginn des Projekts erfüllen müssen und dann nie wieder. Im klassischen SDL funktioniert jede Anforderung auf diese Weise: Produkte, die den klassischen SDL verwenden, verfügen jedoch in der Regel über klar definierte Entwicklungsphasen, einschließlich eines klar definierten Endes (Veröffentlichung des Produkts). Im Gegensatz dazu fehlt Webanwendungen oft das klar definierte Ende. So ist es möglich, dass das Team jeden Freitagnachmittag ein neues Update veröffentlicht und dann am Montagmorgen mit der Entwicklung neuer Features beginnt. Dieser Prozess kann auf unbestimmte Zeit fortgesetzt werden.

Beispiele sind unter anderem die Anforderung zur Konfiguration des Fehlerverfolgungssystems eines Produkts zur Nachverfolgung sicherheitsspezifischer Daten oder die Erstellung eines Baseline-Bedrohungsmodells für eine Anwendung.

Die Bucket-Anforderungen
Alle anderen SDL-Anforderungen, die weder in die Kategorie der Every-Sprint- noch die der Onboarding-Anforderungen fallen, werden in einen von drei Anforderungsbuckets eingeordnet:

  • Security Verification (Sicherheitsüberprüfung)
  • Design Review (Designüberprüfung)
  • Response Plans (Reaktionspläne)

So würde beispielsweise die SDL-Anforderung zum Fuzzing von Eingabebehandlungsroutinen in den Bucket "Security Verification" eingeordnet werden. Die Anforderung zum Definieren eines Notfallwiederherstellungsplans gehört in den Bucket "Response Plans".

Im Unterschied zum klassischen SDL, wo alle diese Anforderungen vor der Produktveröffentlichung erfüllt sein müssen, reicht es in SDL/A aus, in jedem Sprint eine einzige Anforderung aus jedem Bucket zu erfüllen. Dies ist das Zugeständnis von SDL/A an Projekte mit agiler Entwicklung, die über kürzere Veröffentlichungszeitpläne verfügen.

Fazit

Der Security Development Lifecycle ist ein sehr guter Ansatz zur Entwicklung sicherer Programme, der sich auch im Kleinen einsetzen lässt. Microsoft hat eine Reihe von Tools bereit gestellt, die Ihnen bei der Umsetzung des SDL helfen können. Diese werden Ihnen in folgenden Artikeln genauer vorgestellt. Weitere Informationen finden Sie auf der offiziellen SDL-Seite, dem SDL Pro Network oder diesem deutschsprachigen Webcast.


 

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?