Ship on day one

Here’s How DevOps and InfoSec Can Coexist

May 9, 2018

Securing your software delivery system is easier than you think, and the Polyverse CTO has some thoughts on how to make that happen in a DevOps environment.

Archis Gore isn’t one for sugar-coating things, especially when it comes to the way most engineering teams handle security these days. “I have some very strong opinions,” he says. “But they come from a place of having been there and done that.” What he’s referring to, specifically, are the two years when he was responsible for Amazon Search across Black Friday and Cyber Monday. That experience informed a lot of what he’s doing now at Polyverse, where as CTO he’s focused on giving operators an arsenal of options, rather than pointing out what’s wrong. At the Get Ship Done! Workshop, he’ll expand on that and hammer home his main philosophy: Simple is secure.

What’s your assessment of the information security landscape right now?
In my opinion, everything that people are doing is wrong. It’s wrong because everyone has this urge to want to do more. So in the urge to do more, we come up with problems that we then want to solve, which hurts our cause. Everything would be more secure, better, easier if we simplified.

 

I get what you’re saying about simplicity, but I can also see the argument for lots of levels of security. Because it’s only natural to want to make something as secure as possible.
I have this philosophy: You should have a few simple enforceable rules, and no exceptions. I hate exceptions to rules. If you add an exception, open up the rule. Always. Because any time a rule becomes complicated and cannot be interpreted correctly, it gets broken.

How so?
Let’s say you have six passwords to access your software. You’re going to end up reusing at least one password. So complexity can actually make us insecure by encouraging people to bypass the rules you’ve put in place. So the key part of security is to do enough that people will put up with it — and ideally won’t even know that they’re doing it. The fundamental thing is to accept that there will be some failures. You’re not aiming for 100 percent reliability. You’re fighting the war for sigma, the war for nines.

There are a lot of concerns among infosec teams that what they do isn’t compatible with DevOps. Why shouldn’t they be concerned?
This is where simplicity comes in. Security teams never take over a problem, which means that an engineer that goes into DevOps has to now own an extra thing: “I have to do dev, I have to do ops, and I have to make it secure. And I have to make this thing run, which hardly ever runs.” So the way you combat that is to find solutions which are operationally viable. You always want to make sure that a solution that you ask your engineers to use is operationally easy. Easy does not always mean insecure or bad, and you have to give them that leeway.

Can you give me an example of the kind of simplicity you’re talking about?
When people do deployments, they do deployments based on labels. Like, someone will say, “This is v2.” But what does v2 mean? There’s a way around that called content-based addressing, where you actually address the content. You hash it, and the hash becomes a signature. And it is unfakeable. Ideas like these are very simple to implement. You just have to be goal-based. And I think that’s the part where most DevOps people get confused: What is the goal? What is the purpose of signing? What is the purpose of encryption? From whom? So security people come in and they’re like, “Encrypt your data.” Against whom? For what? And where?

How are philosophies toward security and DevOps changing?
If you go back ten years and start looking at articles on site reliability, you’ll find a lot of articles about these NASA-quality, hard-standby servers with double backup power supplies. They never go down. What we do now is assume that some parts of the software will fail. So instead of “hardened,” the correct word to use is “tolerant.” You don’t build fault-hardened systems. You build fault-tolerant systems that tolerate the fault. But most leaders don’t like tolerances. They want hard. So this is a fairly new concept, except for someone who’s on the frontlines of Twitter, Facebook, Amazon, Google.

So let’s say I’m a frontline engineers at any company other than Twitter, Facebook, Amazon, or Google. How do I convince my boss that we need to go for “tolerant” as opposed to “hardened.”
That’s a tough one. I would say, “Look at what those top-tier companies are doing.” A data breach at Amazon would basically mean the death of the company. The company’s reputation depends on them remaining secure and up and working. If a company whose entire reputation depends on that accepts that failures happen, then I think it’s okay for everyone else to accept that, too.

 

Related Content