Reconsidering Container Security
Logicworks Jason McKay, the company’s Senior Vice President and CTO takes the stance that there are no mature monitoring tools available that monitor access and events across multiple Docker containers or clusters. McKay referenced Gartner in support of his position. I refer you to a blog post from Gartner’s Joerg Fritsch posted at http://blogs.gartner.com/joerg-fritsch/can-you-make-your-containers-contain/, which McKay cited.
Software vendors are creating increasing numbers of solutions to treat these container monitoring maladies. Assuming their survival and that all living things grow, these solutions should mature and inevitably resolve this issue. “Kubernetes (launched v1 in July 2015), BoxSpy (April 2015), and others have all entered the ring, and AWS continues to add functionality to their Elastic Container Service to provide additional options for running Docker containers in EC2,” says McKay.
Maturity here means more than mundane monitoring techniques. Enterprises need a broad solution that supports compliance requirements for auditing purposes, creating an easily traced audit trail.
“Solutions need to integrate existing access monitoring and incident and change management policies that integrate with enterprise SOC teams,” says McKay. The most intuitive and cost-effective means is to integrate enterprise class Docker monitoring tools natively with existing monitoring tools and operations.
A slew of household name information security products don’t monitor individual containers for issues, McKay reminds, leaving the expectation that they should and ultimately will. In order to make a determination as to the security of container functions and internal applications and processes, tools would need to know what is happening there. Security teams particularly need traffic flow transparency of inter-container traffic so that preset incident response planning has something to respond to. “It is not impossible to integrate Docker into this response process – it merely requires an adjustment to existing procedures. We make the case that Docker is by no means a seamless fit into existing incident response procedures,” says McKay.
The lack of container security monitoring maturity complicates incident response and there are highly-visible examples of this to illustrate.
“Take the Heartbleed vulnerability for example. If you’re running on VMs in AWS or elsewhere, a configuration management tool like Puppet can “force” the use of the most current version of SSL on all instances. This can be done in minutes,” says McKay.
“If you were running Docker in ECS, you don’t run a CM agent on containers, so if you want to ensure that the new version of SSL is on every container, you would update the base image and recreate the container in line with your typical deployment procedures. Instead of a task that is usually accomplished by a system admin, this would likely be performed by your development team,” says McKay.
If your enterprise development team is not used to doing the security team’s work, this can be awkward as well as time-consuming.
Because security response should always be a group effort tying every applicable team together, GRC and DevOps should already be collaborating on security even where containers are concerned. DevOps must be involved to ensure that the response is technically accurate.
“If for example, you leave a machine up in the middle of a security incident (in a way that’s not accessible to the outside world) in order to see what’s retained in memory and you try to engage a 3rd party forensic investigator, do they understand Docker? What about your QSAs? The use of containers is not really understood by the broader InfoSec and auditor community yet,” says McKay. So without a DevOps familiar component consulting on investigations and audits, how will these be of any use?
Negative Results of Inadequate Docker Security
To move forward while waiting on mature Docker monitoring solutions, enterprises may need to cross-train teams on issues that are particular to containers so they can collaborate in an informed way. “Security response procedures are often complex processes involving compliance officers and multiple teams; changing runbooks can take time and significant effort if Docker is employed beyond a small team. Containers are so new that you’re working in a little bit of a vacuum – you don’t know what QSAs will think is acceptable or not. That is a potential audit and financial risk,” explains McKay.