Security by Design: A Checklist for Safeguarding Virtual Machines and Containers

Preventing security gaps in containers and virtual machines

Keep containers and virtual machines patched and updated

Having differing scopes and requirements in their workloads, organizations use virtualization technologies according to their respective needs. For example, virtual machines (VMs) are a better fit for developers and enterprises looking for flexibility in running multiple applications, while containers are better for those requiring scalable applications.

Containers and VMs both offer means by which applications can be run multiple times or isolated within a single platform, but they differ in how they do it. Containers virtualize an operating system (OS) to run various workloads in a single OS instance, while VMs virtualize hardware to run instances of the OS.

Thus, every instance of applications running on containers and VMs poses a potential attack vector if it is vulnerable or misconfigured. An instance running with unnecessary ports still set up on the container or VM, for example, can be exploited to let hackers sneak into the application’s server.

Container images must also be vetted for vulnerabilities. They are constantly added to a repository, overwritten, and rehashed (if open-source) — actions that increase the risks of their having security flaws. The SANS Institute’s checklist for auditing Docker-based containers is a good starting point for assessing containerized applications and host OSs.

[RELATED: What is serverless computing and what does it mean for DevSecOps]

Safeguard applications by protecting the hypervisor

The hypervisor manages how guest OSs access resources such as the central processing unit (CPU), memory, network, and storage. It partitions the resources to prevent the instances from intruding into one another’s resources. The hypervisor is the underlying infrastructure behind applications running on VMs, which makes their security of paramount importance. The U.S. National Institute of Standards and Technology has detailed recommendations for securing the hypervisor:

• Disable unused and unnecessary virtual hardware or services (e.g., clipboard and file sharing) to lessen the attack surface.
• Keep an eye on the hypervisor for anomalous activities.
• Actively monitor the traffic between VMs; visibility to them should be explicitly enabled.
• Track the instances and restrict the creation of VMs and virtual servers to prevent virtualization sprawl, in which too many instances running lead to inefficient management of physical and software resources.
• Use secure and encrypted communication protocols (e.g., Secure Sockets Layer) to mitigate man-in-the-middle attacks or to protect data when performing migration or storing VM images.
• Authenticate and ensure the integrity of the VM images stored in the server or library.

[InfoSec Guide: Mitigating Web Injections]

Identify security gaps in containers

Images are the blueprint of containers, which use them to spin or run applications. A vulnerable image begets a malware- or hacking-prone container, and consequently, the application itself becomes prone to malware or hacking as well. Identifying security gaps (such as unsecure code) pre-runtime and fixing them accordingly before the image is scheduled in an orchestration environment will significantly save time and effort reworking on builds, as well as reduce overhead and disruptions in the application’s life cycle:

• Ensure that the container images are signed, authenticated, and drawn from a trusted registry; when scanning images, consider scanning the registries as well since registries can be compromised and their images tampered with.
• Secure the daemon; restrict access to it or employ encrypted communication protocols when exposing it in the network.
• Enforce the principle of least privilege; unlike with a hypervisor, which acts as a central point of management, any user, service, or application with access to the container’s root account can get into other containers sharing the kernel.
• Isolate resources; properly configure control groups and namespaces, that is, what and how much resources a container is allowed to use.
• Bake security in to further reduce the need for extra builds; Docker, for instance, has its own documentation on the built-in security features of its engine that can serve as a reference.

Security by design

Experts predict that this year, intelligent enterprise resource planning-based (i-ERP) applications, which are typically hosted on cloud platforms and designed to manage and automate business processes, will be the benchmarks that 15 percent of Global 2000 enterprises will use to improve their bottom lines and enrich customer experience. Indeed, virtualization and the cloud are increasingly transforming the ways personal and mission-critical data are handled and processed.

But it’s not just about securing containers and VMs. Regardless if an organization’s workloads are under the physical, virtual, or cloud infrastructures (or any combination thereof), maintaining and securing them can be daunting. True to the DevOps culture, streamlining is the name of the game. Whether using virtual machines or containers (or both at the same time) to test, run, and deploy applications, their security shouldn’t be a roadblock. Incorporating security into the very infrastructures that drive applications to work not only helps thwart threats, but also reduces business risks to organizations.