der sicherheits- entwicklungszyklus bei microsoft sebastian weber
TRANSCRIPT
Der Sicherheits-Entwicklungszyklus bei Microsoft
Sebastian Weber
Der Sicherheits-Entwicklungszyklus bei MicrosoftSebastian Weber
Technologieberater - Developer Platform & Strategy GroupMicrosoft Deutschland [email protected]
Development Best Practices (SD³+C)
Threat ModelingThreat ModelingCode inspectionCode inspectionProzess verbessernProzess verbessern
Nicht verwend. Features Nicht verwend. Features ausschaltenausschaltenAngriffsfläche reduzierenAngriffsfläche reduzierenLeast PrivilegeLeast PrivilegeAnleitung für den BetriebAnleitung für den BetriebSecurity Tools Security Tools Training und SchulungTraining und Schulung
Community EngagementCommunity EngagementTransparenzTransparenzKlare RichtlinienKlare Richtlinien
Der Sicherheits-Entwicklungszyklus
Ein Prozess mit dem Microsoft Softwareentwickelt, der Sicherheitsanforderungenund 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
DesignSpecifications
Development of New Code
Bug Fixes
Code Signing A Checkpoint
Express Signoff
RTM
Product SupportService Packs/QFEs Security
Updates
Requirements Design Implementation Verification ReleaseSupport
&Servicing
FunctionalSpecifications
Security Deployment Lifecycle Aufgaben und ProzesseSecurity Deployment Lifecycle Aufgaben und Prozesse
Traditionelle Microsoft Software Product Development Lifecycle Aufgaben und ProzesseTraditionelle Microsoft Software Product Development Lifecycle Aufgaben und Prozesse
Testing and VerificationFeature ListsQuality Guidelines
Arch DocsSchedules
Security Training
Security Kickoff& Register with
SWI
Security DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Ausbildung und TrainingRequirements- & 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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Attack Surface AnalysisDesign-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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Threat ModelingDesign-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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Threat ModelingDesign-Phase
Sicherheit ist oftmals ad-hoc
Threat Modeling identifiziert und bewertet Bedrohungen systematisch
Security Training
Security Kickoff& Register with
SWI
Security DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Threat Modeling – Der Prozess Design-Phase
Security Training
Security Kickoff& Register with
SWI
Security DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Threatsermitteln
Identifizieren
Assets
Entry Points
Trust Levels
Securityverstehen
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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Threat Modeling – ArchitekturDesign-Phase
Was macht die Anwendung? Use Cases, Data Flow Diagram (DFD)
Anwendungsarchitektur Technologien identifizieren
AliceMaryBob IISIIS
Trust Boundaries
ASP.NET(Process Identity)Microsoft
ASP.NETMicrosoft ASP.NET
MicrosoftSQL Server
Security Training
Security Kickoff& Register with
SWI
Security DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Threat Modeling Tool
Threat Modeling – MaßnahmenDesign-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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Tools – Visual Studio 2003Implementation-Phase
Keine Fehler, keine Warnungen!
Tools – Visual Studio 2005Implementation-Phase
Deprecated functions
Buffer OverrunMixed args
Security Response PlansVerification-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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Security PushVerification-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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Final Security ReviewRelease-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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Post-Bulletin ProcessSupport & 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 DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
For Product
PrepareSecurity
ResponsePlan
Security Push
Pen Testing
FinalSecurity Review
Security Servicing &ResponseExecution
ThreatModeling
Reaktion auf einen Zwischenfall
Neuer SicherheitsvorfallInformationen über neue/aktuelle Angriffe
IdentifikationIdentifikation
Interne Interessens-gruppenExterne Interessens-gruppen
Komm.-Komm.-PlanPlan Kommunikation
koordinerenKunden informieren und Anleitungen bereitstellenKundenprobleme beobachten
ReleaseRelease
Best Practices aktualisierenTest Tools anpassenDevelopment und Design Process anpassen
Nachbe-Nachbe-arbeitungarbeitung
Mehrere Test-Ebenen:
Setup und Build VerifikationCode-TiefeIntegration und UmfangKontrollierte Beta
TestingTesting
Abschätzung der möglichen AuswirkungTeam für den Fix identifizieren
SichtungSichtung
Code und Design fixenThreat Model anpassenFix für Test bereitstellen
Fix erstellenFix 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 Total ##
20042004
Jan-AprJan-Apr20052005
SchätzungSchätzung20052005
4545
2323
6969
Microsoft Security BulletinsMicrosoft 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öffentlichtVeröffentlicht29.11.200029.11.2000
VeröffentlichtVeröffentlicht28.09.200328.09.2003
2003
Bulletins 653 Tage nach Produktveröffentlichung
*Stand 31. August 2005
VeröffentlichtVeröffentlicht31.05.200131.05.2001
VeröffentlichtVeröffentlicht17.11.200317.11.2003
Bulletins 594 Tage nach Produktveröffentlichung
Bulletins seitBulletins seitTwC EinführungTwC Einführung
Service Pack 3
Bulletins inBulletins invorheriger vorheriger
PeriodePeriode
27
IE 6.0 SP1
IE 6.0 SP2
5588
1616
33
Bulletins 868 Tage nach Produktveröffentlichung
66
1111
64
Schlussgedanken …
Jeder hat Security-Bugs “Bug hunting” funktioniert nicht Jeder muss seinen Prozess anpassen SDL zeigt erste Ergebnisse http://msdn.microsoft.com/security/sdl
Mehr Informationen
http://msdn.microsoft.com/sdl http://codezone.de http://sebastianweber.org
Ihr Potenzial. Unser Antrieb.