Got microservices? You’d better secure them

One of the toughest parts of being a computer security pro is trying to figure out what to hang your career on every two to five years. Which new buzzwords will stick to become a new paradigms, and which will disappear into the ether? Keeping up with the latest and greatest enterprise tech is part of my job, and no source does it better than InfoWorld, but some “new” trends still end up surprising me.

In 2016, we learned that the emerging ecosystem of containers, microservices, and cloud scalability is not a fad. But it does present new security problems.

Securing containers

In 2015, I talked about securing containers, which were popularized by Docker, and are now used throughout the industry and supported by most industry players. Often inaccurately described as “micro-VMs,” containers hold packaged pieces of software that contain all the components (the software itself, system libraries, the file system) needed to run that software. Containerized applications share a single instance of the OS, rather than running copies of an OS like VMs do.

Since that 2015 article, a handful of companies have offered solutions to help you secure containers, including more default security and support from Docker itself. How hard is it to secure containers? The short answer: It depends on the scenario.

Because applications can be abstracted from the operating system, it’s easier to patch one without necessarily impacting the other. At the same time, containers introduce an additional layer of complexity, so container deployments are harder to secure.

For one thing, a great benefit of containers is that developers can create and share images much more easily than ever before — raising the risks of propagating images containing flaws or malware. Also, root access to the host OS provides an access to all containerized apps. Read this article by Amir Jerbi of Aqua Security for an excellent rundown of these issues.

Securing microservices

You need to add microservices to your security planning, too. Microservices are the modern method to create web and mobile applications: You break down functionality into separate mini-applications that are loosely coupled by RESTful APIs. Martin Fowler, one of the earliest proponents, describes microservices as “suites of independently deployable services.” Microsoft Azure CTO Mark Russinovich has a great article on microservices as well.

You can think of microservices as an outgrowth of object-oriented coding, where each programming component is coded in such a way that, given the required inputs, it can function with any other component. Yet microservices are stand-alone services that, working in concert, power one or more applications.

One of the best aspects of microservices is the ability to have multiple, redundant services, each of which can stand in for each other. Administrators can remove, insert, stop, or start related microservices without impacting the whole application. You can patch or update one or more microservice components, and the larger supported application should hum along without a hiccup.

Securing it all

Let’s review: We have physical computers and virtual machines. We have public and private clouds. We have containers and microservices. It’s all running across physical and software-defined networks.

Now imagine them all working in concert together to deliver a service or set of services. In a full redundant model, you have containers running microservices in VMs in public clouds and/or on in your datacenter.

How are computer security pros supposed to secure it all? You start by breaking it down into its individual components. You secure all the involved physical computers and networks as you have always traditionally done. You look at the threats along the OSI model and address your needs.

Virtual machines have their own security issues (guest-to-guest, guest-to-host, and host-to-guest risks). Microservices are best handled using Security Development Lifecycle methods and tools. At their base, microservices are simply software and should be treated like any software that needs to be securely programmed.

Like VMs, containers have their own issues, but each container scenario demands a different security approach. Be sure to check out the Docker security blog and the aforementioned InfoWorld article.

The most important recommendation I can give you is that identity is the new security boundary. I’m not talking user or device logon identities alone, though they play a major role. I’m also talking about the identities and security contexts that run each of the individual components.

Do they share the same namespace? If so, do multiple components run under the same shared identity? If they share different namespaces, do the involved identities still share common authentication credentials? That would be like someone using the same password across two different, completely unrelated websites.

You have to know what libraries and components are shared by different microservices or containers. If one of the subcomponents has a vulnerability, that means every dependent, upper-layer component has the same vulnerability. Can you even patch the dependent subcomponent? Like the trials and tribulations of computer security people trying to patch Java clients, containers and microservices can open the door to the same patching hell.

If you don’t know much about containers and microservices, start learning more about them today. Done right, containers and microservices can simplify security. Manage them poorly, and you’re inviting another security nightmare.