Security Development Lifecycle, Teil 1

Aus MittelstandsWiki
Wechseln zu: Navigation, Suche

Strategie statt Zufall

Von Uli Ries

Microsoft musste es auf die harte Tour lernen: Bevor die verheerenden Angriffe der Würmer Nimda und Code Red im Jahr 2001 weltweit zigtausende von PCs und Servern lahm legten, spielten in Redmond Sicherheitsaspekte bei der Softwareentwicklung kaum eine Rolle. Im Vordergrund standen vielmehr Funktionsumfang und Optik. Bill Gates persönlich veränderte dann im Jahr 2002 die Prioritäten und erklärte Trustworthy Computing in einer berühmt gewordenen E-Mail zum wichtigsten Ziel.

Auf Herz und Nieren

Eine tragende Säule des Trustworthy Computing ist der so genannte Security Development Lifecycle (SDL). Er soll die Entwicklung weitgehend fehlerfreier und somit sicherer Betriebssysteme und Anwendungen ermöglichen. Insgesamt durchlaufen Microsoft-intern inzwischen knapp 300 Produkte – vom per Windows-Update verteilten Windows-Patch über Xbox-Spiele bis hin zum Serverbetriebssystem – pro Jahr den SDL.

Steve Lipner, einer der Väter des SDL, kann wenige Jahre nach dem Start bereits auf etliche Erfolge verweisen: So mussten für Windows XP im ersten Jahr nach der Einführung 65 Sicherheitsupdates veröffentlicht werden. Windows Vista kam mit 36 aus. (Böse Zungen behaupten, dass diese gute Quote einzig an der im Vergleich zu XP geringen Verbreitung von Windows Vista liegt.)

Kommunikation-und-netze-2015-02.jpg
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserer Magazin­reihe. Einen Über­blick mit freien Down­load-Links zu sämt­lichen Einzel­heften bekommen Sie online im Presse­zentrum des MittelstandsWiki.

Noch besser ist das Ergebnis des SQL Servers 2005, der in den ersten zwölf Monaten nach Einführung keinerlei Patches benötigte, wohingegen der Vorgänger SQL 2000 mit 31 Updates geflickt werden musste. Insgesamt sank die Zahl der in Microsoft-Produkten entdeckten Schwachstellen in den letzten beiden Jahren, wohingegen die Gesamtzahl aller in Anwendungen und Betriebssystemen aufgetauchten Lücken stark anstieg. Diese Diskrepanz spricht laut Microsoft für die Effektivität des SDL.

SDL Lifecycle2.png Damit der Security Development Lifecycle die komplette Produktenwicklung absichern kann, besteht er aus zahlreichen Einzelelementen. (Bild: Microsoft)

Der SDL besteht aus einer Vielzahl von Komponenten, die den kompletten Entwicklungszyklus eines Softwareprodukts begleiten. Stark vereinfacht gesprochen ist der SDL eine umfangreiche und von Produkt zu Produkt variierende Checkliste. Diese Liste kann mehr als 700 Punkte lang sein und muss von den Entwicklern vollständig abgearbeitet werden, bevor ein Softwareprodukt freigegeben wird.

So schreibt der SDL z.B. bestimmte Einstellungen beim Kompilieren oder spezielle ASP-Kommandos vor. Außerdem umfasst er Richtlinien, wie und womit der Quellcode auf Schwachstellen getestet werden muss. SLD fordert jeden Entwickler dazu auf, sich Gedanken über mögliche Angriffe auf seinen Code zu machen (Threat Modelling) und versucht so, die angreifbaren Stellen zu minimieren: Nicht dringend benötigte Funktionen sind im Lieferzustand der Programme abgeschaltet, um mögliche Einfallstore für Cracker zu minimieren.

SDL für alle

Seit Ende 2008 lassen die Redmonder jeden Softwareentwickler gratis vom SDL profitieren, indem sie die wichtigsten Erkenntnisse und Ratschläge im Rahmen des SDL Optimization Models veröffentlichten. Microsoft sieht sich in der Pflicht, auch andere Firmen und einzelne Entwickler am gesammelten Wissen teilhaben zu lassen.

Der Konzern sieht die besondere Notwendigkeit darin begründet, dass Cyberkriminelle immer stärker Anwendungen wie die diversen Internet-Browser ins Visier nehmen und vom Betriebssystem nach und nach abrücken. Um den Angreifern keine Chance zu lassen, müssen sämtliche Anwendungen möglichst sicher programmiert sein. Das Optimization Model bringt aber nicht den vollständigen SDL mit, sondern ist ein Destillat der wichtigsten Erkenntnisse. Das Komplett-SDL ist nur für Konzerne von der Größe Microsofts gangbar.

Auch das SDL Threat Modeling Tool v3 gibt der Konzern frei. Damit können Entwickler von Angreifern ausnutzbare Schwächen im Design ihrer Anwendungen aufspüren. Quellcodeanalysen sind mit dem Tool nicht zu machen. Stattdessen fordert es den Programmierer auf, die Funktionsweise seines Programms im Threat Modeling Tool nachzubauen.

Es ist also nach wie vor Sachverstand nötig, da das Programm nur eventuelle Schwachstellen aufzeigt. Diese verbergen sich immer im Design, nicht im Sourcecode. Auch böse Buben haben keine Freude am Threat Modeling Tool, da es nicht dazu taugt, beliebige Anwendungen automatisch auf potenzielle Löcher hin zu untersuchen.

Rund um das SDL gibt es inzwischen auch Dienstleistungen, SDL Pro Network genannt. Zum Netzwerk gehören momentan neun Dienstleister, darunter die deutsche n.runs AG, die Programmierer bei der SDL-Integration in den eigenen Entwicklungsprozess unterstützt.

Serie: Security Development Lifecycle
Teil 1 zeichnet eine recht erfolgreiche Geschichte nach: von der Trustworthy-Computing-Mail Bill Gates’ bis zu den offenen Threat Modeling Tools für Programmierer. Teil 2 interessiert sich dafür, wie kooperative Hacker den MS-Code austesten und wie die Ergebnisse per Patch Tuesday in alle Welt gehen. Teil 3 stellt die wichtigsten Hilfsmittel vor, die Microsoft Entwicklern an die Hand gibt, damit sie gefährliche Bugs rechtzeitig identifizieren.

Neben den zahlreichen Vorgaben zum eigentlichen Softwareentwicklungsprozess gehört auch externe Kommunikation zum SDL, etwa die Security Bulletins, die gepatchte Schwachstellen beschreiben. Auch hier hat Microsoft aus seinen Fehlern gelernt und sich gegenüber der oftmals als Grauzone angesehenen weltweiten Hackergemeinde geöffnet. Früher waren Hacker für Microsoft ausschließlich Gegner, die oft ignoriert, mitunter juristisch verfolgt wurden. Inzwischen gibt es das nach dem Sozialpädagogenjargon so genannte Outreach Team, das einzig und allein damit beschäftigt ist, in Verbindung mit den hellsten Köpfen der weltweiten Hacker-Community zu bleiben.

Wie das geht, schildert Teil 2 dieser Serie.

Nützliche Links