Containers and the concept of containerization has been growing rapidly over the last couple of 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 or will require some updates.
Below is a high level description of containers and how to secure them. If you would like more information, please feel 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 new world of containers.
What are Containers/What is Containerization?
As you read articles and attend conferences, all you hear of today is 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.
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 jumped on the bandwagon, including Google, Amazon, CoreOS, Rancher, 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 is the Difference Between Virtual Machines and Containers?
Virtual machines 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. 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.
Containers Sound Awesome, How do I Sign Up?
Whoa there…containers may sound great but they are not for every application. Mesosphere has a pretty good article on how to determine if containerization is right for you and your application. If you do decide to move in this direction, 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.
What is the Major Security Concern with Containers?
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 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 to Secure and Monitor Containers?
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 in mid-2017. 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, Docker Compliance, and container compliance.
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 also should 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 basically 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.
In addition to monitoring, 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 tool/process. 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.
I don’t want to get too in the weeds, so here is a blog by Steve Lasker, which speaks to the paradigm shift in patching.
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.
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.
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 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, hopefully there is already some, on security throughout the entire development lifecycle.
Whether you are thinking about or have moved into the wild 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. I 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 certified, 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.
Linford & Co., LLP, founded in 2008, is comprised of professional and certified auditors with specialized expertise in SOC 1, SOC 2, HIPAA, HITRUST, FedRAMP and royalty/licensing audits. Our auditors hold CPA, CISA, CISSP, GSEC licenses and certifications. Learn more about our company and our leadership team.