Automation Risks

There are a number of container and automation frameworks out there that seek to make scale as effortless as the click of a mouse. Some of them are rising quickly due to the excitement over containers, like Mesos and Kubernetes. Others have been around for a while—think Puppet, Chef, VMware, Cisco, and OpenStack.

The thing we sometimes overlook is that these tools are software. They’re apps, like any other. And as such, they’re bound to exhibit the same characteristics of other apps, namely security risks.

Consider this dive into Mesos and its rather laissez-faire authentication requirements:

The thing is, the default upon installation of Mesos at this time is to have no—I repeat no—authentication for frameworks, and no limitation on what those frameworks can see. If you use command line switches, you can modify this default behavior, but the default is still to be wide open where frameworks are involved.

https://devops.com/mesos-security-awareness-considerations/

Lest you think I’m picking on Mesos, I’m not. Similar issues are cropping up in other container orchestration frameworks, as well. And I suspect that if we dig into others, we’d find even more tidbits that would give security professionals palpitations. The point is not to pick on frameworks, but rather to ensure that you’re aware of the risks posed by operational apps inside the data center. Because one of the drawbacks of automation is that it’s hard to pull back on the reins once it kicks off. An errant command can propagate faster than mosquitos in a Florida swamp. Lacking controls on frameworks designed to scale and manage the infrastructure necessary for critical apps, the potential for significant damage to be wrought is huge.

After all, if I can take out one server with an API call, how many can I take out with a system that automatically propagates that call? And what else can I do? Force system updates? Change access rules?

As noted in the discussion on Mesos, there are options to enable controls and reduce the risk of an internal framework accidentally (or intentionally) being used to wreak havoc on infrastructure. As is likely true for most frameworks and systems being put into place to automate and orchestrate critical IT systems. But they often require action on the part of implementers. The key, then, is to be aware of the use of these frameworks and to audit their implementations and ensure proper controls have in fact been enabled in the first place.

The propagation of automation and orchestration frameworks to realize the economy of scale necessary to survive a digital transformation is inevitable. Along with them comes ——a familiar set of risks that security professionals need to not only be aware of, but also take the initiative to ensure they are addressed before they become an existential threat.

Set aside some time to inventory the frameworks in use today in your environment and understand how they’re being used as well as what (if any) security controls are being employed to ensure that risk doesn’t become an existential threat.