agile security
TRANSCRIPT
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
www.1secure.nl
Arthur DonkersSecurity 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
+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
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 sothat 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 thisapplication is free of technical vulnerabilities, so that we keep our license to operate.
Security-related user storiesAs a customer, I want to be sure that the credit card data that I provide for paymentsare processed and stored securely, so that access by third parties or hackers is impossible.
Etc.
Add security to Definition of Done
ComplianceRisk
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 BlocksAuthorization 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 exampleSecurity Measure Classification:
BaselineClassification: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 testsExtension 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
[email protected] [email protected]
+31-6-29525365
www.agilesecurity.nl