How to shift from compliance to proactive security

Size: px

Start display at page:

Download "How to shift from compliance to proactive security"

Charleen Fleming
5 years ago
Views:

1 How to shift from compliance to proactive security and make engineers your competitive advantage Răzvan Tudor, Chapter Lead, ING Tech Cloud & Cyber Security Expo, London, March 2019

Whoami Răzvan Tudor Chapter Lead IT Security @ ING Tech Romania.

2 Whoami Răzvan Tudor Chapter Lead IT ING Tech Romania. Leading a couple of squads with focus on Security Engineering and general IT controls. 10 years + experience in IT Security & IT Risk domain mostly in financial services. Travelling, sports, reading, music, history. 2

3 Agenda Why? What is engineering journey? How does compliance/security fits in the model? Security Champions training Engineers Engineer: what s in it for me? Security in the Agile Way of Working Questions? 3

4 Why do we need to push security into engineering journey?

5 One reason - Ju$t becau$e Image source: Jim Routh Defects observed in production significantly increase the remediation cost. Though nobody acknowledges situation is just slightly improving year-on-year. 5

6 Industry is improving but still space to get better 6 Image source: State of Software Security 2018, Veracode

7 A second reason every company is a tech company How do performing companies approach security? Approach 1: Security is the responsibility of individual product team Approach 2: Security is the responsibility of the security team 7

8 Quick look into engineering journey

9 Engineering journey using continuous integration & delivery Onboard & Plan (define) Build & Test (create) Release (orchestrate) Design & Code (digitize) Deploy & Test (assembly) Operate & Maintain (detect & correct) 9

10 How to add Compliance & Security to engineering journey Onboard & Plan (define) Build & Test (create) Release (orchestrate) Normal journey 10 Design & Code (digitize) SR PR SAST Outside of Normal journey SR = Security Requirements PR = Peer (Code) Review SD SD = Secure Design SAST= Static Analysis SC= Secure Configuration SCA VA SC Deploy & Test (assembly) DAST PT SCA = Secure Components Analysis DAST = Dynamic Analysis RD = Responsible Disclosure PT= Pen Testing Operate & Maintain (detect & correct) VA SC PT RD RBT VA= (Infra) Vulnerability Assessment RBT = Red & Blue Teaming

11 Quick look into a sprint from engineering journey

12 Indicative 2 weeks sprint from engineering perspective Day 1 Day 2-12 Day 13 Day 14 Start (Planning) Engineering Deploy Finish (Retro) 12

13 Indicative 2 weeks sprint from engineering perspective with Security & Compliance Day 1 Day 2-13 Day 11 Day 12 Day 13 Day 14 Start (Planning) Engineering Security Work Finalize Security Work Deploy Finish (Retro) Day 7 Do I need specific Security help? SR SD PR VA SC SAST SCA PT DAST 13

14 Agreed on journey but how does security fit in the model?

15 Let s make it clear When shifting from compliance to proactive security is a matter of Tooling Know-how 15

Tooling Onboard & Plan (define) Build & Test (create) Release (orchestrate) Normal

Requirements PR = Peer (Code) Review SD SD = Secure Design SAST= Static Analysis SC=

Analysis DAST = Dynamic Analysis RD = Responsible Disclosure PT= Pen Testing Operate &

16 Tooling Onboard & Plan (define) Build & Test (create) Release (orchestrate) Normal journey 16 Design & Code (digitize) SR PR SAST Outside of Normal journey SR = Security Requirements PR = Peer (Code) Review SD SD = Secure Design SAST= Static Analysis SC= Secure Configuration SCA VA SC Deploy & Test (assembly) DAST PT SCA = Secure Components Analysis DAST = Dynamic Analysis RD = Responsible Disclosure PT= Pen Testing Operate & Maintain (detect & correct) VA SC PT RD RBT VA= (Infra) Vulnerability Assessment RBT = Red & Blue Teaming

17 Know-how through a Security Champions/Satellites Program Source BSIMM v9 Satellite In addition to the SSG (Note: Software Security Group), many SSIs (Note: Software Security Initiative) have identified a number of individuals (often developers, testers, and architects) who share a basic interest in software security but are not directly employed in the SSG. When people like this carry out software security activities, we call this group a satellite. Twenty-seven of the 30 firms with the highest BSIMM scores have a satellite. Source OWASP 17

18 How to Source: OWASP Map teams where approach works (start simple) Set clear role description for Champion/Satellite Keep the process open Clear onboarding criteria (prerequisites) Keep it live, maintain interest (newsletters, security library, meetings) Approach it as a Trust but Verify 18

19 Takeaway Security Scale up with limited resources (Security) coaching & mentoring Secure artifacts Secure by design (and practice) Engineers Better understanding of security and compliance Faster release cycle Responsibility Autonomy Predictable Faster release-cycle Secure 19

20 Measure maturity Not really a process Basic things in place Autonomy but Trust & Verify Security in DNA of team

21 Some tips Managing the program / keeping the community engaged and motivated not easy thus you need to dedicate time Need to continue to build trust and have a positive attitude, especially when dealing with reluctant teams Everything Should Be Made as Simple as Possible, But Not Simpler Engage with teams to secure time for security activities Have a Security Champions program manager not necessarily full time Achievements, leaderboards, top performer award 21

22 Q & A

Suman Sourav Director DevSecOps, Vantage Point Security. OWASP Indonesia Day 2017

Suman Sourav Director DevSecOps, Vantage Point Security OWASP Indonesia Day 2017 About me Certified Secure Software Lifecycle Professional (CSSLP) 12+ Years of Experience in Software Security Co-Founder