Security in the Age of DevOps
We’re in the fight for the soul of… I’m not going to get political, but the reality is we’ve got a challenging road ahead in InfoSec. Security is facing a bit of an identity crisis. Okay, it’s more of an identity crisis for a function that has always been ill-defined, without clear success criteria, or the empowerment to impact change within an organization. That sounds pretty bad, doesn’t it? I assure you, it can get worse. (It’s not FUD if it’s true, right?)
As more organizations embrace DevOps and as tech decision-making takes place much closer to the business, information security must figure out how to add value in this environment. Developers have definitely not forgotten how difficult security made things through the years so they have really embraced the idea of not dealing with security in this new continuous integration/continuous development (CI/CD) reality. Our mission is clear: add value to DevOps without slowing things down. Sounds easy but it isn’t – and it probably doesn’t even sound that easy if you’ve worked in the industry as cloud has become more commonplace.
Key Security Functions in DevOps Environments
Let’s start by revisiting the key functions of security in this DevOps context. It’s something I call the 3 Gs:
You can’t expect developers and Ops folks to understand what security means unless you tell them. So this function is all about providing education in terms of what security looks like in a Cloud and DevOps world and how to get there. Part of this initiative is a security champions program to work with dev and Ops team members who will advocate for security. Here you can provide secure design patterns and a set of approved security tools to get the job done – knowing full well that some teams will decide what tools they’ll use, bringing us to…
The security function is the keeper and maintainer of the governance policies relating to cloud and DevOps. Basically this defines acceptable cloud use for the organization. The security team must also be able to substantiate that every team follows the policies Contrary to what some may say, compliance is still a thing. Piggybacking on the guidance initiative, the security team needs to make sure all appropriate teams understand the governance policies, especially the policies which cannot be violated, which leads to…
Every organization should have what I call the “no-no’s” – the situations that are never allowed because they result in unacceptable organizational risk. Examples may include an open storage bucket or unnecessarily permissive identity policy that could result in a full compromise of systems or customer data. That’s the kind of stuff that cannot happen. Period. So the security team implements guardrails around those situations to act first, ask questions later. Of course, there may be legit exceptions for some of these situations, but they should be just that – exceptions. You can’t take any chances.
The Process to Find the Right Fit Has Changed
Given what the centralized security function looks like over time, how can the DevOps teams pick security tooling that makes sense for their application? That’s actually a key nuance here. The governance policies mentioned above need to apply across the entire organization, but the reality is each project team or application has unique requirements. I’m old enough to remember when an enterprise could mandate a technology platform be used everywhere. Remember mainframes? If you wanted to do computing, that was the computing platform. Or Oracle as the RDBMS? You could use any database you wanted, as long as it was Oracle because you spent a ton of money on the site license.
Cloud and DevOps is different. You can build the infrastructure the application needs instead of being forced to use the infrastructure you have. This also means that security needs to become much more flexible because one size does not and will not fit all. You can (and should) have specific security policies and tooling that fits the application, not the enterprise. As long as teams follow corporate governance policies, DevOps teams should have the ability to make the best decisions for their applications.
Where is Security in the Age of DevOps?
Back to the question at hand. Security is everywhere and nowhere. Pretty existential, eh? Security must be a core consideration of every application stack that is built – so it’s everywhere. But things move way too fast for security to be a formal gate in a CI/CD world. Yikes! How do you get there?
It’s probably not a shock, but we believe a cloud security operations platform is necessary to achieve these goals. You need to be able to identify issues within the cloud and application stacks, get those enriched and actionable alerts to the appropriate party AND then be able to fix the issues within the tools the developers and Ops teams already use. It’s not about adding tooling or hurdles to the DevOps processes. it’s about fitting security into the emerging structures.