Building a DevSecOps capability - Making the transition to agile security

The Challenge

• The autonomy granted to the delivery teams can preclude traditional security assurance quality gates

• The pace of change challenges traditional security assurance methodology; including people, process and technology

• A broader selection of technology is likely to be in play, both from an infrastructure and development perspective creating a diverse portfolio to understand and secure

Key steps to a successful DevSecOps capability are:

1) Buy in

High level management buy in to security which is cascaded down the organisation from the top, directing the message that security is both important and everyone’s responsibility.

2) Education & collaboration

Knowledge is key to successful change; a team cannot be given responsibility without first having the knowledge to fulfil the responsibility.

If done correctly this can be a springboard for tighter integration between development and InfoSec, with InfoSec providing fun education sessions around key findings from previous security reports.

These should include exercises where the developers use attackers’ methodologies to exploit vulnerabilities, so they can see how the exploits work and understand the impact of a vulnerability. Depending on the corporate culture working party sessions with Pizza, caffeine and/or beer can go a long way to building bridges between teams and adding to the fun.

‘Give a Dev a pen test finding, and they will fix a vulnerability in one app. Teach a Dev to exploit SQLi and they will use prepared statements and parameterised queries for the rest their career’

 3) Clear responsibility and measurement

Security should be measured as a quality aspect, prioritised in backlogs and included in employee objectives. This is particularly true of the owners of the backlog, security items in the backlog will not be prioritised without measurement of meaningful security metrics, and the reporting of those measurements at an appropriate management forum.

4) Make it easy

Security tooling should move out of the security team into the DevOps teams to operate, incorporate into build and release processes and self-serve as much as possible.

Security teams should work on making security easier including converting standards into code where possible, writing security checking functions and publishing to code repos and supporting DevOps in building in recommended controls in desired state configuration tooling.

‘Build it (in code) and they will come, PDF it and it will gather dust’

The security function shifts slightly into support and audit to validate that the tools are being used appropriately, consistently and findings are being remediated and constantly making compliance easier.

The goal of the tooling is to make security automated, frictionless and integrated into processes owned outside of InfoSec.

5) Empowerment

DevOps teams should be empowered to fix security issues identified, dedicate time to continuous improvement of the product and tooling.

Part of the empowerment should be co-owning education and working with InfoSec on onboarding education and continuous improvement between the teams.

Security at pace and security in agile are challenges recurring across the industry, Savanti have a wealth of experience in this area, we have integrated security into DevOps functions across large organisations and have the experience to deliver a security capability that integrates and supports agile delivery at pace while reducing risk.

We’d be happy to support you on the journey, please get in touch – info@savanti.co.uk or visit the chat function on our website: www.savanti.co.uk