Containers and container security
Do you docker? Without a doubt, containers are one of the hottest concepts in application delivery and security these days. And that’s a very good thing. Containers have tremendous advantages over the way we have done things in the past. But how should containers influence a threat detection and response strategy? Do I need a larger “container security” strategy to get started deploying my apps using container architectures?
The short answer to these questions is “No.” But let’s explore that a bit more.
What is a container?
A container is an evolution of virtualization. Traditionally, virtualization requires entire “guest operating systems” to be deployed on a hypervisor or host operating system. This was an amazing breakthrough as it blew up the traditional relationship between hardware and operating systems, enabling the deployment of different application building blocks in different VMs on the same or different hardware. Thus it created new ways to build and scale applications. This transition changed how we think about compute resources, moving us from “pets” to “cattle”. Yet each VM carried along with it an entire operating system worth of overhead.
Containers fix this problem by virtualizing only the application and all the associated dependencies it has (shared libraries, file systems, etc.), allowing many more containers to ride on a single operating system. This makes them much, much more efficient. They also have the advantage of being portable across operating systems; they are truly platform agnostic.
Docker security and Kubernetes security are simply the most well known
There are many kinds of containers, Docker is only the most popular. In addition to the containers themselves, most deployments benefit from orchestration and management tools. Kubernetes is the most well-known of these, and Swarm and Mesos are others. These tools handle all aspects of the container lifecycle, helping build consistent container images, deploy them into production, monitor their performance, and decommission them when the time comes.
Easier, safer: benefits of containers, as they relate to security
The isolation provided by containers enables us to better scale and modularize our applications into smaller pieces. But what does it do for our security? LOTS! But containers don’t fundamentally change anything we need to do in the threat detection and response area.
Containers make it extremely easy to reduce our attack surface area. In fact, Docker containers use a “Docker file” that defines many things, including what IPs, ports, and protocols the container can use for communication. Because containers are intended to be used for modular workloads, it isn’t difficult to determine what these ports and protocols should be, making it simple to realize the idea of providing only essential access while keeping things simple
Another key security advantage of containers is, of course, the isolation they provide. If the application inside your container falls victim to an attack, the attacker will find themselves in a very restricted area with only a small part of the application code and user data present. In fact, management connectivity via SSH and the like is often unnecessary in containers, making them even harder to access remotely. Of course, lateral movement or privilege escalation may be possible when vulnerabilities are present. But even if containers are compromised, they have huge advantages. Because they are designed to be ephemerial, remediation of an infected container can be as simple as blowing it way and deploying a new, patched one.
Lastly, containers radically simplify log collection. Container management infrastructures and cloud management tools like AWS Cloudwatch automatically deal with gathering log messages and centralizing them for easy import into a detection and response tool such as AlienVault® USM Anywhere™. This can often eliminate the need to deploy an agent inside a container for monitoring purposes and expand visibility across your entire application with a configuration in the management layer.
A secure container is still about the applications
None of these myriad advantages change the basics of detection and response. At the end of the day, vulnerabilities, configuration weaknesses, and essential trust relationships will still exist. Therefore, we must still monitor our applications and services for vulnerabilities, watch the network for suspicious access attempts, and collect relevant security data to review looking for anomalies.
One useful analogy for thinking about this is the server load balancer. This stalwart of application architecture revolutionized how we build and scale web applications. It introduced small increases in the attack surface (for example, management CLIs) while also giving us a centralized place to perform some important security functions such as access management and detection of certain types of attacks.
The load balancer did not, however, fundamentally change the security game. We still needed to keep our services patched and up to date. We still had to write our application code securely, and we still needed to keep an eye on the system when we’re done building it. It’s reasonable to think about containers the same way – they have optimized and scaled service delivery while providing incremental security enhancements.
But what about all these container security companies?
It seems like everywhere we look today, we see Docker security or Kubernetes security products popping up. If containers already help with security, why are these specialty products launching? As with any new technology, vendors see an opportunity to innovate as well as to package up existing solutions in new ways. There are some really cool new ideas in cloud security.
Network security is one very promising area of innovation with containers. We are seeing some really interesting new tools designed around zero trust networking, micro-segmentation, and other techniques for hiding assets and reducing attack surfaces. These tools aim to lock down your container network as completely as possible. These technologies deserve your attention, but they don’t in any way replace what a detection and response tool does monitoring your applications, and can be seen as very complementary.
One example of solving a related problem is secure image creation. It’s always been a good idea to ensure our gold master images are free from known vulnerabilities and insecure configurations. Some container security products will automatically scan new containers as you create them and then ensure that the image is not compromised anywhere during the deployment process. Using a product like this alongside your detection and response tool is a great idea, as it can prevent deployment of containers that already contain vulnerabilities or malware.
However, other products do things like check for vulnerabilities in running containers. If you’re already monitoring your entire environment with a detection and response tool, adding a “container vulnerability” product will just complicate your security architecture – you’ll be doing the same thing in two different ways, reviewing two sets of reports, and generally wasting time doing double work. Use a detection and response tool that can monitor cloud, LAN, and container vulnerabilities, so this solution is not needed.
Don’t wait to improve your container security, start today
This blog has explained some of the security implications of running workloads in containers. We have explained the inherent advantages: reduced attack surface compared to bare metal or VM deployments, easier access control with the Docker File, and modular design simplifying remediation. We’ve also touched on the fact that USM Anywhere is a great way to analyze the application logs and monitor containers for vulnerabilities. So if security has been holding you back from getting started with containers in your application architecture, hopefully this blog will help you get started on your container journey with confidence.
If you’re looking to learn more about different types of containers, check out this discussion.