1. Steve Lipner Executive Director, SAFECode 16 May 2019
Lessons Learned About Building Secure Software: It’s About the Developers!
Steve Lipner Executive Director, SAFECode
16 May 2019

2. Overview Pre-history History of the SDL Things that made a difference
Lessons learned – what’s still the same in secure development after fifteen years and what’s changed

3. History: The 1990s Windows 3.1, NT
Smashing the Stack for Fun and Profit
Internet Exploder
Microsoft Security Response Team
Security Task Force
The Threats to Our Products (Kohnfelder and Garg)
Secure Windows Initiative (SWI)

4. History: 1999-2001 Microsoft Security Response Center
SWI Training and “bug bashes”
CorpNet Intrusion
Code Red
Nimda
UPnP

5. History 2001-early 2002
Howard Schmidt, Craig Mundie push for corporate commitment
Started after CorpNet intrusion
Meetings, s, briefings, demonstrations
Writing Secure Code
Trustworthy Computing
Initial reaction was skeptical
“Microsoft has this terrible product security problem and in response they’ve issued a press release” (John Pescatore, Gartner)

6. History Late 2001-early 2002 SWI/MSRC engineering PM team offsite
.Net Common Language Runtime stand- down
Let’s stop development…
“…they’ll just roll their eyes…”
Meetings – VP; SVP; GVP
Trained 8500 developers – each half day session introduced and attended by a Windows VP

7. History Winter 2002 Two month “Security Push”
Inventory of components to review/ sign off
Threat modeling (very immature)
Static analysis (centralized)
Modifying defaults/reducing attack surface
“Just fix it!”
SWI team (and partners) advised
Windows developers drove the process
Two months  six
Manual code reviews
Flaw hypothesis and penetration testing
Mitigations
Cash prizes

8. History Spring 2002-Fall 2003
Security push appeared to have been effective
Built a team
Training
Penetration testing
Replicated the Windows push for other products
More worms
Slammer
Blaster
XP SP2
Advising
“Security Science

9. History Winter-Spring 2004
“We aren’t there yet”
A mandatory process?
Briefed Ballmer and staff
“we’re not ever going to talk about it again”
Created SDL v2
Training
Technical content from security push
Final Security Review
Effective July 1, 2004

10. History SDL Overview Ongoing Process Improvements
Technology and Process
Education
Accountability
Ongoing Process Improvements

11. History After mid-2004 SWI Team supported SDL
SDL creation
Training
Tools
Advising
Penetration testing, more security science, mitigations
Verification – do the SDL – and can’t ship known vulnerabilities
Mandatory meant mandatory
Escalations
“I can tell you not to ship…”

12. History After mid-2004 Updated SDL every 6-12 months
Product group advice
MSRC cases
Tools and usability
Security science team found new bugs, mitigations
Scale, scale, scale
Online training
Tools!
Automated requirements applicability, execution tracking
Surprisingly little pushback!
I’m long gone from Microsoft, but the SDL lives!

13. Sample Product Team Feedback
Threat modeling aproach was too hard
New process, new tool
Some tools unusable
Fixed where we could
Occasionally said “suck it up”
Some tools unproductive
Deprecated where that made sense
Process doesn’t work for services
SDL for Agile/DevOps

14. Lessons Learned Developers want to do the right thing
Pride in company, product, and work
Demonstration that security matters
SDL is a product group activity advised by the SDL team
Build security in – not test when done
Only way to scale
Only way to ship secure code
When the product is done, the security is done
Product teams must buy credibility of SDL team and importance of security

15. Lessons Learned Continuous improvement
New classes of vulnerabilities are nature’s way of telling you to update SDL
Best case – discover them yourself and remove them first
Training is good but tools are (much!) better
People forget – code doesn’t
Integrate into development workflow
Report finds and fixes to bug tracking system
Overall – it’s worked
Customer reaction
Industry adoption/emulation
Free market price of a Windows 0-day

16. What’s Changed in Fifteen Years?
Diversity
Original SDL aimed at C, C++, C#
Big organization today might use languages
More work for SDL teams
Speed
Original SDL looked waterfall or spiral
Adapted well to Agile or DevOps
Bing/MSN team pushback
Integrate requirements with development (and tools)
Automate verification
Some requirements met post-release

17. What’s Changed Supply chain
Original SDL assumed Microsoft wrote everything (though we did have to contend with cross-team code reuse)
“Third party code” is the rule today – especially OSS
Someone had better be responsible
Have an inventory
Have a standard for acceptance and use
Have a detection system
Be prepared to respond

18. Summary SDL works because the developers write secure code
Product team buy-in is the critical factor
SDL team functions as advisors and facilitators, not inspectors or testers