agile and secure: can we be both?can we be both? · definition of secure a secure productis one...

Agile and Secure:Can We Be Both?Can We Be Both?

Dan Cornell, OWASP San Antonio LeaderPrincipal, Denim Group Ltd.dan@denimgroup.com

OWASPAppSecS ttl

g p(210) 572-4400

Copyright © 2006 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this license, visit http://creativecommons.org/licenses/by-sa/2.5/

SeattleOct 2006

The OWASP Foundationhttp://www.owasp.org/

The Agile Practitioner’s Dilemma

Agile Forces:More responsive to

Secure Forces:More aggressive p

business concernsgg

regulatory environment

Increasing the frequency of stable releases

Increasing focus on need for security

Decreasing the

y

Traditional time it takes to deploy new features

approaches are top-down, document centric

OWASP AppSec Seattle 2006 2

features document centric

Objectives

Background

Goals of Agile Methods

Goals of Secure Development Lifecycle (SDL)

Review the Momentum of Agile MethodsReview the Momentum of Agile Methods

Look at An Integrated Process

Challenges & Compromises

OWASP AppSec Seattle 2006 3

Background

Dan CornellP i i l f D i G LtdPrincipal of Denim Group, Ltd.MCSD, Java 2 Certified Programmer

Challenges facing our own agile teamsDeliver projects in an economically-responsible mannerUphold security goalsUphold security goals

OWASP AppSec Seattle 2006 4

Notable Agile Methods

eXtreme Programming (XP)F t D i D l t (FDD)Feature Driven Development (FDD)SCRUMMSF for Agile Software DevelopmentAgile Unified Process (AUP)Crystal ClearDynamic Systems Development Method (DSDM)

OWASP AppSec Seattle 2006 5

Manifesto for Agile Software Development

Individuals and interactions over processes and tools

Working software over comprehensive documentation

C stome collabo ation o e cont act negotiationCustomer collaboration over contract negotiation

Responding to change over following a planResponding to change over following a plan

Source: http://www.agilemanifesto.org/

OWASP AppSec Seattle 2006 6

Agile’s Core Values

Communication

Simplicityp y

Feedback

CourageCourage

OWASP AppSec Seattle 2006 7

Principles of Agile Development

Rapid Feedback • The system is appropriate for the intended audience

Simple Design

the intended audience.

• The code passes all the tests.

Incremental Change• The code communicates everything it needs to.

Embracing Change

• The code has the smallest number of classes and methods.

Quality Work

OWASP AppSec Seattle 2006 8

Agile Practices

The Planning Game• Customer: scope, priorities and release dates

• Developer: estimates

The Driving Metaphor

• Developer: estimates, consequences and detailed scheduling

Shared Vision

On-Site Customer • Development iterations or cycles that last 1-4 weeks.

Small Releases • Release iterations as soon as possible (weekly, monthly, quarterly).

OWASP AppSec Seattle 2006 9

More Agile Practices

Collective OwnershipCollective Ownership

Test Driven

Continuous IntegrationContinuous Integration

Coding StandardsCod g Sta da ds

Pair Programming

OWASP AppSec Seattle 2006 10

Pair Programming

Definition of Secure

A secure product is one that protects the confidentiality, integrity, and availability of the customers’ information, and the integrity and availability of processing resources under control y p gof the system’s owner or administrator.

-- Source: Writing Secure Code (Microsoft.com)

OWASP AppSec Seattle 2006 11

A Secure Development Process…

Strives To Be A Repeatable Process

Requires Team Member Education

Tracks Metrics and Maintains Accountability

Sources:“Writing Secure Code” 2nd Ed., Howard & LeBlanc

“The Trustworthy Computing Security Development Lifecycle”by Lipner & Howard

OWASP AppSec Seattle 2006 12

Secure Development Principles

SD3: Secure by Design, Secure by Default, and in Deploymentin DeploymentLearn From MistakesMi i i Y Att k S fMinimize Your Attack SurfaceAssume External Systems Are InsecurePl O F ilPlan On Failure Never Depend on Security Through Obscurity

AlAloneFix Security Issues Correctly

OWASP AppSec Seattle 2006 13

Secure Development Practices

Education, Education, Education

Threat Modeling

Secure Coding Techniques

Security Testing

Security Code Reviews

OWASP AppSec Seattle 2006 14

Microsoft’s Secure Development Lifecycle (SDL)

Requirements DesignDesignImplementationVerificationRelease(Waterfall!)

OWASP AppSec Seattle 2006 15

Observations of the SDL in Practice

Threat Modeling is the Highest-Priority ComponentComponentPenetration Testing Alone is Not the AnswerT l Sh ld b C l tTools Should be Complementary

OWASP AppSec Seattle 2006 16

Threat Modeling

STRIDE – classify threatsSpoofing Identityp g yTampering with DataRepudiationInformation DisclosureInformation DisclosureDenial of ServiceElevation of Privilege

DREAD – rank vulnerabilitiesDREAD – rank vulnerabilitiesDamage PotentialReproducibilityE l it bilitExploitabilityAffected UsersDiscoverability

OWASP AppSec Seattle 2006 17

Dr. Dobb’s says Agile Methods Are Catching On

41% of organizations have adopted an agile methodology

Of the 2,611 respondents doing agile…

37% using eXtreme Programming19% using Feature Driven Development (FDD)16% using SCRUM7% using MSF for Agile Software Development

Source: http://www.ddj.com/dept/architect/191800169

OWASP AppSec Seattle 2006 18

p j p

Agile Teams are “Quality Infected”

60% reported increased productivity

66% reported improved quality

58% improved stakeholder satisfaction

OWASP AppSec Seattle 2006 19

Adoption Rate for Agile Practices

Of the respondents using an agile method…

36% have active customer participation

61% have adopted common coding guidelines

53% perform code regression testing

37% utilize pair programming

OWASP AppSec Seattle 2006 20

Let’s Look at Some Specific Agile Methods

eXtreme Programming (XP)

Feature Driven Development (FDD)

SCRUM

MSF for Agile Software Development

OWASP AppSec Seattle 2006 21

eXtreme Programming (XP)

OWASP AppSec Seattle 2006 22

Feature Driven Development (FDD)

Develop an BuildDevelop an Overall Model

BuildFeatures

ListPlanning

Startup Phase

Designb

Buildbby

Featureby

Feature

Construction Phase

OWASP AppSec Seattle 2006 23

Source: http://featuredrivendevelopment.com/

SCRUM

Commonly Used to Enhance Existing Systems F t B klFeature Backlog 30 Day SprintsDaily Team Meeting

OWASP AppSec Seattle 2006 24

Source: http://www.controlchaos.com/

MSF for Agile Software Development

Adapted from the Spiral / Waterfall Hybrid

Product definition, development and testing occurs in overlapping iterations

Different iterations have a different focus

OWASP AppSec Seattle 2006 25

An Integrated Process

Making Agile Trustworthy

OWASP AppSec Seattle 2006 26

Project Roles

Product Manager / CustomerP M / C hProgram Manager / CoachArchitectDeveloperTesterSecurity Adviser

OWASP AppSec Seattle 2006 27

Project Setup

Education & Training (include Security)D lDevelopersTestersCustomersCustomers

User Stories / Use Case DevelopmentArchitecture Decisions (spikes)Architecture Decisions (spikes)Agree on Threat Modeling standards for the projectproject

STRIDE prioritiesDREAD ratings

OWASP AppSec Seattle 2006 28

g

Release Planning

User Stories / Use Cases Drive…Acceptance Test ScenariosAcceptance Test ScenariosEstimations may affect priorities and thus the composition of the releaseInputs for Threat ModelingInputs for Threat ModelingSecurity Testing ScenariosDetermine the qualitative “risk budget”

Keep the customer involved in making risk tradeoffs

Finalize Architecture & Development GuidelinesCommon Coding Standards (include security)Common Coding Standards (include security)

Crucial for collective code ownershipConduct Initial Threat Modeling (assets & threats)Designer’s Security Checklist

OWASP AppSec Seattle 2006 29

Designer s Security Checklist

Iteration Planning

1-4 Weeks in Length (2 weeks is very common)Begins with an Iteration Planning MeetingBegins with an Iteration Planning Meeting

User Stories are broken down into Development TasksDevelopers estimate their own tasksDocument the Attack Surface (Story Level)Model the threats alongside the user story documentation

Crucial in documentation-light processesg pCapture these and keep them

– Code will tell you what decision was made, threat models will tell you why decisions were made

– Crucial for “refactoring” in the face of changing security priorities

Never Slip the DateAdd or Remove Stories As Necessary

OWASP AppSec Seattle 2006 30

y

Executing an Iteration

Daily Stand-ups

Continuous IntegrationCode Scanning ToolsgSecurity Testing Tools

Adh C C di S d d d S iAdherence to Common Coding Standards and Security Guidelines

Crucial for communal code ownershipp

Developer’s Checklist

OWASP AppSec Seattle 2006 31

Closing an Iteration

Automation of Customer Acceptance TestsI l d ti t ti f id tifi d th tInclude negative testing for identified threats

Security Code ReviewSome may have happened informally during pairSome may have happened informally during pair programming

OWASP AppSec Seattle 2006 32

Stabilizing a Release

Schedule Defects & VulnerabilitiesP i iti l biliti ith li t i t b dPrioritize vulnerabilities with client input based on agreed-upon STRIDE and DREAD standards

Security PushSecurity PushInclude traditional penetration testing

OWASP AppSec Seattle 2006 33

Compromises We’ve Made

Feature-focus in iterations removes some “top down” controldown controlMore documentation than is required in pure Agile developmentAgile development

Security coding standardsProject-specific STRIDE and DREAD standardsProject specific STRIDE and DREAD standardsUser story threat models

OWASP AppSec Seattle 2006 34

Values of an Agile and Secure Process

CommunicationSimplicityFeedbackCourageTrustworthyy

OWASP AppSec Seattle 2006 35

Questions

Dan Cornelld @d idan@denimgroup.comWebsite: www.denimgroup.comBlog: www.agileandsecure.com

OWASP AppSec Seattle 2006 36