©2011 Gotham Digital Science, Ltd

Are Agile and Secure Development Mutually Exclusive? Source Barcelona

November 2011

Matt Bartoldus matt@gdssecurity.com

2

Introduction

o Me

o Who Are You? – Assessment (Penetration Tester; Security Auditors)

– Developer

– IT Architect

– Management

– Academia

– Consultant (2 or more above)

– Here because someone told you that you now have to do security

3

Agenda

‘Traditional’ Project Method

Agile Project Method

Agile Conditions and Culture

Project Managers and Objectives

QA and Agile Testing

Frameworks and Agile

Security in Agile Development

Waterfall vs Agile

Real World Examples

Are Agile and Secure Development Mutually Exclusive?

4

‘Traditional’ Project Method

Tasks are completed in a stage by stage manner - linear;

Each stage assigned to a different team

Requires a significant part of the project to be planned up front;

Once a phase is complete, it is assumed that it will not be revisited;

Lays out the steps for development teams;

Stresses the importance of requirements

5

‘Traditional’ Waterfall

i.e. PRINCE2

6

Manifesto for Agile Software Development

Signatories in 2001 (following a decade of Agile methodology practices):

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

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

Source: www.agilemanifesto.org

7

Agile Method

Working in cycles i.e. a week, a month, etc;

Project priorities are re-evaluated and at the end of each cycle;

Aims to cut down the big picture into puzzle size bits, fitting them together when the time is right;

Agile methods benefit small teams with constantly changing requirements, rather more than larger projects.

8

Agile Method

9

Conditions for Agile

Project value is clear

Customer actively participates throughout the project

Customer, designers, and developers are located together

Incremental feature-driven development is possible (focus on one feature at a time)

10

Culture of Organisation and How It Affects Agile

Top-Down

Command and Control

Hierarchical

Micromanaged

Holistic

Systems thinking

Delegated

Macromanaged

Helpful characteristics Unhelpful characteristics

11

Not my job

12

PM - Define Security Objectives

Understand current threats and risks

– As well as control objectives and controls

Know security drivers

Understand Resources (skills needed)

Have defined requirements

Have a Plan

13

Objectives

– Ensure security objectives for the project align with those of IT and the organisation as a whole.

• Beyond the project

• Quality

• Compliance

• Availability

• KPIs

Handover

Who will own the project solution? – Accountability

How will it be supported? – Maintenance

Responsible for security and compliance to policy? – Security Operations and

Monitoring

– Compliance

PM - Align with IT

14

PM - Align with IT

Embed Security skills within IT – Development = secure code skills

– Architecture = security technology and architecture skills

– Communications (Networks) = network and infrastructure security skills

– Support = security training and awareness, security operations and monitoring

– Quality = security testers, auditors

Develop working relationships with IT management and help them understand security objectives aligned with theirs.

15

PM Objective - Quality

What is Quality? – Subjective

– Depends on context

Quality Assurance • Prevention of defects

Quality Control • Detection of defects

Six Sigma "Number of defects per million opportunities."

ISO 9001 "Degree to which a set of inherent characteristics fulfills requirements."

16

The role for QA

Traditional

– Testing performed at end of waterfall process

– Document centric: specifications and test plans

– Developer-QA interaction: throw over wall

Agile

– Testing activity at all stages of the development lifecycle

– Face to face interactions matter more than documents

• Testers talk to developers

– QA is essential for a complete Agile process (by-passing the QA team is high risk)

17

Agile Testing

Requirements documents give way to stories tied with User Acceptance Tests

Specifications give way to prototypes, mock ups, examples

– but some documents are necessary

QA and testers are part of Agile team, interact with developers, end users, and customer

18

How much automated testing?

UI: What is meant here is testing the whole application through the UI layer – becomes difficult to tell where the problem is

UI (end-to-end) UI

Service Service

Unit Unit

Ideal Typical

19 19

Secure Development Lifecycle

Initiate Plan Design Develop Test Release

Hig

h Le

vel

Dev

elop

men

t Pro

cess

Sec

ure

Dev

elop

men

t

S

uppo

rting

Pro

cess

es

Sup

porti

ng

Doc

umen

ts

Business

Requirements

Non-Functional

Requirements

Functional

Requirements

End to End

DesignBuild QA

Pre / Post

Production

Threat Modelling

Security Requirements Review

Abuse Cases

Security

Architecture

Review

Source

Code

Review

Checklist Review -

Code

Penetration Testing

Training and Education (Awareness, Process, Technical)

Defect Management

Security Metrics and Reporting

Checklist Review

– Infosec Criteria

Project Governance and Change Management

Infosec StandardsCorporate

Infosec Policies

Development

Standards and

Guidelines

Acceptance

Criteria

Risk Assessment, Metrics and Reporting

High Level

Risk Assessment

Project Close

Down

Security within a Generic Waterfall Project

20

Agile Lifecycle: what happens before first Sprint

.

…

Sprint N

Sprint or Iteration

Project Idea:

Is this

worthwhile?

Is this

feasible?

Project

Inception:

Issues, risks,

opportunities,

marketing,

green/red light

Project Setup:

Requirements gathering,

Team, infrastructure

Sprint 0:

1st

architecture

iteration

High view

design

Sprint 1 Sprint 2

21

Primary Benefit

– A way to link the inherent threats and risks of applications and underlying infrastructure to those facing the organisation as a whole.

That’s business speak for ‘get all of the super techies and business types on the same page’

Benefits of a Framework Approach

22

Microsoft Security Development Lifecycle

Software development processes designed to improve the security of the software

– Reaction to negative security reputation in early 2000’s

– Three core concepts—education, continuous process improvement, and accountability.

23

Software Assurance Security Model

o An OWASP Project

o Open framework to help organizations formulate and implement a strategy for software security.

24

Microsoft SDL for Agile

Security practices

– Every-Sprint practices: Essential security practices that should be performed in every release.

• Threat Assessment

• Code Review

• Design Review

– Bucket practices: Important security practices that must be completed on a regular basis but can be spread across multiple sprints during the project lifetime.

• Dynamic Security testing

• Fuzz Testing (mis-use)

– One-Time practices: Foundational security practices that must be established once at the start of every new Agile project.

• Risk Assessment

• Define Requirements

• Incident Response

25

Security within Agile Development

Focus: • Coding guidelines/standards/secure design patterns • Continuous Testing

26 26

Secure Development Lifecycle

Initiate Plan Design Develop Test Release

Hig

h Le

vel

Dev

elop

men

t Pro

cess

Sec

ure

Dev

elop

men

t

S

uppo

rting

Pro

cess

es

Sup

porti

ng

Doc

umen

ts

Business

Requirements

Non-Functional

Requirements

Functional

Requirements

End to End

DesignBuild QA

Pre / Post

Production

Threat Modelling

Security Requirements Review

Abuse Cases

Security

Architecture

Review

Source

Code

Review

Checklist Review -

Code

Penetration Testing

Training and Education (Awareness, Process, Technical)

Defect Management

Security Metrics and Reporting

Checklist Review

– Infosec Criteria

Project Governance and Change Management

Infosec StandardsCorporate

Infosec Policies

Development

Standards and

Guidelines

Acceptance

Criteria

Risk Assessment, Metrics and Reporting

High Level

Risk Assessment

Project Close

Down

Security within a Development Project

27

Waterfall Defined in distinct project

phases

Focus towards end of project/ pre-release

Specialty skills primarily in information security

Brought in as needed

Interaction as needed

Specific security testing

Periodic

More towards end of project

Agile Iterative inline with project

lifecycle phases

Focus on continuous testing throughout project

Broader range of security and software development skills

Embedded within project teams

Frequent interaction/ involvement

Hybrid Security Testing

Continuous

Steady level of testing activity throughout project

Methods Compared (Security Perspective)

Timing of

Activities

Security

Skills

Integration

Security

Testing

28

Threat Assessment

• Structured process to identify, categorise and document application level risks;

• Provides important input in to subsequent phases of the SDLC such as the formulation of application security requirements, generation of abuse cases, targeted code review and most importantly the design of compensating controls to protect against specific threats.

29

Example – Threat Assessment

Performed threat assessment of proposed solution

• Assessed Use Cases and Scenarios (story boards)

– Results lead to the following: • Understand primary threats

• Derive Primary Security Objectives

• Validated Security Requirements

• Security considerations for solution design prior to and while coding

Mobile Device Customer Banking Application

30

Example – Integrated Code Review

Security Code Review Capabilities to project teams

– Integrated security code review capabilities within the development infrastructure

• On to developer desktops

• Within build environment

– Results led to the following:

• Increased awareness of security within teams

• Ability to perform continuous testing

• Emergence of ‘secure code libraries’

Financial Transaction Processing Application

31

Are Agile and Secure Development Mutually Exclusive?

32

Summary of security vulnerabilities, and how Agile can help:

Code weaknesses

– Code standards: These can be tested using security unit tests

Architecture/Design weaknesses

– Agile iterations revisit the design every iteration, raise security as first class consideration

Social engineering / cognitive hacking

– Run an Agile security sprint to simulate scenarios and identify weak spots

Lack of motivation to implement security

– Agile collaboration can raise security profile: it may not be seen to add value to an application but it lowers customer’s risk (fear)

33

Waterfall Defined in distinct project

phases

Focus towards end of project/ pre-release

Specialty skills primarily in information security

Brought in as needed

Interaction as needed

Specific security testing

Periodic

More towards end of project pre-release

Agile Iterative inline with project

lifecycle phases

Focus on continuous testing throughout project

Broader range of security and software development skills

Embedded within project teams

Frequent interaction/ involvement

Hybrid Security Testing

Continuous

Steady level of testing activity throughout project

Methods Compared (Security Perspective)

Timing of

Activities

Security

Skills

Integration

Security

Testing

34

Conclusions

Agile Management processes compliment GRC objectives:

– Continuous auditing and controls monitoring

Like any processes, success is dependent on a number of factors:

– People (Skills)

– Metrics

– Defined Clear Objectives

– Clear Requirements

Stronger Emphasis on coding guidelines/standards/secure design patterns