By now, we’re all aware of the Equifax breach that affected 143 million customer records. Equifax reports that Apache Struts vulnerability CVE-2017-5638 was used by the attackers.

Equifax was not running its vulnerable struts application in a container, but what if it had been? Containers are more secure, so this whole situation could have been avoided, right?

Not so fast.

Containers’ inherent infrastructure as code approach has multiple security advantages. Building and deploying new containers continuously is the standard operation, so deploying updated and patched software versions comes with less risk of downtime. You start with a clean container so you won’t potentially be patching an already compromised system, leaving beachheads in place. It also means that, in general, containers have shorter life spans than servers, so an attacker has a shorter period to use a persistent backdoor or move further into the network.

Furthermore, repeatedly exploiting a newly deployed container over and over increases the chance an alert from another security solution will be seen, be it IDS/IPS or file integrity monitoring.

Containers have compelling security benefits, notably container isolation from host processes and networks. However, misconfiguration or neglect can still wreak havoc on an otherwise solid security posture.

Let’s discuss securing the Docker stack, which encompasses many of the same elements as securing your traditional infrastructure, but comes with some of its own twists on a familiar set of challenges.

1. Privilege Escalation Attacks

A common threat to defend your Docker stack against is the elevation of privileges by an attacker. The attacker’s goal is to break out of the container and gain access to the Docker host; they can do so through a variety of opportunities.

2. Vulnerabilities

Vulnerabilities in the Linux Kernel, such as the widely publicized Dirty COW vulnerability, can be used to escalate privileges (Read more...)