SOURCE Barcelona 2011 - Matt Bartoldus

1. Matt Bartoldus
matt@gdssecurity.com
Are Agile and Secure Development Mutually Exclusive?
Source Barcelona
November 2011
©2011 Gotham Digital Science, Ltd

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
2

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?
3

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
4

5. ‘Traditional’ Waterfall
i.e. PRINCE2
5

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
6

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.
7

8. Agile Method
8

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)
9

10. Culture of Organisation and How It Affects Agile
Unhelpful characteristics Helpful characteristics
 Top-Down  Holistic
 Command and Control  Systems thinking
 Hierarchical  Delegated
 Micromanaged  Macromanaged
10

11. Not my job
11

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
12

13. PM - Align with IT
Objectives Handover
– Ensure security objectives for  Who will own the project
the project align with those of solution?
IT and the organisation as a – Accountability
whole.
 How will it be supported?
• Beyond the project
– Maintenance
• Quality
• Compliance  Responsible for security and
• Availability compliance to policy?
• KPIs – Security Operations and
Monitoring
– Compliance
13

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.
14

15. PM Objective - Quality
 What is Quality?
– Subjective
– Depends on context
ISO 9001 Six Sigma
"Degree to which a set
of inherent "Number of defects
characteristics fulfills per million
requirements." opportunities."
Quality Assurance Quality Control
• Prevention of defects • Detection of defects
15

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)
16

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
17

18. How much automated testing?
Ideal Typical
UI (end-to-end) UI
Service
Service
Unit
Unit
 UI: What is meant here is testing the whole application through the UI layer –
becomes difficult to tell where the problem is
18

19. Security within a Generic Waterfall Project
Secure Development Lifecycle
Initiate Plan Design Develop Test Release
Development Process
High Level
Functional
Requirements
Business End to End Pre / Post
Build QA
Requirements Design Production
Non-Functional
Requirements
Penetration Testing
Secure Development
Threat Modelling
Source
High Level Abuse Cases Code Security Metrics and Reporting
Risk Assessment
Review
Security Requirements Review
Checklist Review - Checklist Review
Security Code – Infosec Criteria
Architecture
Review
Risk Assessment, Metrics and Reporting
Supporting
Processes
Training and Education (Awareness, Process, Technical) Project Close
Down
Project Governance and Change Management
Defect Management
Documents
Supporting
Development
Corporate Acceptance
Infosec Standards Standards and
Infosec Policies Criteria
Guidelines
19 1
9

20. Agile Lifecycle: what happens before first Sprint
Project Setup:
.
Requirements gathering,
Team, infrastructure
…
Project Idea: Project Sprint 0: Sprint 1 Sprint 2 Sprint N
Inception:
Is this 1st
worthwhile? Issues, risks, architecture Sprint or Iteration
opportunities, iteration
Is this
marketing,
feasible? High view
green/red light
design
20

21. Benefits of a Framework Approach
 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’
21

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.
22

23. Software Assurance Security Model
o An OWASP Project
o Open framework to help organizations formulate and implement a strategy
for software security.
23

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
24

25. Security within Agile Development
Focus:
• Coding guidelines/standards/secure design patterns
• Continuous Testing
25

26. Security within a Development Project
Secure Development Lifecycle
Initiate Plan Design Develop Test Release
Development Process
High Level
Functional
Requirements
Business End to End Pre / Post
Build QA
Requirements Design Production
Non-Functional
Requirements
Penetration Testing
Secure Development
Threat Modelling
Source
High Level Abuse Cases Code Security Metrics and Reporting
Risk Assessment
Review
Security Requirements Review
Checklist Review - Checklist Review
Security Code – Infosec Criteria
Architecture
Review
Risk Assessment, Metrics and Reporting
Supporting
Processes
Training and Education (Awareness, Process, Technical) Project Close
Down
Project Governance and Change Management
Defect Management
Documents
Supporting
Development
Corporate Acceptance
Infosec Standards Standards and
Infosec Policies Criteria
Guidelines
26 2
6

27. Methods Compared (Security Perspective)
Waterfall Agile
 Defined in distinct project  Iterative inline with project
Timing of phases lifecycle phases
Activities
 Focus towards end of project/  Focus on continuous testing
pre-release throughout project
 Specialty skills primarily in  Broader range of security and
Security information security software development skills
Skills
Integration
 Brought in as needed  Embedded within project teams
 Interaction as needed  Frequent interaction/ involvement
 Specific security testing  Hybrid Security Testing
Security
Testing  Periodic  Continuous
 More towards end of project  Steady level of testing activity
throughout project
27

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.
28

29. Example – Threat Assessment
Mobile Device Customer Banking Application
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
29

30. Example – Integrated Code Review
Financial Transaction Processing Application
 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’
30

31. Are Agile and Secure Development Mutually Exclusive?
31

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)
32

33. Methods Compared (Security Perspective)
Waterfall Agile
 Defined in distinct project  Iterative inline with project
Timing of phases lifecycle phases
Activities
 Focus towards end of project/  Focus on continuous testing
pre-release throughout project
 Specialty skills primarily in  Broader range of security and
Security information security software development skills
Skills
Integration
 Brought in as needed  Embedded within project teams
 Interaction as needed  Frequent interaction/ involvement
 Specific security testing  Hybrid Security Testing
Security
Testing  Periodic  Continuous
 More towards end of project  Steady level of testing activity
pre-release throughout project
33

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
34