Automating a DevOps-Friendly Security Policy

Much has been written about the need for a balance between DevOps and security architecture. While DevOps is all about getting whizbang apps to market as efficiently as possible, the security team is often portrayed as the party pooper — folks who tell you why you can't do something instead of how you can do it.

There's a similar clash of missions between the security team and the IT operations team. Security can be disruptive to IT Ops, with requests that can seem arbitrary and needlessly time consuming. IT Ops generally has the goal of simply keeping things running — even if this opens opportunities for bad actors.

Security has a strong case for wanting what it wants and for not wanting what it doesn't want. Security vulnerabilities are rising at an alarming clip — data theft, leakage of intellectual property, corporate sabotage, denial-of-service attacks, and more. A company's profits, reputation, brand, and even viability are at stake. But the relentless march of commerce takes no prisoners. Any company that's hamstrung from acting with speed and agility is pretty much already dead on its feet. So, we find companies willing to accept risk that those in charge of security see as unacceptable, and implementing solutions that may be insecure.

It's a tension that raises its head frequently for us at HyTrust. Our customers routinely face this tension when they try to implement our offerings. The security team wants to do X, but the IT Ops team does not want to do X. In one recent case, a client's security team wanted to implement our solution, but the IT Ops team put up roadblocks every step of the way, with a list of reasons why our offering wasn't a good idea. In this case, those on the Ops team feared the rollout would expose process flows they hadn't been following — weaknesses that made the client vulnerable.

An Unsafe House
Security architecture work is like building a safe, compliant house. The problem is that the builders made it so hard to lock the windows, turn on the security system, and operate the surveillance cameras that the inhabitants leave these tasks undone. DevOps promises to make life in the house a comfortable and efficient experience, but without a security policy that is friendly to DevOps, this promise is never fulfilled.

In a recent "Ask Me Anything" session on Reddit, Mike Foley described this problem. Mike is a senior technical marketing architect at VMware whose main goal is to help IT admins build secure platforms that stand up to scrutiny from security teams with the least impact to IT Ops. Asked what he thought was "the coolest new security toy" in the recently released vSphere 6.7, Mike said virtual Trusted Platform Module (vTPM). But it's the rationale he gave that's germane to this post:

"I like the balance of security and IT operations impact. Let's face it, if I'm an IT guy and security comes to me and says I have to do a bunch of things that I know are only going to 'make work' for me, then it's no longer a technical discussion. It's political. And everyone loses. If, as an IT guy or gal, I can meet the security requirements of security with the least impact to my day-to-day operations, then I'll be much more open to enabling those features."

Mike used VM encryption to illustrate what he means, then added: "It's the same with virtual TPM. I'm not having to completely re-jig my environment to support this need."

Automating Doing the Right Thing
No one wants to "completely re-jig" their IT environment without good cause. One reason those in charge of security don't always make a compelling case is that many security and compliance monitoring tools haven't kept pace with the times. They certainly weren't built to test code at the breakneck speed DevOps requires.

The good news is that security can take a page from the DevOps playbook — in particular regarding automation. DevOps encourages automation, and as I argued in a previous post, I favor an approach to security that automates doing the right thing — that automates ethics for cybersecurity. That's because most security breaches and system failures result from human mistakes. Automating the right thing takes a load off security architects. It spares them from having to configure security consoles manually. It reduces the chances of human error.

What is the right thing? When it comes to risk, most companies already have clear governance of what they consider it to be. From this, they derive their security policies. A security policy is whatever you decide is the correct behavior, based on experience. The next step is to bake these policies into your processes — which puts us squarely into DevSecOps territory.

This is a hot topic. In a 2017 survey, Gartner found that the issue of how to securely integrate security into DevOps — delivering DevSecOps — was one of the fastest-growing areas of interest of clients in the preceding 12 months. A key finding was that information security must adapt its security testing tools and processes to developers, not the other way around. As more companies embrace DevOps principles to help developers and operations teams work together to improve software development and maintenance, they're increasingly automating security in this way. In fact, the Gartner report predicts that DevSecOps will be embedded into 80% of rapid development teams by 2021.

Automating doing the right thing is key to a DevOps-friendly security policy — a policy that's also friendly to IT Ops. Going back to the "Ask Me Anything" session on Reddit, one poster joked that Mike's focus on minimizing impact to IT Ops was "the lazy man's approach." Mike's terrific comeback: "One man's lazy is another man's 'I have only so much time in the day.' :)"

Related Content: