Containers face security risks at every stage, from building to shipping to the run-time production phases. Securing them requires a layered strategy throughout the stack and the deployment process.
Containers face numerous security risks at every stage of the deployment process, from building to shipping to the run-time production phases. These threats make achieving continuous security essential to the integrity and safety of containers. However, often these security measures are skipped or overlooked in the rush to get the CI/CD pipeline flowing faster. Many businesses are paying the price today for poor security implemented years ago. Hopefully, these mistakes won’t be repeated in the migration to a containerized environment.
Risks to containers and their hosts come in many forms: ransomware, application-level DDoS and cross-site scripting attacks, compromised containers that download extra malware or hunt for sensitive data or weaknesses in internal systems, container breakouts allowing unauthorized access across systems, containers forced to eat up system resources to crash other containers, and plenty others.
Many of these attacks start with previously undetected vulnerabilities that can lie dormant for years. Attackers exploit these to gain a foothold, and then expand into other hosts or containers.
Recent ransomware attacks have exploited various vulnerabilities, including open ports, remote code execution, and other application liabilities.
WannaCry/WannaCrypt is basically attacking Microsoft Windows vulnerabilities on SMB, RDP, and IIS service ports like 445. Like most attacks, there is a « kill chain » of events that leads to the ransomware demand.
Once attackers are able to get inside a network they spread laterally in an ‘east-west’ direction. Doing that has become much easier in a containerized environment due to the lack of visibility into east-west container traffic.
SambaCry is a 7-year-old critical remote code execution vulnerability ( CVE-2017-7494) discovered in the Samba networking software that could allow a remote attacker to take control of an affected Linux system. Today, if you have your CVE database updated in time, vulnerability scanning software could help to find this CVE in container images. Other techniques can also help detect a privilege escalation or breakout.
ElasticSearch and MongoDB are two of the most popular application container downloads from Docker Hub. Surprisingly simple attacks involving open ports and passwords could allow these to be used for ransomware. Basic container security precautions could prevent such an attack. Frequent auditing and testing of host and container security settings would highlight risks introduced by the latest application updates or host deployments.
The Dirty Cow ( CVE-2016-5195) kernel exploit is used by attackers to overwrite a so-called setuid program in the system. By replacing the setuid program, the attacker gains root access privilege when the program is executed, and is then able to do whatever they want. While an attacker can perform destructive acts, it is more likely that at this point they will try to expand to other systems or applications as stealthily as possible. It’s even possible for the exploit to stick around in a container environment, even when the infected containers are destroyed.
The Linux Stack Clash vulnerability ( CVE-2010-2240) was recently discovered by Qualys security researchers and has been named « Stack Clash » because it involves « clashing » the stack with another memory region, such as the heap. While this is a local exploit in the user space, it can still give attackers a foothold into the operating system or kernel. Stack Clash could be used with other exploits to wreak even more havoc on systems and potentially move laterally. For example, a recent sudo vulnerability ( CVE-2017-100367) could be combined with Stack Clash to be able to run arbitrary code with root privileges.
Every successful attack involves a ‘kill chain’ of events, and detection is possible at multiple points using various techniques. Generally, to mitigate these risks in a container environment, the following security measures should be taken:
Curtailing these threats requires a layered security strategy that is implemented to prevent issues throughout the stack and at each phase of the deployment process. The correct security controls and automated tests to detect and address attacks and other issues are critical components for ensuring effective and secure applications.
Here are the measures you can put in place throughout the container deployment process to enact continuous security.
Continuous security begins with building secure applications. Developers must understand and utilize proper techniques for minimizing risk within the application code itself. These techniques include:
Code analysis – Developers should make use of code analysis tools that can recognize and report any potential vulnerabilities.
Hardening – Reduce the attack surface of the container image by removing any libraries and packages that aren’t needed, and by restricting non-required functions.
Image Scanning – Just before the ship phase, container images should be scanned for vulnerabilities in order to catch any issues before the application is built. Registry scanning should also be done regularly, as this can find new issues in existing images.
As a practical matter of executing these security measures, they should be automated into the delivery process/pipeline using adequate tools, as doing so ensures they are performed continuously and without fail.
When preparing to deploy images, security depends on the right controls and verifications in place to ensure trust. These include:
Image signing – This ensures that the author / publisher is verified and that no image tampering has occurred. For example, Docker’s Content Trust feature provides this security.
User access controls – Sensitive systems and deployment tools (registries, orchestration tools, etc.) should have mechanisms in place to effectively enforce restrictions and monitor for user access.
In order to automate these security features to facilitate continuous security, images for production use should be signed and tagged automatically. Access controls for sensitive tools should be integrated with Active Directory, or LDAP directories. Docker Bench for Security can be run as an automated process to test content trust and access control issues.
Ahead of running application containers live in production, the run-time environment needs to be secured – including the host, kernel, Docker daemon, and all network and system services.
Host and kernel security – These can be safeguarded using security modules such as AppArmor, SELinux, seccomp, or the equivalent host security settings.
System and Docker daemon security – Make sure that only authorized users can access sensitive systems and Docker commands and settings.
Secrets Management – Utilize encryption to protect secrets that are subject to application and API access.
Auditing – Perform audits of security settings both before and during run-time. This can be accomplished using the previously mentioned Docker Bench for Security, Kubernetes CIS Benchmark, or other tools, and has the additional benefit of helping to meet container compliance requirements.
Orchestration security & networking – Secure the container environment by using container management and orchestration tools capable of controlling access, setting network policies and appropriate names and labels. These tools can also make sure that security containers are running on every host.
These orchestration and integrated security tools can deliver automated security testing and checks against standard benchmarks, as well as automatic policy updates to adapt to configuration changes and offer clearer visualization of behavior within the application and containers.
