1

Xebia Security

Who Am I

Dave van Stein- nl.linkedin.com/in/dvstein- @Dave_von_S

Security Consultant

SecDevOps Engineer

Embedding security and privacy controls in agile anddevops environments

KPN

Largest Telecom and IT operator in NL

Consumer, Business, Corporate markets

Several international brands

18,000 employees, 500M€ profit

KPN Online

Most internet facing applications and appsOpen environment (www.kpn.com)Selfcare environments (mobile & desktop)Consumer and small business webshop

A long, long time ago …

-2013: project based

Security requirements Penetration test

Afterfix Afterfix 2

Retest

2014: Agile transformation

Security & Agile?

One way to do it

A change from this

To this

While preventing this

Find a new balance

Voor intern gebruikKPN Web Application Security

KPN Online Security Roadmap

Tooling capability

KSP’s defined

Embed security behaviours

Operationalise Quality & Security (Q&S) framework

Business alignment Clear governance structure

New / emerging risk & technology

Regulatory changes

Maturity timeline

Bus

ines

s/IT

Val

ue

• Adhoc management• Lack of business/IT

alignment;• Unclear and/or no process

documentation;• Inconsistent processes;

• Defined Q&S framework aligned with new WoW;

• Clear roles & responsibilities;

• Simplified communication & engagement;

• Security awareness & training;

• Understanding of security risk;

• Continuous monitoring of new threats and vulnerabilities;

• Complete & accurate reporting;

Non-

existent

• Not clearly demonstrated.

• Multiple dashboard reporting;

• Semi-structured assessments;

• Security advisory;

Risk focused

Recognition Q&S value

Confidence in implementation of Q&S framework

Policies

Split your policies

Voor intern gebruikKPN Web Application Security

Policies governed within innovation

1 Policies and Digital Innovation

Vision (team)Ready (team)

Scrum (team) Operational (team)I-theme Epics Features

UsrStories Product

Launched

Global

Detail

Policy assessor(involvement responsibility of Pa)

First check on applicable policies can be done

Inform about themes

Policy assessor(invited by Ready Team)

Check if applicable policies are covered and / or define extra

“requirements”

Invite / walk through features by “Policy

consultation” (spreekuur)

Policy assessor(involvement responsibility of Pa)

Second check on applicable policies

will be done

Inform about Epics

Policy assessor(informed by Ready Team)

Check if all necessary and predefined

“policy” requirements are covered within

usr stories

Policy assessor(stakeholder during Demo)

Alle applicable policies / requirements covered in product / deliverable

Product Owner to Pa stakeholders“Policy risk :

High : invite for DemoMedium: check test resultsLow : no involvement

PBL

DOD

DOR

Pa Policy AssessorPBL: Product backlog (requirements list in form of usr stories);PCL: Policy Checklist;DOR: Definition of Readiness (a kind of clear order check to see if everything is clear enough to start design / built/ test cycle);DOD: Definition of Done (checklist to see if all the work has been done, so product is ready for next step) (ie concerning policies: Are policy requirements met??)Demo: A demo from the deliverd product to the most important stakeholders

Legend

PCL

Invite / informGo from Pa

Check (applicable Policies)

KSP requirements for the Agile innovation process

Covering KSP for Agile teams (process level)

18

Step Description When (Agile) Who

Have the needed level of security knowledge in project to:

Constantly Security stakeholder, Prod Owner & team

Scope relevant KSP requirements to teams Quarterly Security stakeholder + support

Classify the changes Quarterly /Backlog Ref.

Security stakeholder high levelProd Owner During refinement

Risk analysis (on team level for high risk teams) Quarterly Security stakeholder + support

Additional Requirements (high risk teams only) Quarterly /Sprint

Security stakeholderTeam per Sprint (ASRA)

Supplier management Before signing contracts Supplier management / Teamlead

Exceptions (if applicable) Sprint Team, Scrum Master

Continuity (update continuity plans) Backlog Ref.. & Sprint Process Chain Manager

Quality Assurance: Complete coverage check Sprint Team (by testing etc.)

Quality Assurance: Security testing by Portal Authority Before Def. of Done High Risk, see detailed appointments how to handle

Onboard new systems with SOC Before Def. of Done Monitoring

3

5

4

6

8

7

0

2

1

9

10

KSP requirements for the Agile innovation process

Relevant KSP requirement

Have the needed level of security knowledge in project

ID Title Short Description

KSP-FA06-RL01-R01 Security in Innovation

Every project must have a security specialist capable of guiding the project

0

Accountability / Responsibility:

• Product Owner: Is accountable to cover policies

• Security stakeholder: Has detailed knowledge of security

• Development Team: Responsible for applying policies

• Activities:

- Scoping of KSP requirements (is this requirement relevant for this change?)

- Classifying change (is this a high risk change?)

- Risk analysis & additional requirements (are additional requirements needed on top of KSP?)

Who?

• Security stakeholder & Product Owner & Dev

Team

When?

Constantly

KSP requirements for the Agile innovation process

Relevant KSP requirement

Exceptions (if applicable): Impediment (blocking issue) on security requirement.

6

Responsibility

• Team Members: Check if the proposed solution meets all requirements (KSP + additional)

• Scrum Master: Start exception management process by means of security stakeholder for all

requirements that are not (or not completely) met.

Who?

• Scrum master (representing implementation

team) & Security stakeholder (content)

When?

During sprint

ID Title Short Description

KSP-FA06-ST01-R04 Exceptionmanagement

Any requirement that cannot be met must be handled via Exception Management.

Security must become agile

Form a guild

Pentests

Waterfall vs Agile

Risk Profiling

Agile Risk Self Assessment

But there’s more

Architecture

Standardize

Ground rules

Assess new blocks

Experiment

Experiment

X

Thinks about the wrongs

Cause the bad guys do

Abuse cases

Security by Design S&I Digital

Scrum team 1

KSP requirement

tool

Build / Test

Code Review / Vulnerability Assesment by 3rd party or internal

“Pen Test” / CR_VA

results checkby Security stakeholder

Backlog

FinalSecurity approval

Scrum team 2

Scrum team …

MaturityTool

(Quaterly)

Backlog

Backlog

Abusecases

Prod

Threatmodel

ARSA ARSA ARSA ARSA

ARSA: Agile Risk Self Assessment

Requirements “Test / Review” Approval

New Systems and / or Major functional

changes on existingsystems

1. Security stakeholder involved2. CR/ VA by 3rd party

1. Security stakeholder involved2. CR/ VA by 3rd party

3. Final Check PA

3. Final Check Sec. Officer Digital

Medium functionalchanges on existing

systems

changes on existingsystems within

existing functionality

1. No extra steps necessary or internal scan (VA)

1. KSP Req tool2. Threat Analysis3. Abuse cases

1. KSP Req tool2. Threat Analysis3. Abuse cases

1. KSP Req tool2. Threat analysis

2. Final Check Scrum Team

“Pen Test” byRed TeamPeriodically

High Security RiskMedium Security RiskLow Security Risk

SecDevOps teams

Monitoring

Continuous security

Remember

Thank you, Q&A