Der Sicherheits- Entwicklungszyklus bei Microsoft Sebastian Weber.

Präsentation zum Thema: "Der Sicherheits- Entwicklungszyklus bei Microsoft Sebastian Weber."—  Präsentation transkript:

1 Der Sicherheits- Entwicklungszyklus bei Microsoft Sebastian Weber

2 Der Sicherheits- Entwicklungszyklus bei Microsoft Sebastian Weber Technologieberater - Developer Platform & Strategy Group Microsoft Deutschland GmbH Sebastian.Weber@microsoft.com

3 Im digitalen Jahrzehnt geht es nicht nur um einen bestimmten Aspekt der Computertechnik bei Unternehmen, Arbeitskräften im Informationsbereich und Privatanwendern und darum, Standards zu schaffen, die diese Dinge miteinander verbinden. Der Dreh- und Angelpunkt sind vertrauenswürdige Systeme, die auf äußerst zuverlässige Weise Ihren Erwartungen entsprechen. In all diesen Bereichen haben wir also neue Szenarien, neue Arten der Computernutzung, die es vorher nie gab – Bill Gates, Microsoft Chairman und Chief Software Architect

4

5 Development Best Practices (SD³+C) Threat Modeling Code inspection Prozess verbessern Nicht verwend. Features ausschalten Angriffsfläche reduzieren Least Privilege Anleitung für den Betrieb Security Tools Training und Schulung Community Engagement Transparenz Klare Richtlinien

6 Der Sicherheits-Entwicklungszyklus

7 Ein Prozess mit dem Microsoft Software entwickelt, der Sicherheitsanforderungen und Meilensteine definiert Verpflichtend für nahezu alle Microsoft Produkte Wird ständig weiterentwickelt (neue Bedrohungen und Technologien) Auf die Praxis abgestimmt Effektiv bei der Reduzierung von Sicherheitslücken Der Sicherheits-Entwicklungszyklus

8 Design Specifications Development of New Code Bug Fixes Code Signing A Checkpoint Express Signoff RTM Product Support Service Packs/ QFEs Security Updates RequirementsDesignImplementationVerificationRelease Support & Servicing Functional Specifications Security Deployment Lifecycle Aufgaben und Prozesse Traditionelle Microsoft Software Product Development Lifecycle Aufgaben und Prozesse Testing and Verification Feature Lists Quality Guidelines Arch Docs Schedules Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling Der Sicherheits-Entwicklungszyklus

9 Security Kickoff & SWI Registrierung Requirements-Phase Ansprechpartner in beiden Gruppen benennen Einer aus dem Security-Team Der andere aus der Produktgruppe Unterstützung der Produktgruppe beim Leben des SDL Vorbereitungen für den Final Security Review Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

10 Ausbildung und Training Requirements- & Design-Phase Jährliches Security-Training vorgeschrieben Teilnahme wird von jedem VP nachgehalten Zusätzliche Schwerpunkte Threat Modeling In Depth Secure Design Security Patterns Security Defects in Detail Fuzz testing SDL for Managers … Writing Secure Code 2nd ist Pflichtlektüre Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

11 Attack Surface Analysis Design-Phase Es geht nicht nur um den Code allein – die Angriffsoberfläche ist mit entscheidend Security-Team arbeitet an Leitfäden zur Reduktion der Angriffsfläche zur Verfügung Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

12 Threat Modeling Design-Phase Kritisch für die Entwicklung sicherer Software Voraussetzung für alle SDL Produkte, bevor sie ausgeliefert werden (FSR baut darauf auf) Threat Modeling Tool als Download verfügbar msdn.microsoft.com Threat Modeling Buch verfügbar http://www.microsoft.com/MSPress/books/6892.asp Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

13 Threat Modeling Design-Phase Sicherheit ist oftmals ad-hoc Threat Modeling identifiziert und bewertet Bedrohungen systematisch Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

14 Threat Modeling – Der Prozess Design-Phase Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling Threats ermitteln Identifizieren Assets Entry Points Trust Levels Security verstehen Use Scenarios System Model Dependencies Identify Threats Analyze Threats

15 Threat Modeling – Assets Design-Phase Was ist zu schützen? Persönliche Wertgegenstände Beispiele Geheime Daten Web Seiten System Verfügbarkeit Alles, was den Betrieb stören könnte Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

16 Threat Modeling – Entry Points Design-Phase Wo können Angriffe stattfinden? Alle Systemgrenzen Kommunikationsschnittstellen Benutzer Andere Systeme Technische Beispiele Web Service, DCOM, RPC Dateisystem, Registry, FTP... Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

17 Threat Modeling – Use Cases Design-Phase Use Cases verstehen Reguläre Anwender Verstehen, was das System machen soll! Die Sicht des Angreifers Bad Guys Verstehen, was das Systen nicht machen soll(te)! Externe Abhängigkeiten Bis wohin gehen meine Security-Untersuchungen? Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

18 Threat Modeling – Architektur Design-Phase Was macht die Anwendung? Use Cases, Data Flow Diagram (DFD) Anwendungsarchitektur Technologien identifizieren Alice Mary Bob IIS Trust Boundaries ASP.NET (Process Identity) Microsoft ASP.NET Microsoft ASP.NET Microsoft SQL Server Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

19 Threat Modeling Tool

20 Threat Modeling – Maßnahmen Design-Phase Optionen: Lassen, wie es ist Aus dem Produkt herausnehmen Besser technologisch absichern Anwender warnen Wie hoch ist das Risiko hinsichtlich der Vulnerability? Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

21 Tools & Best Practices (I) Implementation-Phase Tools machen keine Software sicher Sie skalieren den Prozess Sie forcieren Richtlinien PREfast (MSR) Source Code Annotation Langauge (MSR) AppVerif (AppCompat) schwache Verschlüsselung, Admin-only Probleme, … FxCop Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

22 Tools & Best Practices (II) Implementation-Phase Über 100 Funktionen sind verboten strcpy, strncpy etc Dafür strsafe (StringCchCopy etc) oder Safe CRT (strncpy_s etc) Gefunden beim Peer-Review und vom Security-Team Integer Overflows SafeInt von LeBlanc (verfügbar auf msdn.microsoft.com) Spezielle Managed Code Probleme Vorgeschriebene Compiler-Einstellungen /GS, /SafeSEH, etc. Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

23 Tools – Visual Studio 2003 Implementation-Phase Keine Fehler, keine Warnungen!

24 Tools – Visual Studio 2005 Implementation-Phase Deprecated functions Buffer Overrun Mixed args

25 Security Response Plans Verification-Phase Warum Security-Response Pläne? Tests adressieren bekannte Schwachstellen Es wird Angriffe geben Security-Reponse ist Bestandteil des Produksupports Prozess und Ressourcen pro-aktiv vorbereiten Ein Response-Plan beschreibt u.a. Das Team, das die Anwendung betreuen wird Kontaktpersonen für einen Zwischenfall Integration in den gesamten Response Plan der Organisation Verwendete Technologien und Risiko-Bewertung Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

26 Security Push Verification-Phase Konzentriert sich vor allem auf Legacy-Code Zusätzliche Ausbildung der Entwickler Code Review Aktualisierung der Threat Models Bug Review Penetration Testing Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

27 Final Security Review Release-Phase Notwendige Voraussetzung, damit ein SDL Produkt ausgeliefert werden kann Kann bis zu 10 Wochen dauern Der Prozess für die großen Produkte beinhaltet: Externer (nicht-Microsoft) Review Code Review Penetration Tests Architektur & Design Review Threat Model Review Bug Review Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

28 Post-Bulletin Process Support & Servicing-Phase Jeder Fehler in jedem Bulletin unterliegt einer Ursachenuntersuchung Security-Team hat dedizierte Experten dafür Bericht beinhaltet: Wie konnte der Fehler gefunden werden? (falls bekannt) Code diff (falls zutreffen) Aussage zur Designschwäche (falls zutreffend) Welcher Code, Test oder welche Verteidigung hätte den Fehler finden oder unschädlich machen müssen? Welche Auswirkung hat der Fehler auf andere Plattformen? Action Items und Empfehlungen (Ausbildung ändern, Tools anpassen, Prozess verbessern etc.) Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Threat Modeling

29 Reaktion auf einen Zwischenfall Neuer Sicherheitsvorfall Informationen über neue/aktuelle Angriffe Identifikation Interne Interessens- gruppen Externe Interessens- gruppen Komm.-Plan Kommunikation koordineren Kunden informieren und Anleitungen bereitstellen Kundenproblem e beobachten Release Best Practices aktualisieren Test Tools anpassen Development und Design Process anpassen Nachbe- arbeitung Mehrere Test- Ebenen: Setup und Build Verifikation Code-Tiefe Integration und Umfang Kontrollierte Beta Testing Abschätzung der möglichen Auswirkung Team für den Fix identifizieren Sichtung Code und Design fixen Threat Model anpassen Fix für Test bereitstellen Fix erstellen

30 Zusammenfassung Der Sicherheits-Entwicklungszyklus Ein integrierter Bestandteil im Microsoft Entwicklungszyklus Ein effektiver Prozess, um Sicherheitslücken zu reduzieren Ein lebender Prozess Anwendbar bei Kunden Für Produktentwicklung ausgelegt

31 Ist TwC erfolgreich? Total # 2004Jan-Apr2005 Schätzung 2005 45 23 69 Microsoft Security Bulletins Die Mathematik 23 ÷ 4 Monate = 5,75 pro Monat 5,75 x 12 Monate = 69 Es wird immer schlimmer…TwC funktioniert nicht

32 Die TwC Realität Veröffentlicht 29.11.2000 Veröffentlicht 28.09.2003 2003 Bulletins 653 Tage nach Produktveröffentlichung *Stand 31. August 2005 Veröffentlicht 31.05.2001 Veröffentlicht 17.11.2003 Bulletins 594 Tage nach Produktveröffentlichung Bulletins seit TwC Einführung Service Pack 3 Bulletins in vorheriger Periode 27 IE 6.0 SP1 IE 6.0 SP2 5 8 16 3 Bulletins 868 Tage nach Produktveröffentlichung 6 11 64

33 Schlussgedanken … Jeder hat Security-Bugs Bug hunting funktioniert nicht Jeder muss seinen Prozess anpassen SDL zeigt erste Ergebnisse http://msdn.microsoft.com/security/sdl

34 Fragen und Antworten Vielen Dank! Sebastian Weber Sebastian.Weber@microsoft.com http://sebastianweber.org

35 Mehr Informationen http://msdn.microsoft.com/sdl http://codezone.de http://sebastianweber.org

36 Ihr Potenzial. Unser Antrieb.