SlideShare a Scribd company logo

Agile security

•Download as PPTX, PDF•
•
Arthur Donkers
Arthur Donkers

The document discusses challenges with traditional security management approaches in agile development environments. It proposes a new Agile Security Engagement Model (ASEM) to address these challenges. ASEM involves making security experts part of the development team, adding security-related user stories, providing security building blocks through a service catalog, implementing detailed security policies when needed, classifying security measures to automate decisions, conducting daily automated security tests, and establishing continuous independent monitoring of the development process. The goal of ASEM is to take a hands-on approach to security and provide reusable security services, patterns and continuous monitoring to help address risks in an agile context where not all can be fully addressed.

1 of 39
Agile Security Can infosec keep up with agile? www.i-to-i.nl A new security management approach for agile environments www.agilesecurity.nl
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
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
Why? System and application development is moving towards agile and a continuous delivery model.
Why? Can info security keep up with this new paradigm?
Why? The traditional approach for security management fails in agile development projects.
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.
New with agile Short cycles that can be managed easily, and don’t be afraid to postpone to the next cycle
New with agile Feed back and feed forward (results are used in next cycle, as are fixes)
Agile development model
Misalignment Agile and security frameworks do not cooperate easily because of 4 ‘assumptions’
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
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
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
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
How can we solve this?
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
Agile security
BREAK-OUT SESSIE
The basis of ASEM (from Scrum)
First: make security expert part of the development team • partly developer, • partly security advisor
Add security-related user stories Business
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.
Add security to Definition of Done Compliance Risk
Sample Definition of “Done”
Provide security building blocks Detailed sub- policies where useful Service Catalogue with generic solutions
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)
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
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
Externalize and formalize the security knowledge Means to extend your span of control:  Define a classification scheme  Define security baselines
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.
Daily automated security tests Extension of regular functional tests Direct feed-back, to current or future user story
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!
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.
Agile Security Engagement Model Continuous Security Monitoring
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
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
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
? QUESTIONS THANK YOU + 31-6-53315102 arthur@1secure.nl p.de.koning@i-to-i.nl +31-6-29525365 www.agilesecurity.nl

More Related Content

Agile security

  • 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. 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. 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. Why? System and application development is moving towards agile and a continuous delivery model.
  • 5. Why? Can info security keep up with this new paradigm?
  • 6. Why? The traditional approach for security management fails in agile development projects.
  • 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. New with agile Short cycles that can be managed easily, and don’t be afraid to postpone to the next cycle
  • 9. New with agile Feed back and feed forward (results are used in next cycle, as are fixes)
  • 11. Misalignment Agile and security frameworks do not cooperate easily because of 4 ‘assumptions’
  • 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. 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. 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. 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. How can we solve this?
  • 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
  • 20. The basis of ASEM (from Scrum)
  • 21. First: make security expert part of the development team • partly developer, • partly security advisor
  • 22. Add security-related user stories Business
  • 23. 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.
  • 24. Add security to Definition of Done Compliance Risk
  • 25. Sample Definition of “Done”
  • 26. Provide security building blocks Detailed sub- policies where useful Service Catalogue with generic solutions
  • 27. 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)
  • 28. 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
  • 29. 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
  • 30. Externalize and formalize the security knowledge Means to extend your span of control:  Define a classification scheme  Define security baselines
  • 31. 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.
  • 32. Daily automated security tests Extension of regular functional tests Direct feed-back, to current or future user story
  • 33. 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!
  • 34. 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.
  • 35. Agile Security Engagement Model Continuous Security Monitoring
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. ? QUESTIONS THANK YOU + 31-6-53315102 arthur@1secure.nl p.de.koning@i-to-i.nl +31-6-29525365 www.agilesecurity.nl