We all agree we need to secure DevOps, but what should we call it?
In previous articles we’ve talked about the need and challenges associated with securing DevOps environments.
It’s a complex topic. At the root of the matter is the fact that it has to do with the overlap of the three main functions in any organization:
- Application developers (Dev) who must quickly develop and iterate applications designed to move the business forward. However they do not have the tools or the skills needed to include “must-have” advanced secure features, such as encryption, during the build process
- InfoSec (Sec) resources who are charged with the network infrastructure (on- and off-prem), including data security. InfoSec is usually left out of the existing DevOps model, so when production tests rolls around, they are forced to play catch-up.
- Finally, operations (Ops) who are often in charge of the success of the lines of business and must make sure the business is running as efficiently and effectively as possible.
Clearly, securing DevOps is an important topic, and one that has the full attention of developers, InfoSec teams, CISOs, and almost everyone else in the industry today. Yet while we can all agree that we need to do a better job, there’s less agreement on the approach, which contributes to confusing terminology.
What should we call it? Secure DevOps, SecDevOps, DevSecOps or DevOpsSec? And is there a real difference between the terms?
What’s in a name?
A quick Google search produces results for SecDevOps (93,000 searches), DevSecOps (435,000 searches), and “DevOpsSec,” (21,000 searches). But, can they be used interchangeably?
To help shed some light, we thought we’d take a closer look at three terms, see what they really mean, and show you which one CSPi prefers:
- DevSecOps: So what is DevSecOps? If we break this down, you can see that Dev leads the pack and is given the highest level of importance.
On one hand, we give this term credit for including security as part of its name. But this approach still doesn’t overcome the inherent conflict: Developers don’t have the simple tools, or skills to secure applications from the beginning, and InfoSec teams are potentially brought in too late to address security concerns.
As a result, DevSecOps represents the scenario we are in today – a situation where security doesn’t get the prioritization it deserves.
- DevOpsSec: What is DevOpsSec? If taken literally, this version places security at the end of the line, after discrete development, deployment, and operations activities.
Such an approach is extremely risky to an organization’s critical assets as it’s a strong possibility that applications are put into the field unsecured or not fully tested. From an operation’s perspective, once the handoff occurs, they want the app put right into production, but security will likely be the block and cause inherent friction between the two functions goals.
It’s easy to release applications with the rationale, “We’ll patch as we catch bugs.” Yet from security’s perspective, patching simply can’t keep up. For example, the 2017 Equifax breach was caused by a missed patch on an open-source application.
- SecDevOps: To borrow from “Goldilocks and the Three Bears,” this approach is just right! According to this insightful article on CSO.com, SecDevOps refers to the inclusion of security efforts and best practices into the continuous integration and continuous deployment pipeline. It also suggests that security requirements are taken into account before development to ensure security is included throughout the product lifecycle.
Additionally, SecDevOps includes InfoSec teams as part of the development pipeline. This approach attempts to address previous shortcomings by automating and integrating security solutions are part of the core development process – and not as a clunky, “afterthought” function that may only disrupt the entire production process.
Where do we go from here?
Overall, it is a positive trend that the popular and beneficial DevOps model is now taking security into consideration. This is a big improvement from just a short time ago. It’s clear that security is becoming a top priority.
Security breaches keep happening, with no indication of slowing, and new stringent PII/PHI data privacy laws are coming online – like PCI DSS, GDPR and 23 NYCRR 500. We believe that the term “SecDevOps” will become the de facto standard as taking security into the account at the beginning of the development process will have the best results.
At CSPi, we are tackling the gap between application development and security head-on. Our ARIA Software-Defined Security (SDS) platform provides simple-to-use connectors ,which when applied insert the desired security features, without any additional coding.
This solves a couple of problems:
- Application developers have the tools they need at the start of the design process. They also don’t need to change their normal development process to learn complex security features. This allows them to do what they are being charged with – quickly build and iterate applications.
- With security included at the front of the DevOps process, InfoSec resources know that the application has the security features incorporated. This means they don’t need to play catch-up to determine whether the application will be risky to production data, and thus, become a bottleneck to release.
These two benefits alone are huge! Yet, ARIA goes one step further and gives InfoSec team the power to automatically discover and activate security policies within applications, as well as the data within or produced. Just think of the possibilities the speed and agility of DevOps paired with security built into development AND automatically enforced. This is definitely a win-win and SecDevOps is at its core.
Interested in learning more about SecDevOps tools, and what makes CSPi solutions different? Download our white paper, “How to Secure DevOps Across Any Environment,” view any one of our on-demand webinars, or contact us today.