Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile security

818 views

Published on

How to apply security in an agile environment. Using old frameworks in an agile environment fails. By using a new model and an agile aligned security strategy, information security can be integrated into agile development projects.

Published in: Technology
  • Be the first to comment

Agile security

  1. 1. Agile Security Can infosec keep up with agile? www.i-to-i.nl A new security management approach for agile environments www.agilesecurity.nl
  2. 2. dfdd + 31-6-53315102 arthur@1secure.nl www.1secure.nl Arthur Donkers Security Officer Interested in info sec, technology, organisation and combining these all into one solution Critical Security Architect Trainer for PECB (ISO27001, 27005, 31000) Convinced that Infosec is a means to an end, not a purpose in itself. Pascal de Koning Has a security manager role at several companies. His passion is to make security an integrated part of IT. Was lead author of the TOGAF Security Guide (2016). He also initiated the Security Service Catalogue project, a joint effort of The Open Group and The SABSA Institute. Senior Security Consultant p.de.koning@i-to-i.nl +31-6-29525365 www.i-to-i.nl
  3. 3. Agenda • Four false assumptions that make the traditional security approach fail • ‘Feet in the mud’ with the Agile Security Engagement Model (ASEM) • Explanation of the innovations in this Agile Security approach
  4. 4. Why? System and application development is moving towards agile and a continuous delivery model.
  5. 5. Why? Can info security keep up with this new paradigm?
  6. 6. Why? The traditional approach for security management fails in agile development projects.
  7. 7. Managing expectations We summarize the cause of failure of traditional Security Management, and propose a new Agile Security Engagement Model (ASEM) to solve the issues.
  8. 8. New with agile Short cycles that can be managed easily, and don’t be afraid to postpone to the next cycle
  9. 9. New with agile Feed back and feed forward (results are used in next cycle, as are fixes)
  10. 10. Agile development model
  11. 11. Misalignment Agile and security frameworks do not cooperate easily because of 4 ‘assumptions’
  12. 12. Assumption #1 The agile project is capable of translating the generic security requirements to specific controls This fails because: • Agile team has other priorities • Agile team has limited resources • Agile team has a strict timeline • Agile team finds security boring
  13. 13. Assumption #2 The agile team has the expertise and knowledge to build secure solutions This fails because: • Agile team (often) does not have the skills or expertise • Agile team is not always aware of requirements • Agile team is not aware of security vulnerabilities • Agile team has no tools and methodologies
  14. 14. Assumption #3 There is sufficient time and money to perform a security test and process all of the recommendations. This fails because: • Continuous delivery has no clear test phase • Focus on functional testing • Shifting focus, only clear at start of the sprint
  15. 15. Assumption #4 There is sufficient time and money to identify and address all security risks This fails because: • Serious time constraints • Not enough people and resources • Culture clash
  16. 16. How can we solve this?
  17. 17. New: Agile Security Engagement Model • Risk-driven – don’t aim for 100% secure • Bring on security solutions – don’t just set requirements • Provide a set of sub-policies that address specific issues – not an 80-pager security policy • Security monitoring independent of development process – don’t try to synchronize with project planning
  18. 18. BREAK-OUT SESSIE
  19. 19. The basis of ASEM (from Scrum)
  20. 20. First: make security expert part of the development team • partly developer, • partly security advisor
  21. 21. Add security-related user stories Business
  22. 22. As a senior manager, I want to be sure that access to customer data is restricted so that I won’t risk a fine of 800.000 euro in case of leakage of privacy-sensitive data. As a senior manager, I want to be able to report to the regulatory board that this application is free of technical vulnerabilities, so that we keep our license to operate. Security-related user stories As a customer, I want to be sure that the credit card data that I provide for payments are processed and stored securely, so that access by third parties or hackers is impossible. Etc.
  23. 23. Add security to Definition of Done Compliance Risk
  24. 24. Sample Definition of “Done”
  25. 25. Provide security building blocks Detailed sub- policies where useful Service Catalogue with generic solutions
  26. 26. Set up a security service catalogue • Provide re-usable operational security services to the development team • Provide re-usable security patterns • Manage these via a security catalog (see next slide)
  27. 27. RESPOND DETECT PREVENT Security Service Catalogue - example User Data Application Platform Network Housing Operational Security Building Blocks Authorization management Authentication Log Management Hardening Security monitoring SSL certificate Patch management Back-up & restore Vulnerability management Trusted time Anti-virus Penetration testing Managed PKI Forensic research
  28. 28. Security Policy Framework Information Security Policy IT Security Handbook Hardening policy Encryption Standard Access Control Policy Password Policy Etc Etc Detailed sub- policies for non-security practitioners High-level, describes security management process Boring Interesting
  29. 29. Externalize and formalize the security knowledge Means to extend your span of control:  Define a classification scheme  Define security baselines
  30. 30. Classification scheme example Security Measure Classification: Baseline Classification: High Secure Authentication Username / password based on Active Directory Two-factor authentication based on PKI certificates Authorization Regular authorization process Additional approval of line manager needed Attestation Management Standard review of authorizations every 6 months Additional monthly reviews of authorizations Hardening policy Standard hardening policy for OS idem Etc.
  31. 31. Daily automated security tests Extension of regular functional tests Direct feed-back, to current or future user story
  32. 32. Continuous Monitoring • Continuous security monitoring of the development process! • Define Key Risk Indicators and Quality Controls at the detail level of the development process (e.g. OWASP secure coding standard). This step is NOT a SIEM or other Event Monitoring service!
  33. 33. Suggestions for daily, automated security checks • Source code security checks (language-dependent) – Dangerous programming logic (allow by default) – Processing undefined variables – Processing unsanitized (‘tainted’) parameters • Checks on security functionality (see user stories) – Logon – Authorization model • Testing for common abuse scenarios (generic) – Access to admin section – Session hijacking – Cross-site scripting – SQL injection – Etc.
  34. 34. Agile Security Engagement Model Continuous Security Monitoring
  35. 35. Continuous Monitoring • Checking the security within agile is an independent and separate thread • Will feed back into agile • Red Team • No scope limitations, dedicated testing • Bug bounty program • Disclosure • Incident response process
  36. 36. Summary of Agile Security Engagement Model • Make security expert part of the development team • Security-related user stories • Security building blocks in the service catalogue • Detailed security policies where needed • Security classification to unify and automate decisions • Daily automated security tests • Continuous monitoring Publications in progress Check previous PECB-webinar of Arthur Donkers
  37. 37. Conclusion for Security Management • Apply hands-on approach • Provide a security catalog with re-usable services and patterns • Implement continuous monitoring process • Accept that not all risks will be addressed, so rely on your risk management capabilities
  38. 38. ? QUESTIONS THANK YOU + 31-6-53315102 arthur@1secure.nl p.de.koning@i-to-i.nl +31-6-29525365 www.agilesecurity.nl

×