Enterprise infrastructure, integration and solution delivery are enjoying significant acceleration as a result of the “as a Service” model. The slower Waterfall approach to software iteration has yielded to the Agile methodology, which enables fast and continuous development and delivery. Automation must be a component of Agile to accelerate quality assurance and change management.
As all this change takes places, a more foundational goal is to make security and compliance part of the development process from the start. In order for this to succeed, teams must take on a DevOps mindset regarding these aspects. If security and compliance are to become native to the development process, then they need to adopt a development operations (DevOps) cadence of sustained engineering that prioritize speed of delivery and automation of workflow.
What’s difficult here is that, until now, SecOps/compliance and DevOps have had different priorities. SecOps needs to anticipate risk and ensure controls are retroactively mitigating compliance and security risk. DevOps focuses on things like policy management, monitoring, code inspection and risk mitigation. The inherent conflict comes from a traditional view that security review should come after software development as a final check but instead ends up becoming a fractious process of reconciling necessary controls into the release cycle.
This is a transition that requires DevOps to bring along risk, security and compliance teams into the shared responsibility of making the organization resilient to change. But bringing the idea of shared responsibility to fruition can be difficult because there is a natural tension between DevOps and SecOps, as they have different charters and cultures. DevOps can be seen as more of a do culture (Atlassian calls this a “do-ocracy”) and SecOps can be seen as a control culture and they are inherently in conflict. To fulfill the promise of teaming for shared responsibility, DevOps and SecOps should align on three key objectives: collaboration, communication and integration.
Why collaboration?
DevOps is all about recognizing and relying on the interaction between development and operations, including testing and support teams. The focus is on reducing time to market and improving agility through rapid development and rollouts. However, before the process of development can begin, you need to start with a plan. At the planning stage of development is where security and compliance can start to be incorporated. Organizations need to build a system of record that can implement and orchestrate the SecOps portion of the development plan. Policies and controls can be widely disseminated across product and engineering teams to document the intention of controls, define their implementation and enable teams to collaborate with comments and feedback in one hub.
Cross-functional communication
Between the security function and the rest of the development function lies a communication gap, and it is a critical necessity that security practitioners bridge that gap. Compliance and security can be viewed pejoratively by other teams because people don’t understand them or see their relevance to users’ lives. But this, too, can be changed.
Breaches and vulnerabilities don’t mean as much to the dev team, so it makes more sense to talk about a security risk in terms of project delays and unplanned, unscheduled work rather than talking about a breach or a vulnerability. When speaking to operations teams, it’s better to talk about availability and user privacy requirements as correlated with mean response time or system uptime rather than a data breach. To succeed in a world that’s moving at the speed of DevOps, security groups need to be able to articulate control requirements in both the language and tools that DevOps lives in, such as Jira and GitHub.
The need for integration
The high degree of automation and workflow tools in DevOps is often the most radical process departure for security practitioners. The critical success factor for integrating security and development operations is to make control implementation easy and clear for developers to follow. For example, if the team is working toward a SOC 2 security certification, then a clear control framework broken down into tasks and issues will ensure a smooth integration of security into the dev cycle. A SOC 2 attestation will also require evidentiary verification that controls are implemented throughout the software development lifecycle (SDLC), including release cadence. The final critical piece to achieving readiness for a security certification is to have integrated risk assessment, controls gap analysis and audit-ready evidence for your observation period in one central place.
Collaboration breeds security
The heat is on to iterate rapidly and continuously in a world where everything is offered “as a Service.” To make this possible, the DevOps methodology relies on the speed that comes through automation. But security is sometimes overlooked in favor of speed. That means security needs to automate, as well, to keep pace with continuous delivery. The division of DevOps and SecOps must be bridged to create DevSecOps.
When organizations realize the advantages of DevSecOps, they will be more willing to do what it takes to create a smooth transition. Still, they will also need to learn how to describe these advantages in a way that makes sense to everyone involved. Collaboration is enabled when the entire dev team can see and take part in an orchestration and demystification of security and compliance. There will no longer be any reason for developers to not integrate security once it’s clear and simple for them to do so. The end result – and the ongoing result – will be stronger security.
