Thanks to the cloud revolution, development operations are now agile, in continuous deployment, and leveraging automation to accelerate QA and change management. Suppose security and compliance were to become native to the development process? In this case, they’d need to adopt a development operations (DevOps) that prioritizes speed of delivery and automation of workflow.
Alternatively, security operations (SecOps) and compliance have required a different focus than DevOps, prioritizing policy management, monitoring, code inspection, and risk mitigation. SecOps needs to anticipate risk and ensure controls mitigate compliance and security risk retroactively. The inherent conflict comes from a traditional view that security review should come after software development, like a final check. But instead, it becomes a troublesome process of reconciling necessary controls into the release cycle.
What I learned this week at the Atlassian Summit is that we need a new approach that allows risk and compliance to integrate security earlier in the software development and deployment process. Guy Herbert, Head of Risk and Compliance at Atlassian, calls this a journey, requiring DevOps to bring along teams like risk, security, and compliance into the shared responsibility of making the organization resilient to change.
Bringing about the shared responsibility can be tricky since there is a natural tension between DevOps and SecOps. They have various charters and cultures. DevOps is more of a “do culture” (Atlassian calls this a “Do-ocracy”), and SecOps resembles a “control culture”, and they tend to butt heads.
To reconcile these two approaches, DevOps and SecOps should align on three key objectives: collaboration, communication, and integration.
DevOps is a process for software development that emphasizes collaboration between an organization’s operations, development, testing, and support teams. The focus is on reducing time to market and improving agility through rapid development and rollouts.
However, before the development process can begin, you need to start with a plan. This is where security and compliance can be incorporated. Tugboat Logic’s platform enables an organization to build a record system that can implement and orchestrate the development plan’s SecOps portion. They can broadcast policies and controls across product and engineering teams to document the intention of controls. Beyond that, they can define control implementation and enable teams to collaborate with comments and feedback in one hub.
Equally vital is the need for security practitioners to bridge the communication gap between the security function and the rest of the dev organization. Other teams can view compliance and security negatively, especially if they don’t understand how it affects users. But you can improve this, too.
For example, instead of talking about a breach or a vulnerability, it’s better to address a security risk in terms of project delays and unplanned, unscheduled work. When speaking to operations teams, focus on availability and user privacy requirements related to response times or system uptime, rather than a data breach.
“Organizations will see more ownership at the coalface of risk management, and it will be teams, not lone geniuses, solving problems,” Herbert says. The teaming of DevOps and SecOps is the key to making security just another product requirement task and a natural business condition for the company.
To succeed in a world that’s moving at the speed of DevOps, security groups need to articulate control requirements in both the language and tools that DevOps lives in, such as Jira and GitHub. Tugboat Logic enables information security principles to be extended from an IT control directly into a task or issue within Jira. Once DevOps has closed out an issue, the Tugboat Logic can update its status as “complete” and enable an auditor to verify implementation status.
The high degree of automation and workflow tools in DevOps is often its most radical process departure for security practitioners. The critical success factor for blending security and development operations is to make control implementation easy and clear for developers.
For example, if the team’s working towards SOC 2, then a clear control framework broken down into tasks and issues will ensure a smooth integration of security into the development lifecycle. Tugboat Logic’s Security Certifications module is an example of defining requirements to achieve readiness for a security certification with controls gap analysis and audit-ready verification status in one place.
“The fact is that if you set the parameters and controls right, by automating, you will actually have better security,” notes Alan Shimel of Devops.com. “You have less human error, less drift,” because everything is configured to specifications that have already been proven secure and approved by the business. Shimel continues: “When you combine code injection analysis tools and automated penetrating tests earlier in the development process, it makes it possible for organizations to identify and eliminate security issues at every step of the development process.”
Bringing it Together
The truth is that automation and velocity in DevOps are fundamentally driving the business forward, and security needs to automate as well. The key to tying together security and development operations is the orchestration and demystification of security and compliance for the entire dev team. If you make it easy for developers to integrate security, you’ll have a more secure product and organization. Tugboat Logic provides you with the necessary glue to connect the different worlds of DevOps and SecOps.
PS: You don’t have to make a tradeoff between speed and security. Download The Enterprise DevSecOps Playbook for practical tips on integrating security into your SDLC and start building better, more secure apps, faster.