Warum Redmond es Ernst meinte, als er Sicherheit in Windows 7 mit einbackte.
Es ist wahrscheinlich gut, dass mein Lieblings-Softwareentwickler mich am liebsten in Sushi-Restaurants trifft. Wenn ein Sicherheitsfanatiker wie ich eine Diskussion mit einem Code-Jockey wie Adam [Name zum Schutz der Schuldigen geändert] anfängt, dann ist es besser, wenn keine scharfen Utensilien bereitliegen. „Was meinst Du damit, ‚Sicherheit ist nicht Dein Problem‛!? Was soll das heeeiiiisssen ‚Der Kram kann bis später warten?‛”, kreische ich, während mein Freund lässig kaut, schluckt und erklärt, dass dort, wo er arbeitet, erst die Software gebaut und dann die „Bugs” später ausgebügelt werden – einschließlich jeglicher auftauchender Sicherheitslücken.
Und dann bestellt er mehr Sake, während ich darüber nachdenke, ob mehr Angst vor schlechtem Sushi oder vor Adams Software haben sollte.
Glücklicherweise arbeitet Adam nicht bei Microsoft. Im Jahr 2004, nachdem Sicherheitsforscher und auch solche mit weniger edlen Motiven jahrelang auf Microsoft eingehämmert hatten, machte Microsoft es zur unternehmensweiten Richtlinie, dass Sicherheitsprozesse in die Software mit eingebacken werden müssen, und zwar von dem Moment an, wo die ersten Notizen auf die erste Weißwandtafel gekritzelt werden. Windows 7 ist die zweite Version des Vorzeige-Betriebssystems des Unternehmens, das den vollständigen Prozess durchläuft, der unter dem Namen Microsoft Security Development Lifecycle bekannt und vielleicht sogar beliebt ist.
Beliebt? Endlich akzeptiert nennt es David Ladd, Haupt-Sicherheitsprogramm-Manager im Security Development Lifecycle (SDL)-Team des Unternehmens. Er sagt, der Prozess ist in Entwicklungs-Teams im ganzen Unternehmen „fest verwurzelt”. Genaue Sicherheitsüberprüfung ist in allen sechs Phasen des Software-Entwicklungsprozesses verwoben.
1. Anforderungen Während die Entwickler langsam herausfinden, welche Eigenschaften in die neue Software gehören, werden Projekt bei Microsofts Secure Windows Initiative-Team registriert, die wiederum der Entwickler-Crew Sicherheitsberater zur Verfügung stellen.
2. Design Die Anforderungen und Struktur für die neue Software werden ausgearbeitet während Sicherheitsleute die Sicherheitsarchitektur entwickeln und Richtlinien für das Produkt entwerfen, potenzielle Angriffsflächen prüfen und mögliche Bedrohungen modellieren. Ladd sagt, dass das Unternehmen seit den Entwicklungsjahren von Windows Vista schwerpunktmäßig mehr Sicherheit in diese Phase des Prozesses bringt – und zwar früh -, da dies die Phase ist, in der potenzielle Sicherheitsprobleme am leichtesten entstehen und am kosteneffektivsten zu lösen sind.
Gefahrenmodellierung ist in vieler Hinsicht eine Übung in kreativem Denken, das dem Design-Prozess selbst gleich kommt, da die Sicherheitsleute versuchen, Bedrohungen für jegliche Software-Features vorauszusehen, die möglicherweise Sicherheits- oder Datenschutzauswirkungen haben (wie gesagt, zur gleichen Zeit werden von der allgemeinen Entwicklung die Features an sich ausgedacht). Ladd hat Bedenken, wenn es darum geht, spezifisch zu werden. Er sagt jedoch, dass das Team für Windows 7 „dutzende von Gefahrenmodellen mit unterschiedlicher Komplexität” herausgefunden hat.
3. Implementierung. Die Codierung ist gegenwärtig voll und ganz im Gange. Während die Entwickler den Code fließen lassen, tun die Sicherheitsleute ihr Bestes, ihn zu brechen. Sie führen Code-Überprüfungen durch, lassen Code-Scanning-Tools laufen, die versuchen Pufferüberläufe zu finden (ein beliebter Angriffsvektor für schädliche Software) und so weiter, bringen Codierung an, testen Standards und lassen andere Sicherheitstest-Software laufen, einschließlich „Fuzzing”-Tools, die mit API verbundene Probleme auffangen können. Bei Windows 7 bekamen die Fuzzing-Tools mehr zu schwitzen, als bei Vista; die Liste gesperrter APIs, sagt Ladd, hat sich erheblich erweitert, seitdem es Vista gibt und somit werden eine ganze Reihe potenzieller Angriffswege verschlossen.
Risikominderungen – Methoden, die es Entwicklern leichter machen, den Versuchen der Hacker, Sicherheitslücken auszunutzen, entgegenzutreten – sind bei SDL gegenwärtig von großer Bedeutung. Methoden, die auf fundamentaler, gründlicher Abwehr basieren, so wie die Verhütung von Ausnutzung von Heapbeschädigung im Benutzermodus, Integritätschecks für sichere Aufhebung der Verknüpfungen im Kernel-Pool und Filterverbesserungen an XSS-Filtern in Internet Explorer 8 (dem Standard-Browser in Windows 7) haben, so Ladd, in Windows 7 ihren ersten Auftritt.
4. Verifikation. Die Software ist nun funktionsmäßig fertiggestellt und zum Beta-Test bereit. Für Sicherheitsleute geht der Security-Push (ja, das ist der offizielle Name dieser Phase) jetzt los; sie erweitern Ihre Anstrengungen von in der Designphase identifizierten Angriffsflächen hoher Priorität auf – na, ja, alles. Jetzt, wo das Security-Team nicht nur das neue Material anschaut, sondern auch Legacycode, der aus früheren Versionen der Software stammt und wiederverwendet wird, ist kein Code sicher. Penetrationstests sind ebenfalls im Gange und das Team – mit der Allgemeinheit direkt um die Ecke – bereitet einen Security-Response-Plan für die Zeit nach der Freigabe der Software vor. Das, nach einer endgültigen Sicherheitsprüfung…
5. Freigabe, sofort und für die Produktlebensdauer gefolgt von…
6. Support und Wartung inklusive der nötigen Patches und Fixes.
Microsoft begann, ihren Sicherheitsansatz mit der Markteinführung ihrer Trustworthy Computing Initiative im Jahr 2002 ernsthaft aufzupolieren. Nichtsdestoweniger, Ehre, wem Ehre gebührt: SDL ist weniger ein kreativer Denkanfall von Redmond als eine Anhäufung bewährter Sicherheitsprozesse, die sowohl Microsoft-intern als auch extern entwickelt und für die Anwendungsentwicklung von Client- und Server-Anwendungen gestaltet wurden (offensichtlich vertrautes Terrain für Redmond) sowie für online- oder Cloud-basierte Anwendungen.
Um wiederum die größere Sicherheitsgemeinde zu unterstützen (und Dritt-Entwickler dazu anzuregen, einen ähnlichen, sicherheitsbewussten Entwicklungsansatz zur verfolgen – Adam, hörst Du zu?), ist das Unternehmen bisher bemerkenswert offen bezüglich der Mechanik des Prozesses gewesen, den sie als „nicht-proprietäre“ Information bezeichnen. Zu diesem Zweck stehen die SDL-Prozess-Richtlinien, die regelmäßig aktualisiert werden, online zur Verfügung. Ladd beschreibt einen „Haufen“ SDL-Tools, die ebenfalls frei zum Download zur Verfügung stehen, einschließlich BinScope Binary Analyzer, ein Tool zur Buildüberprüfung; !exploitable, das den Prozess der Fehlerbewertung automatisiert; und ein aktualisiertes Tool zur Gefahrenmodellierung. Im SDL-Tools-Repository stehen weitere Tools, wie zum Beispiel ein einfacher Fuzzer zur Verfügung. Es gibt auch ein kostenloses Training Kit, das mehrere „Virtual Lab“-Vorführungen für Neulinge enthält.
Also, – da SDL ja ein lebendiger Prozess ist, der ständig geprüft und revidiert wird – was hat das Windows7 Team während der Entwicklung denn nun gelernt? Welche Erstaunlichkeiten und Überraschungen boten sich dem Team? Ladd sagt, „es gab überhaupt keine Offenbarungen – und das ist die ideale Erfahrung, wenn es um SDL geht.“ Oder, wie die meisten sicherheitsbewussten Techno-Leute hinzufügen würden, wenn darum geht, ein frisches Betriebssystem kennen und verstehen zu lernen.
