Security

1. Security Doug Bayer Director, Windows Security Jon Pincus Architect, PPRC, Microsoft Research

2. Security Engineering in Windows Doug Bayer Director, Windows Security dbayer@microsoft.com

3. Engineering for SecurityTimeline • Windows 2000 – 1998 to Jan 2000 • Windows Penetration Team • Prefix, fix all security bugs • Engineering for Reliability SWI (1st rev) • External validation – www.windows2000test.com • Windows XP - January 2000 – August 2001 • SWI (second rev) • Design & code review on product by product basis (1/00 – 1/01) • Project wide bug bashes (2500 people trained in 9 months) (1/2001 – 8/2001) • Tools – PreFix/PreFast/VC 7 • Code Red & Nimda - Sept 2001 • Emergence of “Get Secure/Stay Secure” program • VS .net Security Push 1 – December 2001

4. Timeline (cont.) • Windows Security Push - Feb 2002 – March 2002 • Mobilized all contributors: 5000 Windows + 3000 “partners” • All feature development stopped • Mandatory Security training • Focus on design & code vulnerabilities, attack surface reduction, and secure defaults • Threat modeling, • Code reviews, • PreFAST+ custom tools, and • penetration testing • Individual signoff for code security review, security testing, threat model • Since April • Security Pushes: Office, Visual Studio, and Enterprise Servers • Patch management: Windows Software Update Service released • Configuration reporting: Microsoft Baseline Security Analyzer released

5. Challenge: Incorporating Security into the Development Process • Education – lack of security awareness across engineering community • What is a security design defect? • What is a security implementation defect? • How do you test? • Limited tool and programming language support • What is the priority/severity of a security bug? • When are we done? • What are metrics for success?

6. Design and Implementation Defects • Code – criteria from Howard-LeBlanc book • Buffer overruns • Canonicalization • Parameter validation • Data protection • Residues • Asynchronous attacks (TOCTOU) • DACLs • Stored secrets • Crypto • Least privilege • Cross site scripting • Sample code!

7. What is a Security Bug? STRIDE model • Spoofing identity • attacker obtains something that enables authentication procedure replay • Tampering with data (integrity) • unauthorized change made to stored or in-transit information or injecting a packet in communication. • Reputability • performing an illegal operation in a system that lacks the ability to trace such operations. • Information disclosure • exposing critical information to unauthorized individuals • Denial of service  (DoS) • carried out to deny service to valid users • Local/Remote DoS threats; distributed DoS (DDoS) • Elevation of privilege • Attacker is able to exploit weakness to gain greater privileges on a system than were intended.

8. Triaging Security Bugsthe DREAD model • Damage Potential How great can the damage be? • Reproducibility How easy is it to get the attack to work against users? • Exploitability How easy is it to attack based on this vulnerability? • Affected users How many users are affected? • Discoverability   How easy is it to find?

9. Lessons Learned • Security features != Secure features • Security technology is important … but so is understanding how to create secure solutions • Threat modeling is critical • Understand which techniques mitigate threats • Should be applied as part of all feature definition • Secure coding practices • “Secure out of box” over features • Reduce “attack surface” • Security configuration and patch mgmt is critical

10. Call to Action • Expand CS curriculum to include principles for creating secure solutions • Security aware specifications: Threat modeling • Secure design: • “Attack aware”: What is a buffer overrun? How is it exploited? • Input checking and internal “security boundaries” • Proper secret management • “Least privilege”- based design • Design in logging and auditing • Building attack testing into testing strategies • Expand research programs • Define ways to measure system “secure-ness” • Behavior-based hostile code detection and recovery • Tools for detecting insecure constructs • Strategies for isolating and quickly restoring compromised systems

11. Tools and Challenges Jon Pincus PPRC Microsoft Research jpincus@microsoft.com

12. Agenda • Tools and the security push • Successful defect detection tools • Challenges

13. Programmer Productivity Research Center (PPRC) Investigate new approaches to help MS product teams deliver high performing and reliable products Approach: • Enable rapid research and tool development

14. Rapid Research and Tool Development TOOLS BBCOVER SLEUTH INJECTOR TOOLS BBT IceCAP LOP TOOLS PREfix PREfast TOOLS ECHELON BLENDER Higher Abstraction Infrastructure Technologies Scalable Program Analysis (SPA), Binary Matching (BMAT) Infrastructure Technologies Source Code Analysis (AST), Binary Modification (VULCAN) … using common infrastructures

15. Tools and the security push • Key approach: Consider tools throughout the process, beginning in the planning phase • Where will tools help? • How to better leverage existing tools and technologies? • How to improve tools? • Where won’t tools currently help? • What other approaches to use? • Longer-term, how can tools help?

16. How can tools help? • Make engineers more efficient • Ability to (personally) do more • Increase knowledge about “what’s right” • Transmit knowledge • Improve processes • Identify problem areas • Show relative scale of problems • Provide a common “vocabulary” • Create a positive feedback cycle

17. Security push tools activities • PREfix/PREfast defect detection tools • Usage was already broad; it’s now 100% • “Zero-tolerance” for some kinds of warnings • Extensions to focus on security defects • Annotations for improved checking • Vulcan-based defect detection tools • Toolkit allows Windows engineers to do some static analysis of binaries • Prototype PREview code review assistant • Uses ESP static analysis, PREfix, PREfast, Vulcan, kitchen sink, …

18. Agenda • Tools and the security push • Successful defect detection tools • Challenges

19. Successful tools … • Provide quick and obvious pay-back • Focus on organization’s key problems • Minimize up-front time investment • People need to believe before they put in too much effort • Allow for extensibility • “virtuous circle” effect • Must be vigorously evangelized • … which means listening, not just talking!

20. PREfix and PREfast • Both tools analyze C/C++ source code, identify and present candidate defects • PREfix: heavyweight • Inter-procedural, cross-executable • Targeted at nightly/weekly builds • PREfast: lightweight • Intra-procedural, single-file • Targeted at developer pre-check in usage • “Easily” extensible (in C++)

21. Original focus: reliability • “Typical C/C++ defects” • NULL pointer dereferences • Uninitialized memory • Memory leaks • Starting in 2000, we began to focus on security-related problems • Buffer overruns • “Tainted” data • API usage problems

22. Typical scenario: IIS • Team includes security PM, IIS dev leads, Windows penetration team, PPRC engineers • Requirements gathering: examine all field-reported IIS buffer overruns • Categorize: which are detectable? • Prototype: for a couple engineers • Identifies missed defects! • Refines requirements, usability • Refine … and roll into “release” • Deploy – company wide

23. Successful tools … • Provide quick and obvious pay-back • Focus on organization’s key problems • Minimize up-front time investment • People need to believe before they put in too much effort • Allow for extensibility • “virtuous circle” effect • Must be vigorously evangelized • … which means listening, not just talking!

24. Agenda • Tools and the security push • Successful defect detection tools • Challenges

25. Specification Write Code Test Compile/Build Customer PPRC and Defect Prevention • Provide higher programming models for expressing programs • Permits programmers to express ideas clearly and succinctly Programming Language Design • Have program specification in program readable form • Validate code against partial specification • Verify early in the development process Program Specification

26. Tools Challenges • Can we guarantee absence of defects? • Three-way tension: completeness, noise-avoidance, and scalability • SLAM, ESP are currently investigating two points on this spectrum • Lesson from Java/C#: there’s huge value in removing a particular class of defect • Are other defects amenable to tools? • Script injection? (cross-language) • Incorrect permissions? • …

27. Language/Tools Challenges • We’re hitting the limits of what we can do without “specifications” • Good news: programmers now see the benefits of providing this information • They’ll do it … • … if it’s easy enough • Much work in this area (ASML, Alloy, Z, SLIC, OPAL, LCLint, “spec strings”, ...) • How to combine and make it easy?

28. Language/Tools Challenges • We’re hitting the limits of what we can do without “programmer input” • Good news: programmers now see the benefits of providing this information • They’ll do it … • … if it’s easy enough • Much work in this area (ASML, Alloy, Z, SLAM, ESP, LCLint, “spec strings”, ...) • How to combine and make it easy? • Whatever we do, we won’t call it specification!

29. Modeling Challenges • How to model system security properties? • Scale to real systems • Composability is a key! • How to detect violations of the properties? • Probably a mix of static analysis and dynamic checking • What to do if property violated? • Also: modeling privacy, attack models

30. Measurement Challenges • What measurements are useful? • Metrics we use at MS are pretty standard (incoming bug rate, code size, complexity, API size, …) • They’re useful for some purposes – but not particularly useful for security • What would be more meaningful? • Today, it feels like we as an industry measure what we can – and hope it means something

31. Architectural Challenges • “Why can’t we use all these extra MIPS to help with security?” • How to mitigate compromises? • “Principle of least privilege” only goes so far … • Ideal: isolation of compromised subsystems • And just how do you detect them? • Toggle system to “safe mode”?