New technologies such as virtualization, Docker, and microservices introduce new methods of software delivery and speeds up application deployment, but also brings new security threats and risks. We will briefly discuss how these new technologies change the practices of security and DevOps.
New technology (third-party, cloud, containers, and virtualization)
Virtualization
It's very common to install application services on top of a virtualized OS. Virtualization technology helps to make the most physical machine resources such as the CPU, memory, and disks. However, virtualization is a shared OS technology. It also introduces security risks such as VM escape, information leakage, and denial-of-service for applications running on top of virtualization.
Security practices in guest OS virtualization are normally involved with both OS and virtualization hardening. Here are some key security configurations related to virtualization. Refer to CIS Benchmarks for details:
- Limit informative messages from the VM to the VMX file
- Limit sharing console connections
- Disconnect unauthorized devices (USB, DVD, serial devices, and so on)
- Disable BIOS Boot Specification (BBS)
- Disable guest-host interaction protocol handler
- Disable host guest filesystem server
- Disable VM console paste operations
- Disable virtual disk shrinking
- Do not send host information to guests
The following diagram shows the adoption of virtualization. Virtualization adds a hypervisor layer on top of the physical server so that the virtualized guest OS can run on top of it:
In addition to the secure configuration of virtualization, applying a security patch to virtualization is also a must for operation or IT teams.
In addition, the following resources may help you to search for Common Vulnerabilities and Exposures (CVE) in vulnerability databases:
- Exploit Database https://www.exploit-db.com/
- SecLists http://seclists.org/fulldisclosure/
- Vulnerability Notes Database https://www.kb.cert.org/vuls/
To search for the vulnerabilities of a specific product or vendor, refer to the URL search for VMware as following:
Dockers
The introduction of Docker provides software package delivery and installation with new choices and can be one of the best ways to isolate different applications without using a whole separate OS virtual machine. Software can be packaged into a container by Docker. A container, like a VM image, includes everything needed to run application services such as runtime, system libraries, and settings. The key difference between a virtual machine image and a container is that the container doesn't actually include the whole OS. The container only includes key necessary system libraries and every container shares the same OS kernel during runtime. Therefore, Docker containers can boot up within seconds and use much less memory or far fewer disks than virtualization images.
The use of Docker can also greatly help operation teams to do deployment and secure configuration since a Docker container includes every configuration and the settings you need to run. To understand Docker security practices, check out the CIS Docker Benchmark and Docker security in the Further reading section.
Key secure practices and configurations of Docker are listed here:
- Separate partition for containers
- Updated Linux kernel
- Only allow trusted users to control the Docker daemon
- Audit the Docker daemon, files, and directories
- Restrict network traffic between containers
- TLS authentication for the Docker daemon
- Do not bind Docker to another IP/port or a Unix socket
- Docker daemon configuration files permissions
- Container runtime (Linux Kernel capabilities, SSH, ports, memory, CPU, IPC)
The following diagram shows the key difference between virtualization and Docker. Virtualization is a guest OS level while Docker is actually an application-level isolation and shares the same guest OS:
Here is a summary of the known security vulnerabilities identified in Docker.
| CVE ID | Related CWE ID | Description |
| CVE-2014-5282 | 20 |
Docker before 1.3 does not properly validate image IDs, which allows remote attackers to redirect to another image through the loading of untrusted images via Docker load.
|
| CVE-2017-14992 | 20 |
Lack of content verification in Docker-CE (also known as Moby), and earlier allows a remote attacker to launch a Denial of Service attack via a crafted image layer payload; a.k.a Gzip bombing. |
| CVE-2017-7297 | 264 |
Rancher Labs rancher server 1.2.0+ is vulnerable to authenticated users disabling access control via an API call. This is fixed in versions rancher/server:v1.2.4, rancher/server:v1.3.5, rancher/server:v1.4.3, and rancher/server:v1.5.3. |
| CVE-2016-9962 | 362 |
RunC allowed additional container processes via runc exec to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container. |
| CVE-2014-0047 | n/a |
Docker before 1.5 allows local users to have an unspecified impact via vectors involving unsafe /tmp usage. |
Here is a tip to query a specific vulnerability. Take 'CVE-2014-0047' as an example; just replace the CVE ID number at the end of the following URL.
Infrastructure as Code (IaC)
Puppet, Chef, Ansible, and SaltStack are tools to apply IaC. The key advantage of using these tools is that any system configuration can be defined in a text file at the design stage and changes can be managed by versions. This will help both operation or development teams to build security configuration baselines such as file permissions, firewall rules, web configurations, or MySQL connections. Once the security configuration baseline is defined, the operation team can monitor any unauthorized changes or roll back the configuration to previous specific versions.
For example, we may have baseline security firewall rules for a web services environment to only allow ports 80 and 443. All an operation team needs to do is to define the firewall rules by using one of the tools (Puppet, Chef, Ansible, SaltStack), and the framework will apply the rules, audit, and even correct changes if other ports are opened by mistake or by other service deployments.
The DevSec Hardening Framework project available at https://github.com/dev-sec provides Ansible, Chef, and Puppet secure configuration baseline template scripts.
The following diagram shows how IaC (for example, Puppet) works:
