Microsoft SDL in practice

Paying attention to security during application development is a must. Yet, often we find that security didn’t get the attention it should have had. One of the ways to force yourself to “think and act security” is to embed security in your development process. The Microsoft Security Development Lifecycle (SDL) is a platform-agnostic approach for applying security during the various stages of your development process. In this session you will get an overview of the Microsoft SDL and how it fits in “traditional” and agile projects.
But, with just an approach you are not done. This session will also show the hurdles that Achmea encountered during the implementation of an SDL, and what should be done to make an SDL successful. You will get to see the lesson learned from the Microsoft Competence Centre at Achmea IT.

Alex Thissen is a principal architect at Achmea and concentrates on integration-architecture and security. You can meet hem at various conferences and seminars where he will share his experiences from the field. He likes just about everything related to Microsoft products and technologies, but tries to focus on building secure web-applications in distributed enterprise environments.

Transcript

1. The OWASP Foundation http://www.owasp.org Microsoft SDL in practice Alex Thissen Principal Architect, Achmea alex.thissen@achmea.nl @alexthissen
2. Alex Thissen  Architect with a focus on Microsoft technologies and products • Security • Competencies  Trainer/coach in software development  Regional Director for The Netherlands  Most Valuable Professional for Visual C#
3. Agenda • Overview of Microsoft SDL • Phases of SDL • Implementing SDL at Achmea • Lessons learned • Questions and answers |3
4. Think security • Force yourself to pay attention to security during application development • Security is often first victim 4
5. • Embedding security into software and culture • Platform agnostic approach  Proven benefits • Microsoft internal adoption  Extensive experience with security  Trustworthy computing 5
6. SDL optimization model
7. Achmea SDL optimization Start Goal
8. Phases of Simplified SDL 8
9. Combining SDL and agile • Requirements defined by frequency, not phase • Every-Sprint (most critical) • One-Time (non-repeating) • Bucket (all others) 9
10. Embedding SDL in process • Guidance for process changes • Process template for Visual Studio ALM integration  SDL  MSF Agile with SDL
11. IMPLEMENTING SDL AT ACHMEA 11
12. Focus at Achmea • Emphasis on implementation at MScc  Line-of-business apps  Web portals • Part of chain: bigger scope • Embed SDL into “existing” development process  Sync with quality gates 12
13. Deliverables SDL for Achmea
14. Training • Online assessment and awareness course • Security expert training • Roadshow for all MScc employees • Focus on different phases in SDL for different roles 14
15. Requirements • Business Impact Analysis (BIA) • Determines CIA rating • Weighs in on initial Architecture design and documentation 15
16. Design • Combined Attack Surface Analysis and Threat model • Change design to reduce surface • Threat models as part of architecture • Use SDL Threat Modeling Tool • Determine risks from STRIDE • Part of security view of SAD 16
17. Implementation • Adopted Patterns & Practices guidance  Best practices  Guidelines and checklists  Tooling • Included CAT.NET in build • Watcher 17
18. Verification • BTOcc testplan adopted from OWASP  Testing for OWASP Top 10  ASVS testing  Dynamic, static and manual penetration testing • Code reviews 18
19. Release • Final Security Review (FSR)  Check on deliverables of previous phases • Approval by Design Authority • Ultimate quality gate 19
20. Response plan • Incident response part of other departments  IT Operations (IDS, monitoring)  Security departments • Close loop by applying lessons learned 20
21. LESSONS LEARNED 21
22. Taking hurdles • Security as a hurdle  “False positives” • Break perception  “Security takes time, budget and in not cool” • Missing or sub-optimal tooling 22
23. Visibility • Make sure you have security experts  Advocating security  People to ask questions • Pick people that like it • Find management that demands it 23
24. Achievable goals • Small steps • Not all at once • Prioritize and pick from top 3 24
25. Continuous metrics • Include security metrics in build • Tooling is essential • Testing only at end leads to disaster 25
26. Business and management • Buy-in from management is essential • Awareness at business is critical • Don’t end in a showdown with business 26
27. Ongoing training • Training alone is not enough • Offer help on-the-job • Not just before but during project as well • Fast-moving field of security, attacks, vulnerabilities 27
28. Responsibility • Define clear roles  Who does what? • Sharing responsibility 28
29. WRAPPING UP 29
30. Summary • Embed security in your process • It’s not easy • Microsoft SDL turned out to be a good choice • OWASP initiatives helped a lot • You’re never done 30
31. Questions and Answers & A 31
32. 32 Security Trained? Complete Core Training Tools ID’d? Response Plan? Document emergency response procedures Specify compilers, tools, flags & options Unsafe APIs? Final Security Review? Review all security & privacy activities Ban bad functions & APIs Static Analysis? Release Archive? Archive all pertinent technical data Perform periodic static code analysis Design Reqs? Perform all subtasks Security Consult advisors for review Privacy Consult advisors for review Crypto Consult advisors for review Attack Surface? Layered defenses & least privilege Threat Models? Assess threats using STRIDE Dynamic Analysis? Conduct runtime verification tests Fuzz Tests? Fuzz all program interfaces TM/ASR Review? Validate models against code complete project Pen Tests? (Option) Deliberate attack testing on critical components END Experts ID’d? Assign advisors & team leads Min Reqs? Define minimum security criteria Bug Track? Specify bug/work tracking tool Quality Gates? Specify quality gates & bug bars Assessed Risk? Use SRA/ PRA to codify risk Sec/Priv Reqs? Perform all subtasks Yes No No No No No No No No No Yes No No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No Yes Yes Training Requirements Design Implementation Verification Release Response No