Continuous security: What’s in a name?
DevOps has changed the lives of programmers everywhere for the better. Giving engineering teams operational responsibility drives more robust offerings and better automation. Automation tends to improve development velocity and deployment time, leading to faster, more frequent deployments. Giving engineers responsibility for operations has also driven automation into scalability – many applications are now designed to scale elastically and automatically.
Security automation
Many companies have seen the benefits that automation has brought to product operations, and have asked themselves whether automation can impact security.
Security operations teams tend to drown in alerts and nearly half (44%) of security alerts go uninvestigated. And even for legitimate, confirmed incidents, more than half (54%) go unresolved. Many sources report that there are more than a million unfilled cybersecurity jobs, mostly in operations.
Development organizations similarly struggle to keep ahead of vulnerabilities, both in their own code as well as the code of the open source and other third-party software they leverage in their products.
It is clear that security is an overwhelming task in most organizations.
We’ve seen security automation dramatically drive down both incidents and personnel costs in organizations that have made the right investments, and we’re huge supporters of automation. What we don’t support are the confusing, derivative names people are using to describe initiatives for security automation. We’ve seen SecDevOps, DevSecOps, and DevOpsSec. All three have some traction, but none of them provide the kind of clarity that will encourage fast adoption of security automation.
What’s in a name?
With the DevOps movement, it was easy to understand that development teams were taking responsibility for operations and converting it into a development task, as the name reflected. Enterprises don’t seem to be following a similar path with security, even if they are investing in security automation.
Typically, security automation teams live in a separate security organization. This separation makes some sense, because security is a complex field requiring a lot of specialized knowledge, and for most regulated organizations, currently their headcount is still weighted to non-developers, even if they are investing in automation. Without the anchor to the development organization, starting with “Dev” doesn’t sound right.
Many security operations teams (as in, the team in the Security Operations Center (SOC)) already call themselves the SecOps team. If that team has developers doing automation, it might make sense to call that function DevSecOps (or SecOpsDev). However, many people using the term DevSecOps today (including DevSecOps.org) seem to be referring to automating security during the software development lifecycle (SDLC). In our experience, that kind of automation is done by separate people than those who automate incident response and other operational security concerns.
Focus on automation
A typical team doing software security automation is working to ensure that the software a company authors is as free of security problems as possible. To that end, they focus automation on things such as:
1. Automatically looking for known risky patterns in code, either via complicated static analysis, or simple heuristic techniques.
2. Automatically looking for known vulnerabilities in third-party and open source code (which includes keeping up with dependency issues).
3. Automating security tests and compliance checking.
4. Ensuring that code checks are run continuously, with each commit or each build.
In contrast, when security operations teams automate, they are more focused on automating around production systems, with activities such as:
1. Automatically detecting and closing spurious alerts that people would otherwise have to triage (and/or affecting the prioritization of alerts).
2. Automating the responses for valid alerts if at all possible, and to the degree possible (for instance, it’s not uncommon to take a ChatOps approach, and push actionable items into Slack).
3. Automatically “enriching” the data in alerts that should be triaged to remove the manual burden for investigators.
4. Build tools to be used by analysts to facilitate forensic investigations.
5. Augment the myriad of security signals and data sources to build additional detections.
6. Automate checking for TTPs and IOCs in live operational environments.
Both jobs are all about automating for security, but there’s minimal overlap. The first is about automation around the SDLC, and the latter is automation around production environments. Even when the code written in-house is the only thing deployed in the operational environment, enterprises tend to have different teams dealing with those separate concerns.
Choosing the right term
From a terminology perspective, it’s okay to lump all security automation under a single umbrella term. But we should use such a term to indicate that we’re talking about security automation in general, which is great when talking about engineering philosophy, business goals, etc.
But one term doesn’t help communicate what we mean when we talk about the jobs people do. For example, if someone claims to be a DevSecOps engineer, there’s not enough information to understand if they’re doing software security, or operational security.
Continuous security
At Capsule8, we like to use the term continuous security to talk about the engineering philosophy of automating security concerns throughout an organization. It nicely parallels continuous delivery, which is, in fact, a movement that has inspired a lot of security engineers to automate.
For the domain-specific roles, we tend to see a lot of the people doing security operations automation called “SecOps Engineers” (NOT DevSecOps engineers). This naming convention dovetails with the fact that they’re in security operations and sets them apart as developers since non-developers in a SOC tend to be titled “analysts.”
As for the software security domain, many people doing this job are called Security Engineers or, for more senior people, Security Architects. This role has long been more tightly tied to engineering (though traditionally off to the side) because they perform things like code auditing, and also indicates the people on this team have always been able to write some code. This role has also typically invested in automation, such as building automated static and dynamic analysis into the build pipeline.
Yes, as engineering organizations become the center of the universe in software companies, this role may start to move into the development organization. But we see no reason to rebrand the role as something both fancy and confusing. Let’s just keep calling them Security Engineers and Security Architects.
We don’t have to make everything look buzzwordy, especially at the expense of clear communication.