This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
There still really aren’t many enterprise run-time security tools for containers available, which has skewed the conversation toward establishing defensive barriers prior to run-time – during the build, integration, and deployment stage.
Of course, with rapidly evolving technology like containers, it can be all too easy to overlook the most basic security concerns, so, really, any focus at all is welcome. Efforts pointing out the security advantages of digitally signing container images at build time, and scanning them before they are pushed to the registry, should indeed be heard. The OS should be hardened and attack surfaces should be trimmed where possible. Solutions like Seccomp and AppArmor that introduce security profiles between containers and the host kernel ought to be implemented.
However, the reality is that the idea of thwarting all hacking attempts by simply putting in place preventive measures prior to deployment is unrealistic. Truly guarding against all such intrusions requires security with the ability to detect threats and violations at run-time. Considering the number of threats occurring in real-time with working applications, run-time security is arguably the more crucial component of an overall container security strategy.
Container deployments can suffer from most of the same threats common to virtualized or single-OS server environments, in addition to a few new ones. General threats to container security include:
- Application level DDOS and cross-site scripting attacks on public facing containers
- Compromised containers attempting to download additional malware, or scan internal systems for weaknesses or sensitive data
- Container breakout, allowing unauthorized access across containers, hosts or data centers
- A container being forced to use up system resources in an attempt to slow or crash other containers
- Live patching of applications to introduce malicious processes
- Use of unsecure applications to flood the network and affect other container
And here are some examples of prominent container attacks to prepare for:
- The Dirty Cow exploit on the Linux kernel allowing root privilege escalation on a host or container
- MongoDB and ElasticSearch ransomware attacks against vulnerable application containers
- OpenSSL heap corruption caused by malformed key header and a crash caused by the presence of a specific extension
- Heap corruption and buffer overflow in Ruby and Python libraries allowing execution of malicious code
- SQL injection attacks that put hackers in control of a database container in order to steal data
- Vulnerabilities like the glibc stack-based buffer overflow, giving hackers control through the use of man-in-the-middle attacks
- Any new zero-day attack on a container that represents an on-going threat
- To understand why run-time security is so critical, consider the application lifecycle. What’s developed, tested, packaged and deployed in just months will often run for years, and may be shared across millions of instances worldwide. This makes run-time by far the greater window of attack.
We know from threats such as SSL Heartbleed just how persistent a run-time security vulnerability can be that arises from a small bug in the code. Said another way: from the point of putting applications into production, enterprises need to be thinking about run-time security forever after.
So, what should an effective strategy for run-time container security include? Here are 12 checkpoints, spanning from simple preparations to more advanced run-time security controls.
First, to prepare for production by securing the host environment:
1) Secure the OS and reduce attack surfaces by removing all unneeded modules and files. Be diligent in updating to the latest security patches. Or use a system based on the recently announced LinuxKit.
2) Ensure the container platform is secured. If using Docker, follow the advice in Docker’s best practices guide.
3) Use solutions like SELinux or AppArmor to customize specific security profiles and guard against unauthorized access.
4) Scan containers for vulnerabilities in all registries.
5) Run integrity checks on container images and digitally sign them at build time.
6) Protect secrets such as passwords and API keys required for run-time container access by using third party tools or key management services.
7) Reduce your risk by running application containers in read-only/non-persistent mode.
Then, constantly monitor and protect the run-time environment:
8) Understand normal application network behavior, and enact a security policy to enforce authorized connections. Monitor every container for abnormal behavior or policy violations.
9) Perform live scans of all running containers and hosts, recognizing vulnerabilities and securing the image in use – even as new containers are created.
10) Use session level or network encryption where needed. Carefully weigh the tradeoffs between performance/manageability versus security for each application to determine if host-to-host or container-to-container level encryption is warranted.
11) Implement container threat detection to recognize real-time attacks, including threats at the application layer (DDoS, XSS, Slowloris, etc.).
12) Store forensic data on all container security events and perform offline analysis to understand the nature of these events. Capture network data if needed to help forensic analysis of attacks.
Because containers deliver rapid virtualization for applications, run-time security solutions need a deep application awareness to keep up the pace and actually have an impact. Look to implement run-time security monitoring that can effectively recognize threats and catch them early on, while also allowing the benefits of containers to proceed unimpeded.
NeuVector provides a Docker container network security solution that uses behavioral learning to secure containers during run-time.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.