Microsoft Security Development
Lifecycle for IT
Rob Labbé
Security Engagement Manager
MSIT Infosec – ACE
roblab@microsoft.com
Microsoft IT Environment
94,000 Vista clients
48,000 Windows 7
clients
127,238 Office 2007
clients
129,000 Exchange 2007
mailboxes
359,000 SharePoint Sites
MSCRM deployment for
premier services
business
Dynamics business
running on Dynamics
products
5 data centers
9,700 production
servers
108,000 servers
(MSN)
98 countries
550 buildings
260,000+ SMS
managed
computers
585,000 devices
141,549 end users
2,400,000 internal
e-mails with
18,000,000 inbound
(97% filter rate)
36,000,000 IMs
per month
136,000+ e-mail
server accounts
137,000,000+
remote
connections
per month
Know Yourself, Know your
Enemies
“If you know your enemy and know
yourself, you need not fear the result of
a hundred battles. If you know yourself
but not the enemy, for every victory
gained you will also suffer a defeat. If
you know neither the enemy nor
yourself, you will succumb in every
battle.”
Sun Tzu, The Art of War
“Hacking Microsoft UK”
http://www.youtube.com/watch?v=tJSRnJkH2Ek
The Reasons for Secure Software
There are
many
threats to
data and
systems
• Data can be stolen by attackers
• Data can be corrupted by viruses
• Data can be lost or corrupted by
employees
• IT Systems can be used by attackers
• To send Spam, viruses, or launch
other attacks from
• IT Systems can be crashed by attackers
Application Layer = Weak Point
• Attackers target the weakest point. The OS
Layer and Network layer are too hard now
• On Average over 70% of IT security budget is
spent on Infrastructure, yet over 75% of attacks
happen at the Application level
• According to Microsoft research, only 1/3 of
developers are confident that they write secure
code
• The focus must be on hardening the
application layer
Reasons for IT Security
• Card Services - A Real World Example
• $10 Million a month in revenue
• Processed credit cards for American Express, Master
Card, and VISA
• They Lost 40 Million records to hacking
•
•
•
•
Government imposed heavy fines
Subject to audits every 6 months for 20 years
Amex, Master Card and Visa dropped them
A $10 Million a month company destroyed
Understanding The Attackers
Spy,
Terrorist
National Interest,
Chaos
Thief,
Booster,
Fence,
Classic Criminals
Steal Something
of Value / assets
Disgruntled
Employee
Personal Fame,
To Embarrass,
To Win
Curiosity
Nothing
Mal-Tech
Trespasser
Author
Vandal,
Cyberpun
k
Anyone
UnScriptintentional Kiddie
Hobbyist
Hacker
Expert
Specialist
Hackers are very smart
We need better security
Implement an SDL
• Implement an SDL to build security into
your development process
• Train your developers in secure coding
techniques
• Incorporate Threat Modeling, Secure Code
Review, Security Focused Testing into the
process
Purpose of the SDL
• Inventory and assess applications
• Identify and ensure resolution of
security/privacy vulnerabilities found in those
applications
• Enable Application Risk Management:
•
•
•
•
Strategic
Tactical
Operational
Legal
The SDL is NOT Optional
• At Microsoft all line-of-business
application teams must go through SDL-IT,
All shrink-wrapped products must go
through the SDL
• If they fail to do so, they cannot go into
production
• Enforcement of the SDL-IT process
attributes to it’s success
Visibly Measure the Process
• Have internally visible score cards
• Have contests to see if you can find bugs
and offer prizes
• Offer incentives to teams with the best
security records (no cheating!)
SDL aligns with SDLC
SDLC
SDL-IT
Envision
Design
Application
Entry / Risk
Assessment
Threat
Model /
Design
Review
Develop /
Purchase
Internal
Review
Test
Release /
Sustainment
PostPre-Production Production
Assessment
Assessment
Application Entry / Risk Assessment
App Entry
Internal Review
Threat Model /
Design Review
• Objective:
Post-Production
Assessment
Pre-Production
Assessment
• Application Inventory
• Determine Application Risk Categorization
• High Risk Security/Privacy Release
• Medium Risk Security/Privacy Release
• Low Risk Security/Privacy Release
Threat Model / Design Review
App Entry
Internal Review
Threat Model /
Design Review
• Objective:
•
•
•
Post-Production
Assessment
Pre-Production
Assessment
Threat modeling provides a consistent methodology for objectively evaluating threats to
applications.
Review application design to verify compliance with security standards and best practices
Verify application meets application principles
• Confidentiality
• Integrity
• Authentication
• Authorization
• Availability
• Non-repudiation
Internal Review
Internal Review
App Entry
Threat Model /
Design Review
Post-Production
Assessment
Pre-Production
Assessment
• Review security checklist/policy site
• Team conducts ‘self’ code review and attack and
penetration testing
Pre-Production Assessment
Internal Review
App Entry
Threat Model /
Design Review
• Objective:
• Low Risk Applications
•
Host Level Scan
• Windows
• IIS
• SQL
• High/Medium Risk Applications
•
•
Host Level Scan
White Box Code Review
Post-Production
Assessment
Pre-Production
Assessment
White Box Code Review
• Process
• Application team provides source code
• Analysts review application code
uncovering security vulnerabilities
• Vulnerabilities logged in bug database
• Application team required to address all
sev 1 bugs prior to going into
production
•
•
•
•
•
Some common attack patterns
white box review may reveal
Cross-Site Script Vulnerabilities
SQL Injection
Buffer Overflow
Poor Authorization Controls
Secrets Stored In Clear Text
Post-Production Assessment
Post-Production
App Entry
Internal Review
Threat Model /
Design Review
Assessment
Pre-Production
Assessment
• Objective:
• High/Medium/Low Risk Applications
• Host Level Scan
• Windows
• IIS
• SQL
Conclusion
• The need for security is obvious, we have to
protect the company and our customers
• To do that we need
• Management Support
• Secure Development Life Cycles
• Developers trained in secure development
• A Security First attitude!
Conclusions
• Continuous improvement of the process
• Invest time in upfront activities:
• Threat Modeling
• Design Reviews
• A holistic view
• People
• Process
• Tools
• It may seem hard to get started – ask for help!
People: Providing guidance on
secure application development
Process: Security
cannot be an
afterthought
Tools: Providing the
most innovative tools
Call To Action
• Implement a Secure Development Lifecycle
• Create more secure and reliable software
• Build Trust!
Resources
•
•
•
•
•
•
ACE Team Blog:
http://blogs.msdn.com/ace_team/default.aspx
Threat Modeling Tool
http://go.microsoft.com/fwlink?linkid=77002
Threat Modeling Blog:
http://blogs.msdn.com/threatmodeling/
© 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.