Pragmatic Trustworthy Computing

1. Pragmatic Trustworthy Computing Michael Howard (mikehow@microsoft.com) Senior Program Manager Secure Windows Initiative Microsoft Corporation

2. Agenda • Who is SWI? • What is TwC? • What we’re doing • Teaching critical skills • Attack surface reduction • Beyond Microsoft

3. Who is SWI? • Secure Windows Initiative • Focus on securing Microsoft products • Little (read: zero) focus on security features nor network security • Security Features != Secure Features

4. Secure Windows Initiative Train, and keep current, every developer, tester, and program manager in the specific techniques of building secure products. People Make security a critical factor in design, coding and testing of every product Microsoft builds • Major changes to development process • Security Threat Analysis part of every design spec • Cross-group design & code reviews • Red Team testing and code reviews • Security bug feedback loop & code sign-off requirements • External reviews and testing by consultants and public Process Build tools to automate everything possible in the quest to code the most secure products • PreFIX and PreFAST for defect detection • Updated as new vulnerabilities found • Visual C++ compiler improvements Technology

5. Trustworthy Computing:What Is It? The key goal of Trustworthy Computing is to make computing so safe and reliable that people simply take it for granted—just as they take electricity and the telephone system for granted today. • A top priority for Microsoft—and a cultural shift we are totally committed to • A lengthy journey (at least a decade) • Needs the commitment of the entire computer industry (software, hardware, ISPs, etc)

6. Resilient to attack Protects confidentiality, integrity, availability and data Trustworthy ComputingCore Tenets Security • Individuals control personal data • Products and online services adhere to fair information principles Privacy • Dependable • Available when needed • Performs at expected levels Reliability Business Integrity • Vendors provide quality products • Product support is appropriate

7. Security Framework is Vital SD3 + Communications Secure by Design Secure architecture Improved process Reduce vulnerabilities in the code Secure by Default Reduce attack surface area Unused features off by default Only require minimum privilege Secure in Deployment Protect, detect, defend, recover, manage Process: How to’s, architecture guides People: Training Communications Clear security commitment Full member of the security community Microsoft Security Response Center

8. Sampling of Progress To Date SD3 + Communications Secure by Design Security training for MS engineers Improved process Security code reviews Threat modeling Secure by Default Office XP: Scripting off by default No sample code installed by default SQL/IIS off by default in VS.NET Secure in Deployment Deployment tools (MBSA, IIS Lockdown) Created STPP to respond to customers PAG for Windows 2000 Security Ops Communications Microsoft Security Response Center severity rating system MSDN security guidance for developers Organization for Internet Safety formed

9. Security push/audit = on-going Secure Product Development Timeline Threatanalysis Secure questionsduring interviews Learn & Refine External review Concept Designs Complete Test plansComplete Code Complete Ship Post Ship Team member training Review old defects Check-ins checked Secure coding guidelines Use tools Data mutation & Least Priv Tests SecurityReview

10. Critical Skills Instilled • Designers & Architects • Threat modeling • Developers • Input trust issues • Testers • Data mutation (intelligent fuzz)

11. Threat Models • You cannot build secure applications unless you understand threats • “We use SSL!” • Find different bugs than code review and testing • Implementation bugs vs higher-level design issues • Approx 50% of issues come from threat models

12. Threat Modeling Process • Create model of app (DFD, UML etc) • Categorize threats to each attack target node with STRIDE • Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege • Build threat tree • Rank threats with DREAD • Damage potential, Reproducibility, Exploitability, Affected Users, Discoverability

13. STRIDE Threat (Goal) STRIDE STRIDE Threat (Goal) Threat (Goal) Threat Threat Threat DREAD Condition Subthreat Condition Condition DREAD 1.2.1 Parse Request

14. Input Trust Issues • “All input is evil, until proven otherwise” • Good guys provide well-formed input, bad guys don’t! • Buffer overruns • Integer overflow attacks • SQL injection attacks • XSS attacks • Look for well-formed input, and reject everything else • Don’t look for ‘bad’ things

15. // Do not allow "FILE://" URLs if(url.ToUpper().Left(4) == "FILE") return ERROR; getStuff(url);  // Only allow "HTTP://" URLs if(url.ToUpper(CULTURE_INVARIANT).Left(4) == "HTTP") getStuff(url); else return ERROR;  The Turkish-I problem • Turkish has four ‘I’s • i (U+0069) ı (U+0131) İ (U+0130) I (U+0049) • In the Turkish locale FILE!=FİLE

16. Untrusted! These APIs are not ‘insecure’ A safe version using ‘insecure’ APIs void func(char *strName) { char buff[64]; if (isValid(strName)) { strcpy(buff,”My name is: “); strcat(buff,strName); } } Untrusted Trusted What’s wrong with this code? void func(char *strName) { char buff[64]; strcpy(buff,”My name is: “); strcat(buff,strName); }

17. On the Subject of Buffer Overruns! • Issue is trusting the data is correct! • Don’t simply use the ‘secure’ ‘n’ versions • ie; strncpy rather than strcpy • VC++ .NET adds the –GS flag • Mitigates some stack-smashing attacks • VS.NET: Function return address • VS.NET 2003: exception handlers, stack-based function pointers & data pointers • May lead to DoS rather than attack code execution • Most of Windows .NET Server compiled with -GS • On by default for new VS.NET C++ projects • Not a replacement for good code • Doesn’t fix code!

18. Security Testing: Data Mutation & Threat Models • A Problem: Too many “goody two shoes” testers • We need to teach people how to think ‘evil’ • The threat model can help drive the test process • Each threat should have at least two tests: Whitehat & Blackhat • STRIDE helps drive test techniques • DREAD helps drive priority

19. Decompose the app (threat model) Identify interfaces Enumerate input points Sockets Pipes Registry Files RPC (etc) Command-line args Etc. Enumerate data structures C/C++ struct data HTTP body HTTP headers HTTP header data Querystrings Bit flags Etc. Determine valid constructs Analytical Security Testing

20. Contents Length (Cl) Random (Cr) NULL (Cn) Zero (Cz) Wrong type (Cw) Wrong Sign (Cs) Out of Bounds (Co) Valid + Invalid (Cv) Special Chars (Cp) Script (Cps) HTML (Cph) Quotes (Cpq) Slashes (Cpl) Escaped chars (Cpe) Meta chars (Cpm) Length Long (Ll) Small (Ls) Zero Length (Lz) Container Name (On) Link to other (Ol) Exists (Oe) Does not exist (Od) No access (Oa) Restricted Access (Or) Network Specific Replay (Nr) Out-of-sync (No) High volume (Nh) Mutate the data!

21. Filename too long (On:Cl:Ll) • Link to another file (Ol) • Deny access to file (Oa) • Lock file (Oa) • No data (Cl:Lz) • Full of junk (Cr) • Escaped (Cpe) • Junk (Cr) • Different version (Cs & Co) • No version (Cl:Lz) Data mutation example OnHand.xml <?xml version="1.0" encoding=“utf-8"?> <items> <item name="Foo" readonly="true"> <cost>13.50</cost> <lastpurch>20020903</lastpurch> <fullname>Big Foo Thing</fullname> </item> ... </items>

22. Relative Attack Surface • Simple way of measuring potential for attack • Features are attacked  Security Bugs • Less Features == Less Security Bugs • Goal of a product should be to reduce attack surface • Lower priv • Turn features off • Defense in depth

23. Founded on past mistakes • Products have vulnerability points • Windows is attacked one way, Linux another, SQL Server yet another • Hard to compare non-similar products

24. The Process Old Vulns Determine Attack Vector(s) Apply Bias Σ RASQ Think of it as ‘Cyclomatic Complexity’ for Security!

25. 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 Sample Windows Data Points

26. The Figures are interesting

27. Using RASQ to build better products • Product A agrees on RASQ data points • Based on past exploits • SWI has buy in • v1 has RASQ = 350 • Goal for v2 is to reduce RASQ by at least 10% • Add as many features as you want • But do so while still reducing RASQ • Measurable!

28. Beyond Microsoft • Sharing new issues and education • Writing Secure Code 2nd Edition • “Code Secure” at msdn.microsoft.com • More whitepapers • Strsafe.h • SiteLock • Microsoft Official Curriculum • 2805a – Security Seminar for Developers • ISV training • Premier Partner Training

29. The Ultimate Goal • Not to inject security bugs into the code in the first place! • Short term: remove existing flaws • Longer term: don’t add them to the code • You can’t do this through code review • …or testing • Only remove existing flaws • You have to teach people to do the right things…!

30. Summary • Who is SWI? • What is TwC? • What we’re doing • Teaching critical skills • Attack surface reduction • Beyond Microsoft