Who Am I. Dave van Stein - nl.linkedin.com/in/dvstein Security Consultant. SecDevOps Engineer

Size: px

Start display at page:

Download "Who Am I. Dave van Stein - nl.linkedin.com/in/dvstein Security Consultant. SecDevOps Engineer"

Bethanie Andrews
5 years ago
Views:

1 Xebia Security 1

2 Who Am I Dave van Stein - nl.linkedin.com/in/dvstein Security Consultant SecDevOps Engineer Embedding security and privacy controls in agile and devops environments

3 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 apps Open environment (www.kpn.

4 KPN Online Most internet facing applications and apps Open environment ( Selfcare environments (mobile & desktop) Consumer and small business webshop

5 A long, long time ago

6 -2013: project based Security requirements Penetration test Retest Afterfix Afterfix 2

7 2014: Agile transformation

8 Security & Agile?

9 One way to do it

10 A change from this

11 To this

12 While preventing this

13 Find a new balance

KPN Online Security Roadmap KSP s defined

security behaviours New / emerging risk &

implementation of Q&S framework Recognition

Web Application Security Multiple dashboard

Security advisory; Defined Q&S framework

responsibilities; Simplified communication &

14 KPN Online Security Roadmap KSP s defined Tooling capability Business alignment Operationalise Quality & Security (Q&S) framework Clear governance structure Embed security behaviours New / emerging risk & technology Regulatory changes Confidence in implementation of Q&S framework Recognition Q&S value Risk focused Business/IT Value Non - exis tent Not clearly demonstrated. Adhoc management Lack of business/it alignment; Unclear and/or no process documentation; Inconsistent processes; KPN Web Application Security Multiple dashboard reporting; Semi-structured assessments; Security advisory; Defined Q&S framework aligned with new WoW; Clear roles & responsibilities; Simplified communication & engagement; Voor intern gebruik Security awareness & training; Understanding of security risk; Maturity timeline Continuous monitoring of new threats and vulnerabilities; Complete & accurate reporting;

15 Policies

16 Split your policies

Policies governed within innovation I-theme Vision (team) Check (applicable Policies) Epics Ready (team) Features P B L Usr Stories D O R Scrum (team) D O D Product Operational (team) Global Detail

Pa) Second check on applicable policies will be done Invite / walk through features by Policy consultation (spreekuur) Policy assessor (invited by Ready Team) Check if applicable policies are covered

assessor (stakeholder during Demo) Launched Product Owner to Pa stakeholders Policy risk : High : invite for Demo Medium: check test results Low : no involvement Alle applicable policies /

17 Policies governed within innovation I-theme Vision (team) Check (applicable Policies) Epics Ready (team) Features P B L Usr Stories D O R Scrum (team) D O D Product Operational (team) Global Detail Legend Inform about themes Policy assessor (involvement responsibility of Pa) First check on applicable policies can be done Inform about Epics P C L Policy assessor (involvement responsibility of Pa) Second check on applicable policies will be done Invite / walk through features by Policy consultation (spreekuur) Policy assessor (invited by Ready Team) Check if applicable policies are covered and / or define extra requirements Invite / inform Go from Pa Policy assessor (informed by Ready Team) Check if all necessary and predefined policy requirements are covered within usr stories Policy assessor (stakeholder during Demo) Launched Product Owner to Pa stakeholders Policy risk : High : invite for Demo Medium: check test results Low : no involvement Alle applicable policies / requirements covered in product / deliverable Pa Policy Assessor PBL: 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 1 KPN Web Application Security Policies and Digital Innovation Voor intern gebruik

18 Covering KSP for Agile teams (process level) 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 level Prod 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 stakeholder Team 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 KSP requirements for the Agile innovation process

19 0 Have the needed level of security knowledge in project Who? Security stakeholder & Product Owner & Dev Team Accountability / Responsibility: When? Constantly 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?) Relevant KSP requirement ID Title Short Description KSP-FA06-RL01-R01 Security in Innovation Every project must have a security specialist capable of guiding the project KSP requirements for the Agile innovation process

During sprint Responsibility Team Members: Check if the proposed solution meets all requirements (KSP + additional) Scrum Master: Start exception management

20 6 Exceptions (if applicable): Impediment (blocking issue) on security requirement. Who? Scrum master (representing implementation team) & Security stakeholder (content) When? During sprint 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. Relevant KSP requirement ID Title Short Description KSP-FA06-ST01-R04 Exception management Any requirement that cannot be met must be handled via Exception Management. KSP requirements for the Agile innovation process

21 Security must become agile

22 Form a guild

23 Pentests

24 Waterfall vs Agile

25 Risk Profiling

26 Agile Risk Self Assessment

27 But there s more

28 Architecture

29 Standardize

30 Ground rules

31 Assess new blocks

32 Experiment

33 X Experiment

34 Thinks about the wrongs

35 Cause the bad guys do

36 Abuse cases

Requirements Test / Review Approval Maturity Tool (Quaterly) KSP

Assesment by 3rd party or internal ARSA: Agile Risk Self Assessment Pen

Periodically ARSA ARSA ARSA ARSA Scrum team 1 Backlog Scrum team 2 Backlog

and / or Major functional changes on existing systems 1. KSP Req tool 2.

37 Requirements Test / Review Approval Maturity Tool (Quaterly) KSP requirement tool Threat model Abuse cases Code Review / Vulnerability Assesment by 3rd party or internal ARSA: Agile Risk Self Assessment Pen Test / CR_VA results check by Security stakeholder Pen Test by Red Team Periodically ARSA ARSA ARSA ARSA Scrum team 1 Backlog Scrum team 2 Backlog Scrum team Backlog Build / Test Final Security approval Prod New Systems and / or Major functional changes on existing systems 1. KSP Req tool 2. Threat Analysis 3. Abuse cases 1. Security stakeholder involved 2. CR/ VA by 3rd party 3. Final Check PA Medium functional changes on existing systems 1. KSP Req tool 2. Threat Analysis 3. Abuse cases 1. Security stakeholder involved 2. CR/ VA by 3rd party 3. Final Check Sec. Officer Digital changes on existing systems within existing functionality 1. KSP Req tool 2. Threat analysis 1. No extra steps necessary or internal scan (VA) 2. Final Check Scrum Team Security by Design S&I Digital Low Security Risk Medium Security Risk High Security Risk

38 SecDevOps teams

39 Monitoring

40 Continuous security

41 Remember

42 Thank you, Q&A

Secur i t y by Design

Secur i t y by Design Easy talking??? DevOn summit March 30 2017 Arjan van Breemen Anticipate the difficult By managing the easy (Lao Tzu) March 23, 2017 1 SECURITY BY DESIGN in an Agile environment Before