Here’s a simple question: for each tool that your organization uses, have you (or someone else on your DevOps team) changed the default passwords? That should be a no-brainer, shouldn’t it? Of course you changed them! Or at least you changed them for the tools that looked like they would have default passwords. Well, OK, at least the ones that looked like they might present an obvious security risk — and where you noticed that there was a default password. Would those other tools even provide an intruder with a useable exploit?
Anything that lets a burglar into a house is a good way to get in — it doesn’t have to look like a security hole to you, as long as the burglar knows how to exploit it. And that’s the way it is with any tool. Does it encrypt passwords, or just store them in a sort-of-hidden text file somewhere? Other people’s passwords are very nice things to have if you’re up to no good. Does it provide easy root access without even requiring a password? That’s even better!
What does this have to do with DevOps? Everything. DevOps relies heavily on scripting, on a set of widely-used and generally open-source tools, and on interaction between those tools. It places a premium on rapid, efficient action, and it frequently involves giving a relatively large number of people access to scripts and tools. One of the major goals of DevOps is to automate the entire pipeline from development to release.
The flexibility of DevOps also opens the doors for any developer to bring their own open-source (OSS) component. The problem is these components also have their own security risks. Do you know if their is an exploit in your OSS or commercial component? Do you know when there is a patch that you should install? And because OSS uses OSS the potential issue compounds rapidly. Remember Heartbleed?
To quite a degree, these are the qualities that give DevOps its value, and very few people who have been involved in DevOps or who have seen its benefits would want to give them up. But DevOps doesn’t come with a magic shield that makes it immune to traditional (or non-traditional) security risks. That should be obvious, but all too often, it isn’t. If you’re used to thinking of DevOps as the revolutionary solution that makes everything else obsolete, it’s easy to forget that revolutions still have to deal with everyday problems like system security.
And the use of relatively new or less common tools carries with it its own risks. If a basic system utility has been in wide use for the past twenty years, its key vulnerabilities are probably well known to both the black hat and the white hat crowd, and there will be patches for those vulnerabilities. But that accumulated body of knowledge is the result of a process that takes some time, and is likely to involve at least a few major security breaches along the way.
If you’re using newer and less security-hardened tools, that process of discovery (with all of its built-in risks) is still going to be in the early stages, and the most reasonable assumption that you can make is that each of those tools includes some major, undiscovered vulnerabilities that may result in serious problems for your operation. When you use DevOps tools that have not been through the fire in terms of security testing, you are in effect bringing your own exploit to the party.
But what can you do to maintain a sufficiently high level of security? It doesn’t make sense to simply stop using the basic tools of DevOps automation, or to disable them to the point where they’re useless. What does make sense is to integrate your organization’s security team into your DevOps team, and vice versa, so that they both become part of an overall DevOps-SecOps framework.
This means that DevOps will be responsible for carrying out its part of a clearly-articulated security policy (by tracking down and changing all default passwords, and requiring passwords and encryption where they are not required by default, for example). It also means that the organization’s security team will be fully aware of the high potential for currently unknown exploits in the basic DevOps toolkit, and will take the necessary precautions to protect those tools from intrusion. More than anything, it means that DevOps and the security team will work closely and cooperatively on these and other points of potential vulnerability.
Or to put it another way, DevOps can’t afford to let security stay in its own silo (or to imagine that it is safe by hiding inside of a big and largely imaginary DevOps silo). What’s the cost of siloing security? consider this fable:
Once upon a time, a well-known (but entirely fictional) software company decided to release a seamlessly integrated operating system — one where there would be no boundaries at all between the user’s local system, the local area network, the Internet, or the cloud, where even the boundaries between applications would be eliminated.
The development teams that worked on this operating system understood that this integration brought with it potential security issues, but they also understood that it was their job to provide the integration, and not to worry about security. They assumed (or hoped) that the security development teams (with whom they had no contact) would wrap the entire system in such an airtight bubble that nothing could get in and wreak havoc.
Unfortunately, the teams that were working on security assumed that the system developers would build a full set of reasonable security features into the operating system itself, so they concentrated on protecting it from the more well-known points of attack from the outside. In other words, the system development and security teams were completely siloed.
Unfortunately for the well-known (but completely fictional) software company, hackers (some of whom were not nice people at all) soon discovered that system was full of back doors that had been left wide open, and the company spent the next decade patching holes and dismantling many of the features that it had once been so proud of.
The moral? It doesn’t pay to integrate everything else and keep security in a silo. It’s better to integrate security from the start, and make it a partner in your integration with the rest of the world.
