Applying the Secure Development Lifecycle to the WCF

Applying the Secure Development Lifecycle to the WCF Maciej “Ski” Skierkowski Program Manager Microsoft Corporation

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

Abstract This talk will describe how the Windows Communication Foundation (Indigo) team applied the Trustworthy Computing Security Development Lifecycle to the WCF infrastructure. I’ll elaborate on the processes we followed for design reviews, threat modeling, and security testing. I’ll also describe how these processes (and lessons) can apply to securing your WCF applications

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

Motivation: Protect Assets Key Players Hackers (me at age 16) and “Script kiddies” Disgruntled employees Spammers for profit Assets Company reputation Personal Identifiable Information Financial Information

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

SDL & Format & Value What is the SDL? Process setup at Microsoft as a part of the Trust. Worthy Computing effort. Parallels standard software development lifecycle. Focus on threat modeling and testing against threat model Format: For each step of the process I will introduce the step, application to WCF, and how you can apply the process to your software. Value The SDL makes WCF secure. Apply SDL to your product.

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

Secure Development Lifecycle Overview Secure by Design: the software should be architected, designed, and implemented so as to protect itself and the information it processes, and to resist attacks. Secure by Default: in the real world, software will not achieve perfect security, so designers should assume that security flaws would be present. To minimize the harm that occurs when attackers target these remaining flaws, software's default state should promote security. For example, software should run with the least necessary privilege, and services and features that are not widely needed should be disabled by default or accessible only to a small population of users. Secure in Deployment: Tools and guidance should accompany software to help end users and/or administrators use it securely. Additionally, updates should be easy to deploy.

Secure Development Lifecycle Overview

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

Secure Development Lifecycle Overview

Education and Awareness SDL & WCF All engineers have to take 2 discipline specific courses. Recommendation: Writing Secure Code 2 nd Edition Threat Modeling Keep tabs on everyone's training experience. Everyone has a copy of the “Threat Modeling” and “Writing Secure Code” During Security Push sent “security bug of the day”

Education and Awareness Customer Developers love challenges. Give prizes for finding security bugs. Send out emails about funny, brilliant, or just pathetic security bugs. Provide knowledge (e. g. books, training) Security questions also make good developer interview questions. (skills: think outside the box, creative solutions, and design)

Secure Development Lifecycle Overview

Requirement Phase SDL & WCF Get a “SWI Buddy” Establish point-ofcontact Configure tools for tracking security information Effect: STRIDE Cause: Buffer Overflow, Script Injection, Race Condition, ETC. Define Security Bug Bar SWI Buddy for each Windows division Secure WCF driving team. Track Effect, cause AND threat model information Each milestone has a security bug bar.

Requirement Phase Customer Security “Go-To” person!!. For all development processes (bug tracking, documentation, etc) include security information. Keep track of everything security related. (bug/work item tracking, security news, status against security bar, share general findings, etc). Track threat models through phases (Discovery, mitigation, implementation) Design changes are captured by process

Secure Development Lifecycle Overview

Design Phase SDL & WCF V 1 software and major re-architectures should undergo a SWI review Crypto design requirements All design documents should include security impact Configure tools Firewall exceptions Crypto Encrypted by default Undergone weak crypto review Crypto agile Docs Threat Model Doc & Bugs Attack Surface Security Design Don’t store/transfer PII if not absolutely needed, and if needed pay extra attention to security (ACL logs)

Design Phase Customer Security Go-To person should work closely with Architect. Design with security in mind from the start. Are you using strong enough crypto? If custom crypto is needed undergo extra scrutiny (e. g. what if vulnerability is discovered) Include security impact section in design and functional specs. Ask many questions. (consider threats from similar designed systems). Use Fx. Cop (pre 2005) or Visual Studio Code Analysis (2005). Link with work-item tracking system. Don’t store/transfer any information that is not needed. IT Pros should provide information on medium. (e. g. firewalls, network bottlenecks, etc) THREAT MODELS!! This is your roadmap to security

(side-note) Threat Modeling 1. Data-Flow-Diagram (DFD) 2. Attacks (STRIDE) Spoofing Tempering Repudiation Information Disclosure Denial of Service Elevation of Privilege 3. DFD and STRIDE Categories

Secure Development Lifecycle Overview

Implementation Phase SDL & WCF Dev, PM, and UE managers meet to discuss what information is required by customers to use product securely. UE creates plan for authoring customer facing security documents. Build and Code Analysis tools Prohibit use of Bad APIs Help files, samples, whitepapers, etc, on developing secure code Numerous build and code analysis tools Fuzzing Static analysis tools

Implementation Phase Customer Visual Studio 2005 comes with code analysis tools in build process. Fuzzing products available Use documentation to be secure, help your customers be secure, and help their customers be secure. Avoid reliance on historically insecure APIs IT Pros make sure that developers provide information on deploying securily.

Secure Development Lifecycle Overview

Verification Phase SDL & WCF File, Wire, RPC Fuzzing Security test plan Penetration testing Update security documents Re-evaluate attack surface. Code review for at-risk components Focus entire team Security push 3 weeks, 200+ people All documents updated All “punted” bugs reevaluated for security impact Code reviews End-to-end threat analysis A whole lot more External vendor conducted black and white hat testing

Verification Phase Customer This is not an overhaul; everything should already be secure Run all tools and security procedures Look at product from attackers perspective. Do an end-to-end analysis of the product

Secure Development Lifecycle Overview

Release Phase WCF & SDL Final Security Review Is Pen testing needed? Bug Scrub Checklist Release planning Publicly defined support policy Go-to person for security issues Identify resources All code must have identified owner Giblet dependents Release Sign-Off on response plan, documentation, FSR CHECK! Code accountability was part of Security Push. Release planning under development

Release Phase Customer Check off that everything is done. Public support policy Identify go-to person, and resources Accountability! Code owners Code that you use but didn’t author.

Secure Development Lifecycle Overview

Post Release Phase SDL & WCF & customer IT Pros deploy with S+D 3 If a vulnerability is found, is the software configured to detect origin and prevent How will attacks be detected. Initiate execute of securing software after vulnerability is detected. Work with customers.

Agenda Introduction Abstract Motivation What is the SDL? Format Value Proposition Secure Development Lifecycle Overview SDL Stages SDL & WCF Implementation Customer Impact Q&A

Resources Secure Development Lifecycle http: //msdn. microsoft. com/security/default. aspx? pull=/library/enus/dnsecure/html/sdl. asp IT Pros Secure Center http: //www. microsoft. com/technet/security/default. mspx Microsoft Secure Development Center http: //msdn. microsoft. com/security/

© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U. S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.