What’s inside your containers Why visibility and control are critical for container security
As organizations turn to containers to improve application delivery and agility, the security ramifications of the containers and their contents are coming under increased scrutiny.
Container providers Docker, Red Hat and others are moving aggressively to reassure the marketplace about container security. In August Docker delivered Docker Content Trust as part of the Docker 1.8 release. It uses encryption to secure the code and software versions running in Docker users’ software infrastructures. The idea is to protect Docker users from malicious backdoors included in shared application images and other potential security threats.
Docker Content Trust focuses on the integrity of the delivered contents of Docker containers. Ultimately, it is about cryptographically signing Docker deployment images, an approach also employed in Linux kernel development and by many embedded systems developers and OEMs to ensure that only signed images can boot (for example, in Samsung KNOX Android code).
However, this is only one aspect of container security. There’s also the challenge of ensuring the code constituting the whole image is free from vulnerabilities. If organizations don’t keep software stacks and application portfolios free of known, exploitable versions of open source code, such measures only amount to a partial solution. Without open source hygiene, these tools will only ensure that Docker images contain the exact same bits that developers originally put there, including any vulnerabilities present in the open source components.
What’s needed is informed open source technology selection, vigilance by users and integrators of open source code, and ongoing code maintenance. It’s about knowing your code, because you can’t manage what you can’t see.
Having visibility into the code inside containers is a critical element of container security, even aside from the issue of the security of the containers themselves. New vulnerabilities are being constantly discovered that impact older versions of open source components. Hence, knowing the container is free of vulnerabilities at the time of initial build and deployment is necessary but far from sufficient. Securing the contents of containers is comparable to any other software stack security question. The only twist is when and how to gain visibility inside a container during development and post deployment.
The security risk posed by a container depends on the sensitivity of the data accessed via the container as well the location of where the container is deployed, for example, behind a firewall or Internet-facing.
Internet-facing web and cloud apps are prime targets for cybercriminals and obviously represent the highest potential exposure. A publicly available attack surface makes them subject to a range of attacks, including cross-scripting, SQL injection, and denial-of-service. Given the prevalence of open source frameworks and other cloud/web application components, these also benefit significantly from open source hygiene to address vulnerabilities in those components.
With the use of open source software increasing throughout the enterprise, and with recent high-profile open source security vulnerabilities raising alarms, open source hygiene has become an essential component of an effective application security strategy. Just as physical hygiene involves neutralizing sources of infection, open source hygiene entails keeping software stacks and application portfolios free of known, exploitable versions of open source code. This is just as important for containers as for every other element of the software stack.
The presence of vulnerabilities in all types of software is inevitable, and open source is no exception. Detection and remediation of vulnerabilities in open source, such as in the case of high-profile vulnerabilities like Heartbleed and Freak, is increasingly seen as a security imperative and a key part of a strong application security strategy. And for many organizations today, application security is tied more closely than ever to container security.
The good news is that for companies developing an end-to-end open source security strategy, innovative tools are available today to get a tactical head start. These tools can catalog all open source in software portfolios – from whole platforms such as Linux, Android and Hadoop, to individual code components, all the way down to the level of code snippets cut and pasted into internally-developed application code.
These scanning tools, when employed on demand or when integrated into software development workflows, provide critical information for companies to act upon, without slowing development or delaying time to market.
It’s critical to develop robust processes for determining the following:
Enterprise organizations today are embracing containers because of their proven benefits: improved application scalability, fewer deployment errors, faster time to market, and simplified application management. Just as organizations have moved over the years from viewing open source as a curiosity to understanding its business necessity, containers seem to have reached a similar tipping point. And, just as with open source, the question now is whether security concerns about containers will inhibit further adoption.
Industry analysts differ in their assessments. Forrester Research’s Dave Bartoletti believes security concerns won’t significantly slow container adoption, drawing a parallel to the rapid adoption of virtualization technologies even before the establishment of security requirements. “With virtualization, people deployed anyway, even when security and compliance hadn’t caught up yet, and I think we’ll see a lot of the same with Docker,” Bartoletti says.
Meanwhile, 451 Research’s Adrian Sanabria believes enterprises will give containers a wide berth until security standards are identified and established. “The reality is that security is still a barrier today, and some companies won’t go near containers until there are certain standards in place,” Sanabria asserts. Reflecting this concern, a Red Hat survey of 194 IT operations and development decision-makers in APAC, EMEA, and North America in January 2015 found that 53 percent cited security as their top concern about container adoption.
To overcome these concerns, organizations are best served to take advantage of the automated tools available to gain visibility and control over all the elements of their software infrastructure, including containers.