What is Containerization? Security & Benefits

Containers and the concept of containerization has been growing rapidly over the past few years, and many organizations are struggling to keep up with the new technology and keeping their systems secure. If you and your organization are considering trying to use or moving to containers, many of your current security processes and procedures will no longer work with containerization or will require some updates.

Below is a high level description of containers and some instructions on how to secure them. If you would like more information, please feel free to reach out to Linford & Co, and we can help walk you through what is needed to meet your compliance goals and move into the world of containers.

What are Containers? What is Containerization?

As you read articles and attend conferences, you may hear a lot about the “new” wave of “virtualization” called containers. Containers allow you to run an application and all of its dependencies in isolated processes. The goal of containerization is to allow you to easily package everything you need to run your software reliably when moved from one environment to another.

What Does Containerization Do?

Containers help support continuous integration and also increases consistency, efficiency, productivity, and version control. The biggest name in containerization these days is Docker, but many additional companies have started offering containerization services, including Google, Amazon, Red Hat, etc. To help standardize runtime and formats, the Open Container Initiative (OCI) was created in 2015 by Docker and others, and currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec).

What are the Benefits of Containerization?

There are a number of benefits that moving to containerization provides. Some of the main benefits companies can see include:

• Increased Portability
• Simple and Fast Deployment
• Enhanced Productivity
• Possible Lower Cost
• Improved Scalability
• Improved Security

 

What is the Difference Between Virtual Machines and Containers?

Virtual machines (VMs) package the operating system, code, and dependencies together and are deployed to a host operating system. VMs are pretty bulky and require a lot of system requirements to run. Containers are different, as they only contain the software, libraries, and other dependencies they require to run so you can put them directly on the host operating system. This allows you to cut out a lot of unneeded software, leaving a small and efficient “container” holding you application. This allows you to have many more instances running the same hardware as before when using VMs.

What is Containerization Security?

Containerization security is the approach an organization will take to ensure that their containers are secure from unwanted threat and risk. An organization needs to implement and follow effective security strategies to have success with containerization. Read on for additional information on securing and monitoring your containers.

What is the Major Security Concern with Containers?

If you do decide to move in the direction of containerization, keep in mind that the traditional security model is no longer valid and you may have to redesign how you approach compliance and security. For example, many of your current security tools are host based, and when you remove the dependency of the host you are probably now in the market for new tools.

One major security concern is that containerization lacks isolation from the host OS. So if there is a vulnerability with the host kernel/OS, it could impact all containers. And since containers are still fairly new, security guidance, frameworks, and methodologies are still trying to catch up. Luckily, security tools are also catching up, allowing organizations to automate a lot of the security that they relied upon in a virtual or bare metal approach.

 

How Secure are Containers? How to Secure and Monitor Containers for Security Compliance

Overall Security and Hardening: A good starting point to determine security controls and guidance is to utilize the vendor provided security benchmark or hardening guidelines. For example, the Center for Internet Security created a CIS Docker Community Edition Benchmark. This document walks through steps on host configuration, daemon configuration, daemon configuration files, container images, runtime, etc. There are also a lot of supporting GitHub repositories to help with security configuration. Some quick examples are CIS Kubernetes, and Docker Compliance.

Monitoring: Monitoring containers can be a tricky. You do not have specifics tools like host based firewalls, anti-malware, antivirus, etc. to support the detection of malicious activity within the container. You can install all of those on the host operating system, but depending on what you are using, you will have limitations like events being from the host not the container.

You should also add additional monitoring into the SDLC and monitor, document, and test the image registries and containers. Knowing what each container includes down to the libraries is key in understanding what the threats and vulnerabilities are.

In lieu of more traditional security monitoring techniques, there are other tools like Twistlock which offers a whitelist approach to monitoring processing, networking, and others and flags any unexpected or malicious behaviors, and Polyverse which relaunches the containerized application on specific intervals, for example, relaunches every 10 seconds, thus limiting the ability to exploit the application.

Of course, auditing is always recommended. Monitoring events at the host OS level, the application, and the container daemon level is necessary as well. Depending on your approach and architecture, logs are key to determine gaps in security, especially if you are rebuilding the instances repeatedly, as that instance will not be around for triage and you may not notice the issue until the instance is already rebuilt.

Vulnerability Assessments: In addition to monitoring and general organizational risk management, defining a proper vulnerability assessment process is also key. Luckily, most commercial vulnerability scanners offer some sort of container security scanning to help identify known vulnerabilities and security configuration issues. Be sure to activate these features or search out new tools if your current product does not support containers.

Patching and Hardening: Patching is a bit different in a containerized environment. In the past you would just update your instances through a manifest, recipe, or other patch management process or tool. With containers, there are two components: the base and the application image. You have to first update the base image and then rebuild the application image. This will force a more complex patching process and more interaction between infrastructure support and development as both are now more closely connected.

Integrity: As a way to enhance the security of containers, Docker (Docker Content Trust) and other container systems have incorporated a signing infrastructure to allow administrators or authorized users to sign container images which helps prevent untrusted or unapproved containers from being deployed.

Isolation/Separation/Access: This is a big one, as moving to containers lessens the isolation that was once available with VM and/or bare metal systems since containers shell the same kernel. Understanding your requirements both internally and externally will drive your approach on how to limit the risks. One approach some organizations are utilizing is to run the containers from an operating system on a VM. This way if the container or VM is attacked, the compromise is limited to the VM and not the physical host (in some cases the hypervisor) which protects any other VMs or systems that are also present on the physical host.

You can limit the risk of privileged escalation and other security attacks by following the hardening guidelines documented above, and other techniques like using control groups, making sure to run the containers as an ordinary user, and using namespaces.

Incident Response: As discussed above in monitoring, when you move to containers, you can severely limit your ability to perform forensics since the instance or host could have been replaced already. Reviewing all Incident Management and Response processes specifically for containers is required. Traditional methods are no longer at your disposal.

Also, since containers are still fairly new, there will be additional risks that the organization will be accepting. Everything from external compliance not accepting/understanding the new processes, to new threat vectors, to internal knowledge and training. There is going to be more emphasis on security throughout the entire development lifecycle.

Summary

Whether you are thinking about or have moved into the world of containers, security needs to be reevaluated as the standard practices may no longer be acceptable or the processes may not meet your compliance needs. We recommend implementing containers in a non-compliance or non-production environment first to try and get a good feel for how to monitor, secure, and support them.

Moving to containers does not mean you cannot get a specific certification or pass an audit or examination, it just means you may need to change some of your security processes. Any large changes like this should also be discussed with your auditor to determine the impact on your compliance requirements.

Linford & Company has extensive experience providing SOC 1 Audits, SOC 2 Audits, HITRUST assessments, HIPAA audits, FedRAMP examinations, and more. If you are interested in learning more about any of the services provided by Linford & Co, please view our Services page, or contact us to schedule a free consultation.