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.

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

13. 1. Architecture overview

14. 1. Architecture overview
Image from: http://msdn.microsoft.com/en-us/library/ff649779.aspx

15. Data-Flow-Diagrams are great

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