Der Sicherheits- Entwicklungszyklus bei Microsoft Sebastian Weber

Der Sicherheits- Entwicklungszyklus bei Microsoft Sebastian Weber Technologieberater - Developer Platform & Strategy Group Microsoft Deutschland GmbH

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

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

Der Sicherheits-Entwicklungszyklus

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

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

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

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

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

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 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

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

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

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

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

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

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

Threat Modeling Tool

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

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

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

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

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

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

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

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

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

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

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

Ist TwC erfolgreich? Total # 2004Jan-Apr2005 Schätzung 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

Die TwC Realität Veröffentlicht Veröffentlicht Bulletins 653 Tage nach Produktveröffentlichung *Stand 31. August 2005 Veröffentlicht Veröffentlicht 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 SP Bulletins 868 Tage nach Produktveröffentlichung

Schlussgedanken … Jeder hat Security-Bugs Bug hunting funktioniert nicht Jeder muss seinen Prozess anpassen SDL zeigt erste Ergebnisse

Fragen und Antworten Vielen Dank! Sebastian Weber

Mehr Informationen

Ihr Potenzial. Unser Antrieb.