We noticed a drastic increase in the number of customers who moved to cloud-based container platforms over the last year. This trend was the result of desire to reduce the operation burden which is workload and cost overruns. In a typical cloud set up, Infrastructure as a Service (Iaas) customer is responsible for managing the operating system, system software, application and data whereas in the Platform as a Service (PaaS) setup, customer is responsible for managing the application and data. Likewise, in the Container as a Service (CaaS) cloud model, customer is responsible for managing the application runtimes, application and data.
The operation burden is reduced, however from a security point of view – the customer needs to take care of the additional measures to overcome the challenges thrown by the new threat landscape. This blog aims to cover the requirements for vulnerability assessment & penetration testing in a container environment.
As explained in the beginning, the cloud service provider takes the responsibility of identifying and mitigating vulnerabilities till the operating system layer. The customer will have access only to deploy the container image and can get started with the application service. Once the container is in the running state no further modification is allowed.
A typical vulnerability assessment tool will detect the weakness in the network communication ports, protocol services, Kernel, operating system, applications and classify the vulnerabilities based on CVVS score (Critical, High, Medium, low).
However, a container model brings to the fore a new playground for identifying and mitigating the vulnerabilities.
The vulnerability management process should be integrated with development pipelines (CI/CD pipelines) from application build to run state. Container images are built with application codes and its runtime libraries. Containers are also capable enough to run multiple application (Apache, MySQL, PHP) in a single container image like a typical VM. However, the best practice is to build different containers – one for each application. This gives us flexibility in managing the vulnerability of the application individually and contain the security exposure. It is advised to conduct threat modeling for the application and to identify the possible threats based on STRIDE or DREAD methods in the design state itself.
Finally make sure container is built with latest version of application runtime libraries and frameworks.
Once the container image is built, run a vulnerability scan on the built image using scanning tools.
- Open source tools suggestions
- Anchore
- Clair
- Dagda
- OpenSCAP
- Sysdig Falco
- Commercial tools suggestions
- Tenable Container Security
- Qualys Container Security
It is necessary to perform a scan on the image before it gets deployed into production environment. As containers are immutable, no changes are allowed in the running state of container, patches cannot be applied into the running container if any vulnerabilities are detected. The best practice would be to rebuild the container image with the necessary patches / fixes.
Once the container is launched in the testing / UAT environment, for web-based applications, it is recommended to perform a penetration testing based on OWASP / SANS Web application testing guidelines before deployment into the production environment. It is also necessary to perform the penetration testing activity after rolling out changes – both major and minor changes to the application.
The next stage would be to monitor the running container in the production environment. The above listed open source suggestions can also be configured to monitor the behavior of the container for anomalies.
The last point to note would be the configuration of the containers. It’s important to make sure that the ports/ services allowed are the only required services for the application.