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