Pragmatic Trustworthy Computing Michael Howard mikehow microsoft com Senior

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

Agenda u u u Who is SWI? What is Tw. C? What we’re doing Ø Ø u Teaching critical skills Attack surface reduction Beyond Microsoft

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

Secure Windows Initiative People Train, and keep current, every developer, tester, and program manager in the specific techniques of building secure products. Process 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 Technology Build tools to automate everything possible in the quest to code the most secure products ØPre. FIX and Pre. FAST for defect detection ØUpdated as new vulnerabilities found ØVisual C++ compiler improvements

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)

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

Security Framework is Vital SD 3 + 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 Communications Protect, defend, recover, manage Process: How to’s, architecture guides People: Training Clear security commitment Full member of the security community Microsoft Security Response Center

Sampling of Progress To Date SD 3 + Communications Secure by Design Secure by Default Security training for MS engineers Improved process Security code reviews Threat modeling Office XP: Scripting off by default No sample code installed by default SQL/IIS off by default in VS. NET Secure in 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

Secure Product Development Timeline Secure questions during interviews Concept Security push/audit Threat analysis Learn & Refine External review Designs Complete Team member training Security Review Test plans Complete Data mutation & Least Priv Tests Code Complete Ship Post Ship Review old defects Check-ins checked Secure coding guidelines Use tools = on-going

Critical Skills Instilled u Designers & Architects Ø u Developers Ø u Threat modeling Input trust issues Testers Ø Data mutation (intelligent fuzz)

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

Threat Modeling Process u u Create model of app (DFD, UML etc) Categorize threats to each attack target node with STRIDE Ø u u 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

1. 2. 1 Parse Request STRIDE Threat (Goal) Threat Condition Threat Subthreat Condition DREAD

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

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

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

On the Subject of Buffer Overruns! u Issue is trusting the data is correct! u Don’t simply use the ‘secure’ ‘n’ versions Ø ie; u VC++ strncpy rather than strcpy . 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 Do. S 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! Ø

Security Testing: Data Mutation & Threat Models u A Problem: Too many “goody two shoes” testers Ø u 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

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

Mutate the data! u 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) u Length Long (Ll) Ø Small (Ls) Ø Zero Length (Lz) Ø u Container Name (On) Ø Link to other (Ol) Ø Exists (Oe) Ø Does not exist (Od) Ø No access (Oa) Ø Restricted Access (Or) Ø u Network Specific Replay (Nr) Ø Out-of-sync (No) Ø High volume (Nh) Ø

Data mutation example On. Hand. xml • No data (Cl: Lz) • Full of junk (Cr) • Filename too long (On: Cl: Ll) • Link to another file (Ol) • Deny access to file (Oa) • Lock file (Oa) 13. 50 20020903 Big Foo Thing . . . • Different version (Cs & Co) • Escaped (Cpe) • Junk (Cr) • No version (Cl: Lz)

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

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

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

Sample Windows Data Points u u u u u Open sockets Open RPC endpoints Open named pipes Services running by default Services running as SYSTEM Active Web handlers Active ISAPI Filters Dynamic Web pages Executable vdirs u Enabled Accounts in admin group u Null Sessions to pipes and shares u Guest account enabled u Weak ACLs in FS u Weak ACLs in Registry u Weak ACLs on shares

The Figures are interesting

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

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

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

Summary u u u Who is SWI? What is Tw. C? What we’re doing Ø Ø u Teaching critical skills Attack surface reduction Beyond Microsoft