Agile Secure Development
3 likes849 views
The document discusses how to integrate security requirements within agile development teams, highlighting the lack of security throughout the software development lifecycle. It presents key strategies for improving application security, including threat modeling, continuous integration, and incorporating security activities into sprints. The author emphasizes the importance of collaboration and responsibility among team members to create secure applications.
Agile Secure Development
- 1. SARAJEVO, 27.10.2014 Agile Secure Development Petter Sandholdt -How to make the agile team work with security requirements
- 2. Who am I? Petter Sandholdt -Senior Developer -Senior Security Consultant -Java, C, C++, C#, Cocoa, Erlang, PHP, Pike, Ruby, Cobol, Fortran, Lisp -Security in R&D for last 6 years ... in agile teams the last 5 years
- 3. Easy targets Verizon Enterprise’s 2013 Data Breach Investigations Report ●47,000reported security incidents, ●621confirmed data security breaches ●companies of all sizes. http://www.verizonenterprise.com/DBIR/2013/ 78% of successful security intrusions were simple to pull off
- 4. What do Dev and SO think? http://www.pcadvisor.co.uk/news/network-wifi/3345773/developers-say-application-security-lacking/#ixzz2Vj0QCALy Developers Security Officers Security of applications is not addressed There is no build security in process SSDLC Application had a security breach during the past 2 years Did not receive software and application security training Application meets security regulations 70% 50% 80% 64% 68% 47% 50% 50% 15% 12%
- 5. Agile application ≠ Secure? Agile moto: ●Do what’s in the sprint XP moto: ●Never do more that what’s required TDD moto: ●Code until its green
- 6. Agile application = Secure? REQS CODE
- 7. Agile application = Secure? CODE REQS NOT TESTED
- 8. When is an application secure? ●Requires hard-to-guess passwords? ●Has input validation? ●Has up-to-date and hardened 3rd-party libraries? ●The one that fulfills the security requirementsof the application
- 9. How can the POs know about security? POs are OWNERSin that role decide what is important for this application. ●Deployability (Architects or Operations) ●Performance (Architects,Testers & DBA) ●How to code it (Developers)
- 10. Secure Software Development Life Cycles ●Microsoft SDL ●Adobe SPLC ●CLASP ●Cigital Touchpoints
- 11. Secure Coding in 5 minutes 1.Take Responsibility 2.Never trust data 3.Create a threat model 4.Keep yourself updated 5.Make a fuzz 6.Stay proud of your code 7.Use the best tools http://bit.ly/1dZ6fwA
- 12. Recipe that works! 1.Architecture Overview 2.Have threat modelling sessions 3.Review all new requirements/stories 4.Fix your tools to help you 5.Add YOUR activities to sprint
- 14. 1. Architecture overview Image from: http://msdn.microsoft.com/en-us/library/ff649779.aspx
- 16. Agile??? WTF! More artifacts! Not on my watch! -Helps collaboration-Find discrepancies-Creates ONE terminology
- 17. 2. Threat Modeling session ●First session ○Brainstorming ●Following sessions ○Discussions aroundadded entities
- 18. 2. Threat Modeling session Threat Property we want Spoofing Authentication Tampering Integrity Repudiation Non-repudiation Information Disclosure Confidenciality Denial of Service Authentification Elevation of Privilege Authorization
- 19. Threat Modeling session Elevation of Privilege (EoP) Card Game
- 20. 3. Backlog Review Look at the backlog from a security perspective Security Expert (from team) and PO Create checklist to facilitate
- 21. 3. Checklist Example ●How will this new functionality be accessed? ●Can this affect “protected identites”? ●New entites in theatmodel require adding a new theatmodel session ●New role of users needs new validations on each resource ●Validations needed to be updated if property changes
- 22. 4. Fix your tools to help you ●Continuous Integration ●Static code analyzers ●Dynamic code analyzers ●Penetration tests tools
- 23. 4 Continuous Integration ●Find compile errors in configuration ●Automate robustness testing ○Unit ○Integration ○System ○Fuzz
- 24. 4 Analyze the code ●Evaluate state of code checked in ○Complexity ○Rule breaking ●Tools ○SonarQube ○Coverity ○Fortify
- 25. 5. Add activities to sprints ●Update high level diagram ●Keep updated ●Fuzz-testing
- 26. Buckets ●Verification ○Fuzz ○Data-flow ●Design ○Cryptology ○Privacy ●Planning ○Privacy tests ○Internal symbols
- 27. Recipe that works! 1.Architecture Overview 2.Have threat modelling sessions 3.Review all new requirements/stories 4.Fix your tools to help you 5.Add YOUR activities to sprint
- 28. Q & A -This won’t work in my team since… petter.sandholdt@softhouse.se
- 30. Thank You