Agile and Security - OWASP...4. Agile teams do more planning than traditional teams, but it’s just...

®

IBM Software Group

© 2009 IBM Corporation

Agile Software Development and Security

Scott W. AmblerChief Methodologist/Agile&[email protected]

IBM Software Group | Rational software

2

Agenda

� Introduction

� Agile process maturity

� Agile and security

� Parting thoughts


3

Agenda� Introduction

�Determining if a team is agile

�Misconceptions about agile

�Industry statistics

�When agile is not applicable

� Agile process maturity

� Adopting and security

� Parting thoughts


4

Criteria to determine if a team is agile

Disciplined agile teams:

1. Produce working software on a regular basis.

2. Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach.

3. Work closely with their stakeholders, ideally on a daily basis.

4. Are self-organizing, and disciplined teams work within an appropriategovernance framework.

5. Regularly reflect, and measure, on how they work together and then act to improve on their findings in a timelymanner.


5

Addressing misconceptions about agile

1. Agile teams write documentation

2. Agile teams model

3. Agile requires greater discipline than traditional approaches

4. Agile teams do more planning than traditional teams, but it’s just in time (JIT)

5. Agile is more predictable than traditional

6. Agile scales very well

7. RUP can be as agile as you want to make it

8. Agile is not a fad, it is being adopted by the majority of organizations

9. Agile can do fixed price, but it’s still poor practice to do so


6

Project success rates

Source: Dr Dobb’s 2008 Project Success Survey

Bottom Line: Agile teams produce higher quality work, are quicker to deliver, are more likely to deliver the right functionality,

and more likely to provide greater ROI than traditional teams

AgileIterativeTraditionalAd-Hoc

0.8

0.8

2.7

0.4

0.8

0.2

1.8

2.3

4.0

3.0

5.6

5.0

4.4

3.9

6.0

4.9

Time

Money

Functionality

QualityIterative

Agile

Traditional

Ad-Hoc


7

When agile is not applicable

� The culture of the organization is the primary determinant.

� Potential cultural pitfalls:�Waterfall culture

�Low-trust environment

�Unwillingness to change

� Very expensive to redeploy the system

� Significant dependencies on new hardware development

� They’re doing a good job with non-agile approaches


8


� Agile Process Maturity�Towards a maturity model

�Disciplined agile development

�Agility at scale

� Industry statistics

� Agile and security

� Parting Thoughts


9

Agile Process Maturity Model

1Core Agile

SoftwareDevelopment

Focus is on construction

Goal is to develop a high-quality system in an evolutionary, collaborative manner

Value-driven lifecycle with regular production of working software

DisciplinedAgile Software

Development

Extends agile development to address full system lifecycle

Risk and value-driven lifecycle

Lean development governance

Agility at Scale

�Addresses one or more scaling factors, including:�Team size

�Geographical distribution

�Organizational distribution

�Regulatory compliance

�Environmental complexity

3

2


10

Agile Values: AFoundation forAgile Development

WorkingSoftwareWorkingSoftware

Individuals InteractionsIndividuals Interactions

Respond to ChangeRespond

to Change

CustomerCollaboration


Source: www.agilemanifesto.org

ComprehensiveDocumentationComprehensiveDocumentation

Processes and ToolsProcesses and Tools

Following a Plan

Following a Plan

ContractNegotiation

ContractNegotiation

overWe value

That is, while there is value in the items on the right, we value the items on the left more.

1


11

What is disciplined agile?Disciplined agile software development is an evolutionary (iterative and incremental) approach to development which regularly produces high quality software in a cost effective and timely manner via a risk and value driven lifecycle.

It is performed in a highly collaborative and self-organizing manner, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders.

Disciplined agile development teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.

� “Fits just right” process�Continuous testing and validation�Consistent team collaboration�Rapid response to change�Ongoing customer involvement�Frequent delivery of working software

Core Principles

2


12

The Agile Construction Lifecycle

Source: www.ambysoft.com/essays/agileLifecycle.html

1


13

The Full Agile Development Lifecycle

Source: www.ambysoft.com/essays/agileLifecycle.html

2


14

Manifesto for Software Craftsmanship

WorkingSoftwareWorkingSoftware

Individuals InteractionsIndividuals Interactions

Respond to ChangeRespond

to Change



Source: manifesto.softwarecraftsmanship.org

Well-CraftedSoftware

Well-CraftedSoftware

A Community of

Professionals

A Community of

Professionals

Steadily Adding Value

Steadily Adding Value

ProductivePartnershipsProductive

Partnerships

but alsoNot only

That is, in pursuit of the

items on the left we have found the items

on the right to be indispensable.

2


15

Co-located

Geographical distribution

Global

Team size

Under 10developers

100’s ofdevelopers

Enterprise discipline

Projectfocus

Enterprisefocus

Compliance requirement

Low risk Critical,Audited

Organization and culture

Open Entrenched

Application complexity

Simple, single platform

Complex, multi-platform

Organization distribution(outsourcing, partnerships)

In-house Third party

What is Agility at Scale?

Disciplined Agile

Development

3


16

0 20 40 60 80 100 120 140 160

1 to 5

6 to 10

11 to 20

21 to 50

51-100

101 to 200

200+

Attempt Success

Largest team size: Attempted vs. Successful

Source: Dr Dobb’s 2008 Agile Adoption Survey


17

Agile project success rates: the effect of distribution

55%

73%

79%

70%

AverageCo-LocatedNear LocatedFar Located

Source: Dr Dobb’s 2008 Project Success Survey


18


� Agile Process Maturity

� Agile and security�Recognize limitations of “level 1” strategies

�Product owners

�Initial modeling

�Parallel independent testing

�Invest in your staff

�Tooling

� Parting Thoughts


19

Recognize That the Agile Requirements Strategy Doesn’t Work Well for “ilities”

Requirements are prioritized by stakeholders

Requirements are estimated by the development team

Requirements will evolve throughout the project

Stakeholders see working software each iteration

Stakeholders can change the level of funding as appropriate

Stakeholders determine when “enough is enough”

Source: www.agilemodeling.com/essays/prioritizedRequirements.htm


20

Product Owners Must Represent a Wide Range of Stakeholders – Including Security Stakeholders

� On-site customer is nice, so put them to work

� Stakeholders can be active participants in modeling

� Product owner is really a communication conduit between the team and stakeholders

� Must have agile business analysis skills

� PO gets the team access to the relevant stakeholders just in time

� Negotiate, negotiate, negotiate

Source: www.agilemodeling.com/essays/agileRequirementsBestPractices.htm


21

Do Some Up Front Modeling

Source: www.agilemodeling.com/essays/amdd.htm

Do some initial requirements envisioning to identify the high-level requirements

Do some initial architecture envisioning to identify a viable architecture strategy

DO NOT write detailed specifications at the beginning of the project

The goal is to reduce risk by thinking critical issues through but not take on the burden (and risk) of detailed specifications


22

Have an Independent Test Team Looking for “ilities”

Effective agile teams push their working builds to an independent test team on a regular basis for investigative testing

Change stories must be prioritized and put back on the team’s work stack

Defects == Requirements

Scales TDD: TDD is a form of confirmatory testing. TDD is a great start, but it’s not the full testing picture

Critical strategy for addressing non-functional requirements


23

Invest in Your Staff

� Developers should understand the fundamentals of security�General: Developers should understand the fundamentals of a wide range of topics,

security being one of many

� One-to-two day “intro to security” training

� Mentoring

� Non-solo development�Developers can easily pick up security skills from others who already have them


24

Tooling: IBM Rational AppScanTesting web applications for security problems

� AppScan is an automated Web application security solution that accurately pinpoints critical vulnerabilities and provides advice on how to fix them.

� Helps you to evaluate, understand and resolve security issues and greatly reduce the business risks related to Web vulnerabilities.

� Facilitates PCI compliance

�Greatly reducing the need for manual testing, freeing up resources

�Making in-house web penetration testing automated and affordable

�Protecting company web infrastructure and brand

Source: www.ibm.com/software/awdtools/appscan/


25

Tooling: IBM Rational Software AnalyzerAutomating Code Inspection

Continuous, comprehensive, and collaborative quality

management throughout the lifecycle reduces costs and

improves credibility

Automating workflows across business processes by

streamlining and eliminating redundancies to improve

return on investment

Moment-by-moment grasp of software quality

and project metrics for immediate

corrective action

Continuous Automated Visibility

Source: www.ibm.com/software/awdtools/swanalyzer/


26


� Agile Process Maturity

� Agile and Security

� Parting Thoughts�Why IBM?

�Critical Resources


27

Why IBM?� Our integrated tooling based on the Jazz

platform enables disciplined agile software development

� Our Measured Capability Improvement Framework (MCIF) service offering helps organizations to successfully improve their IT practices in a sustained manner

� We are one of the largest agile adoption programs in the world

� We understand the enterprise-level issues that you face

� We scale from pilot project consulting to full-scale agile adoption

� Our Accelerated Solutions Delivery (ASD) practice has years of experience delivering agile projects at scale


28

Critical resources

� www.ibm.com/rational/agile/

� www.ibm.com/developerworks/

� www.ibm.com/developerworks/blogs/page/ambler

� www.jazz.net


29

© Copyright IBM Corporation 2009. All rights reserv ed. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Agile and Security - OWASP...4. Agile teams do more planning than traditional teams, but it’s just...

Documents

Transcript of Agile and Security - OWASP...4. Agile teams do more planning than traditional teams, but it’s just...