Security Rule One: You’re probably violating it right now

By now you’ve heard Security Rule Zero enough to know it by heart. You do know it by heart, right?

Just in case, let me refresh your memory:

THOU SHALT NOT TRUST USER INPUT. EVER.

Excellent. Now that we’ve got that fundamental rule established and out of the way, let’s talk about Security Rule One. Because as you may have guessed, there is more than one rule to security. So, let’s move on to rule one, shall we?

SECURITY RULE ONE: THOU SHALT NOT HARD CODE CREDENTIALS. EVER. 

In an age of access control via tokenization (popular for APIs) and federated identity, this rule is rarely broken for public facing apps. Where this rule is often broken and ignored is inside the organization. And it’s quickly becoming an issue as NetOps gears up its use of scripting and automation to do their part to optimize IT in support of their organization’s digital transformation initiatives.

Let me illustrate with one of the very real examples I found on the Internets. I say one, because I have neither the time nor the bandwidth to provide a comprehensive list. The practice is that pervasive.

To your right you will see a heinously common security faux pas: plaintext, hardcoded, credentials. There is not even a comment acknowledging it as unacceptable in a working environment nor a head nod toward the need to use a more secure method of authentication.

This troubles me deeply in the context of NetOps side because the blast radius is significantly larger when you’re messing with the shared, corporate network.

One of the reasons we see this kind of security issue is because although it’s true that NetOps is embracing automation, it isn’t necessarily adopting it strategically. What we’re seeing is a significant percentage of NetOps professionals who are picking up Python and combining it with a traditional, CLI-based method of configuration and management.

Just as they’d type in credentials on the command line, so they slap those same credentials in a script and call it a day.

Ultimately, this will be a problem. We will see someone take advantage of this practice and it will be in our news feeds for days. Because that kind of thing has happened before. Remember OneLogin? While they weren’t storing scripts with credentials, they were storing files with credentials. You can imagine the mess that made.

The thing is, NetOps might feel pretty confident in putting command line credentials in a script, but where does that script end up? Is it managed like it should be? Like infrastructure as code? Is it versioned and kept in a repository?

You might recall a Network to Code community survey that showed a high adoption rate amongst NetOps for (wait for it…) Github.

So let’s ask ourselves, where is our repository? Is it off-site? On-site? How is it protected, and what is the blast radius if someone gets a hold of it?

We need, for the sake of keeping up and serving the business, to scale operations via scripts and automation. NetOps has to move in that direction, but it shouldn’t do so without seriously considering the ramifications of plain-text credentials stored, well, anywhere.

At a minimum, scripts should require credential input upon invocation. Credentials should never be stored in a file or in the script, and certainly never in plain-text. Optimally, you’d use a more advanced credential management solution to force authentication and use tokenization across internal scripts. But I know right now we’re just in the burgeoning moments of mass adoption of automation in NetOps, and we have to take it one step at a time.

With that in mind, at least require credentials upon invocation. If that’s too difficult with your current implementation, then perhaps it’s time to step back and take a look at your overall automation strategy for IT. The first question being: do you have one? Or is what you’re doing a tactical (and primal) response to demands from the business?

Because the long term solution shouldn’t – can’t - be plain-text credentials in every script. Aside from the obvious security risk, consider the technical debt you’re incurring. If you have to change credentials, you have to change them everywhere. That takes time and effort to track them down. Time and effort you probably don’t have, otherwise you wouldn’t be so eager to make time by adopting automation in the first place.

So please, don’t violate Security Rule One. Be safer and smarter than that. Automation shouldn’t be a tactical response to scale and speed requirements. It should be – and is – strategic, and that means being more attentive to the long term ramifications of how you’re implementing it.