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

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

Спасибо за внимание