Security Development Lifecycle, Teil 2

Aus MittelstandsWiki
Wechseln zu: Navigation, Suche

Im Dialog mit dem Untergrund

Von Uli Ries

Im Rahmen des Security Development Lifecycles öffnet sich Microsoft vorsichtig dem praktischen Know-how der Hacker-Gemeinde. Das Ziel ist sogar eine dauerhafte Zusammenarbeit, wenn die Hacker Microsoft gegenüber zumindest neutral eingestellt sind. Feindlich gesinnte Sicherheitsexperten, die dem Konzern möglichst großen Schaden zufügen oder ihn erpressen wollen, kommen nicht als Partner in Frage.

Die freundlich gesinnten Hacker kontaktiert das Outreach Team entweder auf Security-Konferenzen wie der DEFCON oder über das Internet. Die Mannschaft liest aufmerksam einschlägige Blogs und Mailing-Listen und wird so auf interessante Köpfe aufmerksam. Sehr oft melden sich die Hacker aber auch selbst bei Microsoft, um mit einer entdeckten Schwachstelle auf sich aufmerksam zu machen.

Kronjuwelen in Hacker-Händen

Microsoft-Sprecher werden nicht müde zu wiederholen, dass der Konzern nicht erpressbar sei und niemals für Informationen über gefundene Schwachstellen bezahlen werde. Trotzdem kann es sich für die Hacker auszahlen, mit Redmond zu kooperieren. Denn Microsoft lädt die fleißigsten Bug-Jäger gegen ein Honorar regelmäßig in die US-Zentrale ein, damit die Hacker mit den Produktentwicklern direkt diskutieren und ihr Wissen weitergeben können. Darüber hinaus organisiert Microsoft sogar eine eigene, kleine interne Hacker-Konferenz namens BlueHat. Hier präsentieren die Hacker vor dem versammelten Management und den Produktverantwortlichen.

Die intensivste Form der Zusammenarbeit ist aber die Qualitätskontrolle von gerade in der Entwicklung befindlichen Betriebssystemen oder Service Packs: Microsoft gewährte erstmals während der Entwicklung von Windows Vista bis zu 30 Hackern Zugang zum Sourcecode des Systems. Diese Prüfung durch externe Fachleute ist ebenfalls ein Ergebnis und Bestandteil des Security Development Lifecycles.

Zu den angeheuerten Hackern gehört auch der Entdecker des DNS-Bugs, Dan Kaminsky. Er erzählt:

„Microsoft hat uns aufgefordert, den Code nach Schwachstellen abzusuchen und sie gaben uns die Macht, binnen 24 Stunden mit jedem Entwicklungsteam auf dem Microsoft Campus über unsere Entdeckungen zu diskutieren. Auf diese Weise entfernten wir tausende von Bugs aus dem Sourcecode.“

So stellten die Hacker z.B. fest, dass die C-Bibliothek „strcopy“ mehrere tausend mal im Sourcecode auftaucht. Diese Bibliothek wird von Crackern als Startpunkt für Buffer Overruns missbraucht, mit deren Hilfe sie sich Administratorenrechte verschaffen. Danach wurde sie komplett aus dem Sourcecode verbannt.

SKL twc.jpg Bill Gates persönlich setzte 2002 per E-Mail die Zeichen auf Sicherheit (Bild: Microsoft)

Die Hacker arbeiten sich momentan durch den Sourcecode des inzwischen als Betaversion verfügbaren Windows-XP-Nachfolgers Windows Seven. Zuvor wurde der Windows Server 2008 von ihnen intensiv unter die Lupe genommen. Dass sich fremde Hacker eines Tages am Heiligtum seines Unternehmens, dem Sourcecode, zu schaffen machen, hätte sich Bill Gates im Jahr 2002 sicher nicht träumen lassen, als er die berühmte Trustworthy-Computing-Nachricht verschickte.

Immer wieder dienstags

Unabhängige Sicherheitsexperten sind für Microsoft nicht nur zum Überprüfen von Sourcecode unabdingbar – also vor der Veröffentlichung des Systems – sondern auch beim Aufdecken von Sicherheitslücken der bereits verkauften Betriebssysteme. Der größte Teil der per Windows Update am 2003 eingeführten Patch Tuesday automatisch verteilten Sicherheitsupdates geht auf Meldungen über Einfallstore zurück, die von Sicherheitsexperten aus der ganzen Welt an Microsoft übermittelt werden. Damit an eben jenem zweiten Dienstag im Monat Updates verschickt werden können, die sowohl das eigentliche Problem beheben, als auch einwandfrei zu installieren sind, ist ein strikter Ablauf nötig.

SDL Livecycle.png Der Security Development Lifecycle soll sowohl für sichere Betriebssysteme und Anwendungen sorgen, als auch einwandfreie Updates sicherstellen. (Bild: Microsoft)

Verantwortlich für den kompletten Prozess ist das Microsoft Security Response Center (MSRC), zu dem auch das Outreach-Team gehört. Beim MSRC laufen nicht nur alle Informationen zusammen, die mit eventuellen Sicherheitsproblemen zu tun haben; das MSRC verteilt den fertigen Patch dann auch per Windows Update. Programmiert werden die Updates von den Teams, die ursprünglich auch das betroffene Produkt entwickelt haben. Denn nur diese Programmierer haben das Fachwissen, um die Softwareflicken in möglichst kurzer Zeit fertig zu stellen.

Das MSRC bezieht seine Informationen aus den jährlich über 100.000 E-Mails von außen, aber auch aus Newsgroups oder von Websites. Wird eine Schwäche gemeldet, klopft ein spezielles Team des MSRC sofort die Relevanz der Informationen ab und versucht, die gemeldete Attacke zu reproduzieren. Pro Lücke gibt es einen dedizierten Mitarbeiter, der für den kompletten Ablauf bis hin zur Freigabe des Updates verantwortlich ist. Dabei wandeln die Experten ständig auf einem schmalen Grat: Weisen sie die oftmals kryptischen und nichts sagenden Meldung zu schnell zurück, entgeht ihnen eventuell eine schwer wiegende Sicherheitslücke. So wurde im Jahr 2005 zu schnell Entwarnung gegeben. Damals misslang die Reproduktion eines Angriffes im Labor und die Meldung wurde als irrelevant abgetan. Genau diese Lücke führte dann aber kurz darauf zum massenhaften Ausbruch des Zotob-Wurms.

Wird eine Meldung als relevant eingestuft stößt sofort das Entwicklerteam des betroffenen Produkts hinzu, um den Patch zu entwickeln. Gleichzeitig suchen die Kollegen des MSRC nach anderen Microsoft-Programmen, die eventuell ebenfalls betroffen sind. Außerdem wird per Fuzzing geprüft, ob die zu untersuchende Lücke eventuell noch andere Auswirkungen an anderen Stellen hat. Hierzu wurden eigens umfangreiche Programme geschrieben, die das Fuzz Testing automatisch erledigen. Die Entwicklung der Patches erfolgt auch wieder nach den Vorgaben des Security Development Lifecycles, das z.B. das Fuzzing vorschreibt.

Sind die Updates fertig programmiert, folgt eine lange und intensive Testphase, erst im Labor, dann in einem kleinen Teil des Produktivnetzwerks auf dem Microsoft Campus in Redmond. Im Gegensatz zur Prä-SDL-Ära, in der Patches teilweise nach nur einem Tag Testen freigegeben wurden, wenden die Tester dafür heute meist mehrere Wochen auf. Auf diese Weise wurde die Zahl der Patches, die zurückgezogen werden müssen, immens gesenkt. Einfache Patches sind laut Cushman schon nach einer Woche entwickelt und getestet, bei komplexen Problemen kann sich der Prozess bis zu 120 Tage lang hinziehen.

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.

Freigabe unter Zeitdruck

Sind alle Tests erledigt, wird die Freigabe des Updates zum nächsten Patch Tuesday vorbereitet. Hierzu gehört unter anderem das Verfassen der Security Bulletins, die die Funktion jedes Updates beschreiben und dessen Bedeutung deutlich machen. Dabei achten die Verfasser darauf, dass sie nicht zu viele Informationen über das gestopfte Loch verraten, um Crackern keinerlei Anhaltspunkte über die Art des gemeldeten Angriffswegs zu geben.

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.

Ist alles erledigt, wird das Update dann am Patch Tuesday per Windows Update automatisch auf knapp 500 Mio. PCs weltweit verteilt. In schweren Krisenfällen wie im Oktober 2008 weicht das MSRC von der Veröffentlichung am Patch Tuesday ab. Für Microsofts Kunden ist allerdings die Regelmäßigkeit der Dienstagspatches immens wichtig, weil sie die für Umsetzungs- und Praxistests notwendige Zeit reservieren müssen. Wie die rasante Verbreitung des nach wie vor grassierenden Wurms Conficker beweist, lassen sich manche Kunden damit aber zu viel Zeit. Denn der außerplanmäßige, seit Oktober 2008 verfügbare Patch schließt genau die Windows-Lücke, durch die Conficker eindringt.

Teil 3 dieser Serie stellt einige der nützlichsten Sicherheitsautomatismen genauer vor, die Microsoft Programmierern zur Verfügung stellt.

Nützliche Links