1 / 37

SDL in an Agile World

SDL in an Agile World. MSSD-3 — третья по счету конференция, посвященная всестороннему обсуждению популярной и важной темы – минимизация уязвимостей программного обеспечения при его разработке. What does “Agile” mean, anyway?. What does “Agile” mean, anyway?. The Agile manifesto.

Download Presentation

SDL in an Agile World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SDL in an Agile World MSSD-3 — третья по счету конференция, посвященная всестороннему обсуждению популярной и важной темы – минимизация уязвимостей программного обеспечения при его разработке.

  2. What does “Agile” mean, anyway?

  3. What does “Agile” mean, anyway?

  4. The Agile manifesto

  5. Security Development Lifecycle Microsoft’s industry leading software security assurance process designed to protect customers by reducing the number and severity of software vulnerabilities before release. Process Accountability Education Ongoing Process Improvements

  6. Challenges

  7. Challenges of adapting SDL to Agile • Iterative nature of Agile • Projects may never end • Just-in-time planning/YAGNI mentality • Emphasis on project/iteration backlogs • General avoidance of automated tools

  8. SDL “Classic” phased approach • Fits spiral or waterfall… • …but Agile doesn’t have phases

  9. Idea: Do the full SDL every iteration • Very secure! • But not Agile.

  10. Short timescale • From the Principles Behind the Agile Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

  11. Idea: Move SDL tasks to product backlog • Very Agile! • But not secure.

  12. Idea: Drop some requirements • But every requirement is, well, required • We need to keep all requirements • We need to reorganize into Agile-friendly form

  13. SDL-Agile process

  14. SDL-Agile process

  15. Three classes of requirements

  16. Requirements as backlog items • One-time requirements get added to the Product Backlog (with deadlines) • So do bucket requirements • Every-sprint requirements go to the Sprint Backlog directly

  17. Agile “sashimi” All every-sprint requirements complete No bucket items more than six months old No expired one-time requirements No open security bugs

  18. Challenges of adapting SDL to Agile • Iterative nature of Agile • Projects may never end • Just-in-time planning/YAGNI mentality • Emphasis on project/iteration backlogs • General avoidance of automated tools

  19. Security incident response • 2:00 AM Christmas morning is a poor time to hold a Scrum meeting…

  20. Challenges of adapting SDL to Agile • Iterative nature of Agile • Projects may never end • Just-in-time planning/YAGNI mentality • Emphasis on project/iteration backlogs • General avoidance of automated tools

  21. Writing secure code • 10% Writing security features • Cryptography • Firewalls • Access ControlLists • 90% Writing secure features • Overflow defense • Input validation • Output encoding

  22. Secure code cannot be a "feature"

  23. Breaking the SDL into tasks • Some SDL requirements are straightforward... • Enable compiler switches • Run static analysis tools • …some are more difficult (not actionable) • Avoid banned APIs • Access databases safely

  24. Two options • Verify manually • Verify with tools

  25. Challenges of adapting SDL to Agile • Iterative nature of Agile • Projects may never end • Just-in-time planning/YAGNI mentality • Emphasis on project/iteration backlogs • General avoidance of automated tools

  26. Static analysis requirements • FxCop • CAT.NET • PREFast (/analyze) • And/or your alternative tool(s) of choice • These are “every-sprint” requirements • Better still: Continuous Integration

  27. Dynamic analysis requirements • Fuzzers (homegrown) • AppVerifier • Passive HTTP traffic analysis • And/or your alternative tool(s) of choice • These are “bucket” requirements • Or Continuous Integration

  28. Secure coding libraries • Web Protection Library (a.k.aAntiXss) • StrSafe • SafeInt • Use always, check every sprint

  29. Strengths

  30. Strengths of Agile in SDL • Bucket activities easily move in & out of sprints • Teams self-select best security activities • Each iteration is a gate

  31. Strengths of Agile in SDL • Bucket activities easily move in & out of sprints • Teams self-select best security activities • Each iteration is a gate “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

  32. Strengths of Agile in SDL • Bucket activities easily move in & out of sprints • Teams self-select best security activities • Each iteration is a gate “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

  33. Strengths of Agile in SDL • Bucket activities easily move in & out of sprints • Teams self-select best security activities • Each iteration is a gate “Security and privacy are most effective when ‘built-in’ throughout the entire development lifecycle”

  34. The Agile manifesto

  35. The SDL-Agile manifesto

  36. More resources • http://www.microsoft.com/sdl • http://blogs.msdn.com/b/sdl

  37. Thank youСпасибозавнимание

More Related