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. 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)

10. Agile development model

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

19. BREAK-OUT SESSIE

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