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

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
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 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.
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
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”
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
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)
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
(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+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.
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, 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.