SecOps shares similar ideas to those driving the DevOps movement. DevOps introduces a framework that brings development, operations and quality assurance under a single automated umbrella. SecOps also seeks to join people, process, and only then tools, so that they can improve security and automate its deployment, management, and coverage.
Because of the current climate of software exploits for both public and internal facing applications, security has to be considered in the DevOps software delivery pipeline. Thus seeking ways to bring automated security into the DevOps strategy is important, even if they are separate entities.
Security is indeed a crucial piece of the DevOps puzzle. DevOps drives a range of misconceptions and myths surrounding security, as the focus on short release cycles with faster feedback loops seems contrary to the SecOps need for oversight, and control of variables. In addition to that SecOps is also concerned with corporate security, but the needs of application development and corporate security are very different, and hard to balance.
DevOps and SecOps also share similarity in the processes they employ:
- Component Monitoring: Precisely identifying vulnerabilities and monitoring for security threats across all components of the product.
- Software Oriented Infrastructure: Using virtualized datacenters or Platform as a Service (PaaS) solutions.
- Continuous Monitoring: Shortening feedback cycles and early threat detection across the infrastructure.
- Version Management: Rapid identification of security related incidents and failures while maintaining business logic with each build.
- Configuration Management: A unified approach to configuration between development, testing and production as Ops, QA and Devs work collectively to understand security requirement throughout the development lifecycle.
- Code inspection and Review: Using automated solutions and dedicated teams to shrink failure rates, improve code quality and enable security while Devs and Ops maintain continuous integration and delivery simultaneously.
- Benchmarking: Automated tools and dashboard solutions maintaining governance throughout the development lifecycle.
SecOps can be an inhibitor to Agile sprints in Dev and Ops processes, unless organizations embrace the necessary cultural shift. This means developers need to be more aware about security. And operations teams must work collectively with Devs and the QA police to ensure desired levels of security with each release. They also need to work together and have a plan to respond to exploits when, not if, they arise.
Although this appears as a distraction for development, iterating security risks and its involvement in development does align with the DevOps approach of quickly responding to customer demands. And when this strategy is used, products are secure from the ground up. And they are developed in the context of real-world security threats .
Unfortunately the catalyst for embracing SecOps in DevOps is when a particular exploit rattles the cage of the developers and operations involved. It can be embarrassing, scary, and the response downright draining. Just like company executives who often do not care about eDiscovery ( the process of culling documents associated with litigation ) until they get sued, developers do not care about security until it is breached.
Sony, recently faced a little of both. They are now scrambling to address lawsuits associated with a hack that SecOps, primarily contractors, now needs to backpedal and figure out how it happened. And then build a system to prevent it. Sony’s spend, and stress level is ten fold what it would have been had they thought about it before.
Internal Collaboration and Integration
The important thing to understand is that SecOps and DevOps can live together, they are joined at the hip. And the best way to do this is to have a subset of the SecOps team involved in development. Or even a resource in each applications DevOps team. And leverage the above joint processes, as an integration point. The SecOpsDevOps should treat the software delivery pipeline as their customer. And their offering is security that is consistent with the overall practices, but flexible enough for software to be delivered on time without a lot of hurdles.
But this also means that the SecOps team need to be flexible. Understanding that public applications and the infrastructure they sit on takes special security considerations. And because there is an inherent conflict of interest, the SecOps team should remain separate, as a governance body over the software delivery. But the combative relationship needs to stop.
The DevOps spirit encourages organizations to build the foundation of stronger IT security on three pillars: systems thinking, shortened and amplified feedback loops, and continuous experimentation and learning, which pretty much sums up the concept of SecOps. However SecOps and DevOps are not the same, and should remain separate. The real integration is of people who are willing to break down barriers to work together, and treat conflict as process bugs that need to be fixed.
Latest posts by Chris Riley (see all)
- DevOps Connect: Rugged DevOps at RSA - February 29, 2016
- Is SecOps, DevOps? - January 6, 2015
- Maven Component Management Brings QA Automation to Life - December 3, 2014
- Components as Process - October 20, 2014
- The DevOps Pipeline: People, Process, and Tooling – New Series - September 9, 2014