DevSecOps: beyond security, a cultural change

Looking beyond security assurance

Mature organisations have well established structures, processes and ways of working designed to keep information, and the systems that process it, secure. This is critical in the public sector, where many departments process large amounts of personal and often sensitive data.

These structures historically have involved deliver and operate functions, and then in a separate part of the organisation, an information security or cyber ‘blue’ team tasked with assuring systems.  

Separating assurance has acted as a helpful gateway before systems go live, keeping information secure.  The price is a degree of inefficiency.  At best, treating security as an assurance function slows releases and makes them more expensive; at worst, it can lead to an adversarial culture.  Security teams have not always been great at making their requirements relevant to business stakeholders and similarly, delivery teams haven’t set time aside to fully understand what is driving those security requirements. 

Bringing together deliver and operate with the advent of DevOps is increasingly seen as industry standard practice.  What seems to be taking longer is the evolution into DevSecOps, where security, too, is brought into the core of the delivery lifecycle. 

The path to DevSecOps is not well signposted

DevSecOps has become one of the most overused buzzwords in the industry, with many and varied definitions.  What does seem consistent are the main benefits organisations seek when they look to transition to DevSecOps:

• Reducing the cycle time required to release new systems or features
• Reducing security and privacy risk (i.e., demonstrably improving security and privacy compliance)
• Improved visibility of security decision making across all stakeholders.

Realising these benefits cannot be done solely through technical or procedural change. In our experience, the full integration of security delivery pipelines is as much a cultural and behavioural shift as it is a structural one.  On the face of it, these types of change can be hard to plan for and implement but are essential if organisations are to be successful in DevSecOps.  

With many organisations investing heavily in digital transformation and the enabling technologies, we would argue that there is no better time than now to harness this disruptive change and make DevSecOps a reality.

Organisations we have worked with who have most successfully realised the DevSecOps benefits have focused on common core principles:

• Making security a whole lifecycle discipline
• Protecting the route to live
• Making risk management agile and adaptive

In line with agile principles, the most successful also empower teams to start small, fail fast, learn and progress quickly. Strong leadership communication and ensuring a good awareness of the drivers and benefits of DevSecOps also encourages genuine cross team collaboration.

Making security a whole lifecycle discipline

DevSecOps leans heavily on building automated vulnerability scanning, and related vulnerability management processes, into the DevOps pipeline. Ensuring developers are following secure coding practices, are sighted on vulnerabilities, and are taking appropriate action is no doubt essential to building secure solutions. At Deloitte, we believe this is only part of the solution.

Building Secure by Design, and increasingly Privacy by Design, into imagine and deliver stages is also critical to ensure security is considered at the architectural level to avoid costly re-work later down the line.

Agile security testing as part of quality assurance (QA) helps identify any vulnerabilities which may have escaped automated tooling.

Ensuring security is properly embedded within live services enables rapid, adaptive changes to platform security controls as threat intelligence or the risk profile of the solution evolves.

Ultimately, organisations must remain adaptive and embed the right security interventions proportionate with the threat profile of the system, the sensitivity of the data it holds, and its mission criticality.  For our part, we always try to ‘push left’ in the DevOps process and have found the earlier in the process we can embed security, the lower the cost of security and the faster the pace of delivery.

Protecting value delivery

For organisations wanting to deliver software and services at pace, the route to live is everything.  This is the critical path of roadmap to release.  By decoupling the security function from delivery teams, it is too easy to drift from ‘enabling’ to ‘assurance’, where delivery leads need to seek permission to go live, and security can be seen as a blocker. The assurers, in this scenario, sometimes do not feel incentivised to get features out the door as they are measured solely on the security of the products.

Security must be not only integrated into the imagine, deliver and operate teams, but security team members must adopt the same delivery culture.  Leadership plays a pivotal role in ensuring a culture of early and open collaboration, driven by a shared vision with security at its core.

Everyone needs to be focused on value delivery to end users.  The subconscious question changes from ‘is this too risky to go live with?’ to ‘given what we know about the risk, how can we still go live?’.  We found this to be a subtle change in thinking, but a change that has led organisations rapidly reduced their release cycle time.

Agile and adaptive risk management

With security being wholly embedded in the DevOps pipeline, the concept of a separate ‘security programme’ becomes a thing of the past.  Often, there is not a dedicated budget for security activities such as time to remediate vulnerabilities, as well as the implementation of security controls in platforms and products.

As security requirements owners, we therefore need to prioritise:

1. Making security risks relevant to the business
2. Making prioritisation work

Making security risks relevant to the business

All security requirements must be described in terms of the business impact of not delivering the requirement, not just the security risk they mitigate.  Too often we have seen requirements struggle to be addressed because they don’t mean anything to business stakeholders, and security specialists getting frustrated because their argument that “it’s important because it’s a security requirement” isn’t landing.  

Making prioritisation work

Tied into the previous point, security stakeholders must play an active role in requirements prioritisation for a DevSecOps organisation to be effective.  They must have a seat at the table, and they must use it.  We frequently see a disconnect between business and security leads.  With a single shared backlog, all requirement owners must work in concert, considering the current security risk alongside the business value that needs to be released to manage an appropriately balanced backlog.

The time for change

DevSecOps can be game-changing in how it enables an organisation to deliver secure systems at pace, but can only be truly successful when organisational and cultural change are also addressed.

As a cultural change, it can be hard to engineer.  It is important to identify the right pilot projects, where there is a very real security need, staff them with team members who have the right balance of technical skills and the ability to communicate and see things from other perspectives.  Tying this in with initiatives already underway in support of digital transformation programmes is a good way of reducing costs whilst tapping into the existing skills and mindsets.  

There is no single out of the box approach that works for all, but transformational shifts to successful DevSecOps must not overlook the critical role of cultural and organisational change in fostering team collaboration, establishing effective new practices and marking clear business benefits and delivering on shared goals. In this, organisations and individuals can learn from others: the DevSecOps community is open and collaborative. Through successful and unsuccessful pilots, organisations will quickly learn what works for them.  We would recommend avoiding an over-analysis of the problem: start small, continually assess impact, learn from others and don’t be afraid to pivot regularly as you learn what works well and what could work better.