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

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

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

arthur@1secure.nl p.de.koning@i-to-i.nl

+31-6-29525365

www.agilesecurity.nl