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

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

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

5. 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

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

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

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

9. SDL & Format & Value What is the SDL?
Process setup at Microsoft as a part of the TrustWorthy 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.

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

11. 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.

12. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

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

14. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

15. Education and Awareness SDL & WCF
All engineers have to take 2 discipline specific courses.
Recommendation:
Writing Secure Code 2nd 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”

16. Education and Awareness Customer
Developers love challenges. Give prizes for finding security bugs.
Send out s 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)

17. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

18. Requirement Phase SDL & WCF
Get a “SWI Buddy”
Establish point-of-contact
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.

19. 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

20. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

21. Design Phase SDL & WCF
V1 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)

22. 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 FxCop (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

23. (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

24. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

25. 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

26. 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.

27. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

28. 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

29. 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

30. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

31. Release Phase WCF & SDL CHECK!
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

32. 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.

33. Secure Development Lifecycle Overview
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

34. Post Release Phase SDL & WCF & customer
IT Pros deploy with S+D3
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.

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

36. Resources Secure Development Lifecycle IT Pros Secure Center
IT Pros Secure Center
Microsoft Secure Development Center
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

37. 4/21/2017 6:10 PM
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.