Cloud Infrastructure: Automating For Security

Hello!

The United States National Security Agency (NSA) just published guidance for mitigating cloud vulnerabilities. It reached my inbox via the United States Department of Homeland Security’s Cyber Infrastructure (CISA) mailing list.

The document covers a bunch of topics and I recommend reading the whole thing, but its “misconfiguration” section contains a guideline that’s extra-relevant to DevOps:

Use [Cloud Service Provider] tools or techniques, such as Infrastructure as Code, to reduce the risk of misconfiguration

I’ve seen misconfigurations behind major security vulnerabilities: once I found the private key of an SSL cert in an Apache web server’s DocumentRoot. It was readable by the entire Internet. This was an accident, an administrator had run the wrong copy command. Anyone in the world could have used that key to execute man-in-the-middle attacks. The NSA doc has more examples that are equally scary.

One of the biggest reasons to automate is that it makes this kind of human error harder. Humans will inevitably make errors, but when your infrastructure is deployed by code there are two new things that help protect you from them:

  1. You get more opportunities to spot the problem. A developer reading their own code will have a chance to see the bad path and fix it. When they submit that code for review by their team, the team will get another chance. Anytime anyone reads that part of the code for any reason they’ll get another chance. When deploying by hand, one person makes one mistake in a second of distraction and suddenly your private keys are public.
  2. You often import existing libraries and tools that implement their own security good practices. Instead of deploying certs and keys yourself, you are more likely to pass them as arguments to tools that are already written to deploy them safely.

I recommend automating everything. Even experiments. It’s better to bodge together low quality automation to build your test environment than to hack it together by hand. Even the exercise of writing low-quality automation will give you more chances to spot problems. I’ve also found that even dodgy automation encourages you to import well-written libraries simply because it’s easier to import than to write your own code. Robots forever! 🤖

Happy automating,

Adam

Need more than just this article? I’m available to consult.

You might also want to check out these related articles: