1	Inside Microsoft’s Secure Windows Initiative Steve Lipner Director of Security Engineering Strategy Security Business Unit Microsoft Corporation
2	Agenda Who Am I? What is SWI? SD³ + c Secure Development Process Threat Models Relative Attack Surface Open Questions
3	Who is this guy? SLipner@microsoft.com Been at Microsoft for 3.5 years Always in security Started working in security in 1970 Experience includes A1 systems, firewalls, consulting, other stuff Pragmatic A chief conspirator!
4	What is SWI? Secure Windows Initiative Work across Microsoft Focus on securing products Security Features != Secure Features Two sub-groups Defensive SWI Offensive SWI
5	Building Software for People
6	Building Software for People
7	A Security Framework
8	SD³ At Work – MS03-007 Windows Server 2003 Unaffected
9	Secure Product Development Timeline
10	Threat Analysis You cannot build secure applications unless you understand threats Adding security features does not mean you have secure software “We use SSL!” Find issues before the code is created Find different bugs than code review and testing Implementation bugs vs higher-level design issues Approx 50% of issues come from threat models
11	Threat Modeling Process Create model of app (DFD, UML etc) Build a list of assets that require protection Categorize threats to each attack target node with STRIDE Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege Build threat tree for each threat Derived from hardware fault trees Rank threats by risk Risk = Potential * Damage DREAD: Damage potential, Reproducibility, Exploitability, Affected Users, Discoverability
12
13	Portion of DFD
14	Information Disclosure Threat to Payroll Data
15	Applying Risk (W.I.P.)
16	Applying Risk (W.I.P.) Using Risk = Chance*Damage
17	Designing to a Threat Model Threat types have mitigation techniques Spoofing Authentication (authn), good credential storage Tampering Authorization (authz), MAC, signing Repudiation Authn, Authz, signing, logging, trusted third party Info Disclosure Authz, encryption Denial of Service Filtering, Authn, Authz Elev of Priv Don’t run with elevated privs
18	Threat Mitigation Techniques & Technologies
19	Threat Mitigation
20	Coding to a Threat Model Threat models help you determine the most ‘dangerous’ portions of the application Prioritize security push efforts Prioritize on-going code reviews Help determine the defense mechanisms to use Determine data flow “All input is evil, until proven otherwise”
21	Testing to a Threat Model Testers have problems Most are not security testers (read: evil) What needs testing? How do you test? Each threat in the model must have a test plan The threat model helps drive testing concepts Allows for Whitehat and Blackhat testing Prove the mitigations work Prove they don’t work :-)
22	Testing to a Threat Model Mitigation techniques have blackhat testing techniques Spoofing Authentication Brute force creds, cred replay, downgrade to less secure authn, view creds on wire Good credential storage Use Information Disclosure attacks Tampering Authorization Attempt authz bypass MAC, signing Tamper and re-hash? Create invalid hash data Force app to use less secure protocol (no SSL)
23	Testing to a Threat Model Repudiation Authn & Authz See Spoofing and Tampering Signing See Tampering Logging Prevent auditing, spoof log entries (CR/LF) Trusted third party DoS the third party Info Disclosure NOTE: Is there any PII/sensitive data in the data? Authorization See Tampering Encryption View on-the-wire data Kill process and scavenge for sensitive data Failure leads to disclosure in error messages
24	Testing to a Threat Model Denial of Service Filtering Flooding, malformed data Authn & Authz See Spoofing and tampering Resource pressure Elev of Priv Don’t run with elevated privs Spend more time here!
25	Threat Modeling Notes Scenario-driven Note infrastructure mitigating techniques vs. application mitigating techniques Determine privilege to initiate data flow Helps determine chance of attack Be wary of unauthenticated data flows Attackers follow the path of least resistance All information disclosure threats are potentially privacy issues Any non-mitigated threat is a potential vulnerability All security features must mitigate one or more threats Work on the higher-risk items first
26	Relative Attack Surface Simple way of measuring potential for attack Goal of a product should be to reduce attack surface Lower privilege Turn features off Defense in depth Does not address code quality Hard to compare dissimilar products On-going work by Microsoft Research
27	The ‘Simple’ Process
28	Sample Windows Data Points Open sockets Open RPC endpoints Open named pipes Services Services running by default Services running as SYSTEM Active Web handlers Active ISAPI Filters Dynamic Web pages Executable vdirs Enabled Accounts Enabled Accounts in admin group Null Sessions to pipes and shares Guest account enabled Weak ACLs in FS Weak ACLs in Registry Weak ACLs on shares Scripting
29	Relative Attack Surface
30	Windows Server 2003 Reduced Attack Profile 20+ services off by default 20+ services run in lower privilege IIS6 off by default Minimal functionality by default All code runs in low privilege by default More restrictive ACLs throughout Internet Explorer is an “HTML 3.2” browser “.” directory no longer searched first No games installed UDDI Server written in C# All Active Directory traffic is signed/sealed SMB packet signing for Domain Controller traffic Defense in depth measures ‘safer’ string handling functions OS compiled with VC++ /GS flag Detects some kinds of stack-based buffer overruns at run time Impersonation privilege
31	Changing the Process: Our Ultimate Goal Not to inject security bugs into the code in the first place! Short term: remove existing flaws Longer term: don’t add flaws to the code You can’t do this through code review …or testing They only remove existing flaws You have to teach people to do the right things…! You must change the process!
32	The Turkish-İ problem (Applies also to Azerbaijan!) Turkish has four letter ‘I’s i (U+0069) I (U+0049) ı (U+0131) İ (U+0130) In Turkish locale UC("file")==FİLE
33	Summary Who Am I? What is SWI? SD³ + c Secure Development Process Threat Models Relative Attack Surface
34	How can you help? When is a threat model complete? How does privacy apply to TMs? A more complete taxonomy of mitigation techniques and technologies A more complete taxonomy of attack techniques Is Relative Attack Surface accurate? Is it worthwhile?
35
36	Backup Slides
37	DREAD Rankings Damage Potential Minor [1] → Complete Subversion [10] Reproducibility Rare [1] → Every Time [10] Exploitability NSA Only [1] → My Mom [10] Affected Users 10% [1] → 100% [10] Discoverability Very Subtle [1] → Already on Bugtraq [10]