sdl in an agile world mssd-3 третья по счету конференция,...
TRANSCRIPT
SDL in an Agile World
MSSD-3 — третья по счету конференция, посвященная всестороннему обсуждению популярной и важной темы – минимизация уязвимостей программного обеспечения при его разработке.
What does “Agile” mean, anyway?
What does “Agile” mean, anyway?
The Agile manifesto
• Individuals and interactions
• Processes and tools
• Working software • Comprehensive documentation
• Customer collaboration
• Contract negotiation
• Responding to change
• Following a plan
Security Development Lifecycle
Ongoing Process Improvements
ProcessEducation
Accountability
Microsoft’s industry leading software security assurance process designed to protect customers by reducing the number and severity of software vulnerabilities before
release.
Challenges
• Iterative nature of Agile• Projects may never end• Just-in-time planning/YAGNI mentality• Emphasis on project/iteration backlogs• General avoidance of automated tools
Challenges of adapting SDL to Agile
• Fits spiral or waterfall…• …but Agile doesn’t have phases
SDL “Classic” phased approach
• Very secure!• But not Agile.
Idea: Do the full SDL every iteration
• From the Principles Behind the Agile Manifesto:
Short timescale
“Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.”
• Very Agile!• But not secure.
Idea: Move SDL tasks to product backlog
• But every requirement is, well, required
• We need to keep all requirements• We need to reorganize into Agile-friendly form
Idea: Drop some requirements
SDL-Agile process
SDL-Agile process
Three classes of requirements
Every Sprint
Training
Threat modeling
etc...
One-Time Only
Set up tracking
Create response
plan
etc...
Bucket
Fuzz parsers
Refresh response
plan
etc…
• One-time requirements get added to the Product Backlog (with deadlines)
• So do bucket requirements
• Every-sprint requirements go to the Sprint Backlog directly
Requirements as backlog items
Product Backlog• Set up tracking system• Upgrade to VS2012• Fuzz image parser• Fuzz network parser• …
Sprint Backlog• Threat model new stored
procedures• Run static analysis• …
Agile “sashimi”
• All every-sprint requirements complete
• No bucket items more than six months old
• No expired one-time requirements
• No open security bugs
• Iterative nature of Agile• Projects may never end• Just-in-time planning/YAGNI mentality• Emphasis on project/iteration backlogs• General avoidance of automated tools
Challenges of adapting SDL to Agile
• 2:00 AM Christmas morning is a poor time to hold a Scrum meeting…
Security incident response
• Iterative nature of Agile• Projects may never end• Just-in-time planning/YAGNI mentality• Emphasis on project/iteration backlogs• General avoidance of automated tools
Challenges of adapting SDL to Agile
Writing secure code
• 90% Writing secure features• Overflow defense• Input validation• Output encoding
• 10% Writing security features• Cryptography• Firewalls• Access Control
Lists
Secure code cannot be a "feature"
Not a “User Story”
Doesn’t go in the Product
Backlog
Can’t get prioritized in or
out
Can’t decide to not do security
this sprint
• Some SDL requirements are straightforward...– Enable compiler switches– Run static analysis tools
• …some are more difficult (not actionable)– Avoid banned APIs– Access databases safely
Breaking the SDL into tasks
Two options
• Verify manually • Verify with tools
• Iterative nature of Agile• Projects may never end• Just-in-time planning/YAGNI mentality• Emphasis on project/iteration backlogs• General avoidance of automated tools
Challenges of adapting SDL to Agile
• FxCop• CAT.NET• PREFast (/analyze)• And/or your alternative tool(s) of choice
• These are “every-sprint” requirements• Better still: Continuous Integration
Static analysis requirements
• Fuzzers (homegrown)• AppVerifier• Passive HTTP traffic analysis• And/or your alternative tool(s) of choice
• These are “bucket” requirements• Or Continuous Integration
Dynamic analysis requirements
• Web Protection Library (a.k.a AntiXss)• StrSafe• SafeInt
• Use always, check every sprint
Secure coding libraries
Strengths
• Bucket activities easily move in & out of sprints
• Teams self-select best security activities• Each iteration is a gate
Strengths of Agile in SDL
• Bucket activities easily move in & out of sprints
• Teams self-select best security activities• Each iteration is a gate
Strengths of Agile in SDL
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s
competitive advantage.”
• Bucket activities easily move in & out of sprints
• Teams self-select best security activities• Each iteration is a gate
Strengths of Agile in SDL
“At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.”
• Bucket activities easily move in & out of sprints
• Teams self-select best security activities• Each iteration is a gate
Strengths of Agile in SDL
“Security and privacy are most effective when ‘built-in’ throughout the entire
development lifecycle”
The Agile manifesto
• Individuals and interactions
• Processes and tools
• Working software • Comprehensive documentation
• Customer collaboration
• Contract negotiation
• Responding to change
• Following a plan
The SDL-Agile manifesto
• Continuous, incremental effort
• Heroic pushes
• Automated tools • Manual processes
• Planned response • Ad-hoc response
• http://www.microsoft.com/sdl• http://blogs.msdn.com/b/sdl
More resources
Thank you
Спасибо за внимание