Are Agile And Secure Development Mutually Exclusive?

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

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

‘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

‘Traditional’ Waterfalli.e. PRINCE2 5

Manifesto for Agile Software DevelopmentSignatories 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

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

Agile Method 8

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

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

Not my job 11

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

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

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

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

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

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

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

Security within a Generic Waterfall ProjectSecure Development Lifecycle Initiate Plan Design Develop Test ReleaseDevelopment 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 ReportingSupportingProcesses Training and Education (Awareness, Process, Technical) Project Close Down Project Governance and Change Management Defect ManagementDocumentsSupporting Development Corporate Acceptance Infosec Standards Standards and Infosec Policies Criteria Guidelines 19 1 9

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 1stworthwhile? Issues, risks, architecture Sprint or Iteration opportunities, iterationIs this marketing,feasible? High view green/red light design 20

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

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

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

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

Security within Agile DevelopmentFocus:• Coding guidelines/standards/secure design patterns• Continuous Testing 25

Security within a Development ProjectSecure Development Lifecycle Initiate Plan Design Develop Test ReleaseDevelopment 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 ReportingSupportingProcesses Training and Education (Awareness, Process, Technical) Project Close Down Project Governance and Change Management Defect ManagementDocumentsSupporting Development Corporate Acceptance Infosec Standards Standards and Infosec Policies Criteria Guidelines 26 2 6

Methods Compared (Security Perspective) Waterfall Agile  Defined in distinct project  Iterative inline with projectTiming of phases lifecycle phasesActivities  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 SkillsIntegration  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

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

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

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

Are Agile and Secure Development Mutually Exclusive? 31

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

Methods Compared (Security Perspective) Waterfall Agile  Defined in distinct project  Iterative inline with projectTiming of phases lifecycle phasesActivities  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 SkillsIntegration  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

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

Are Agile And Secure Development Mutually Exclusive?

by SOURCE Conference

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Are Agile And Secure Development Mutually Exclusive? Presentation Transcript