Maksim Kabakou - Fotolia
Security Think Tank: Container security starts with good DevOps practice
Adopting containers promises great organisational efficiency advantages, but the fast-evolving technology can be problematic for security teams. What do CISOs need to know to safeguard containers?
It is easy to see why the use of containerisation has increased rapidly in line with the increase in cloud services and digital transformation initiatives. Their use allows rapid development and deployment, portability and scalability, and – in some ways at least – more security.
However, the use of containers is a radical change in the approach to developing and deploying applications, and in the infrastructure used to manage them. As with any radical change, the approach to security needs to change, taking advantage of the security properties of containers while addressing the new problems they bring.
Containers provide virtualisation of the operating system (OS), rather than of the hardware as in traditional virtualisation, and are compiled with the application and any dependent programs, libraries and so on, required by the app.
The compiled container is therefore fully self-contained, only needing to access the OS using the specific OS calls necessary for the application to run. Containers are also confined to running in user space. These aspects make it more difficult – but not impossible – for an attacker to compromise the OS, and hence other containerised apps running on the same OS.
On the negative side, additional layers of abstraction mean traditional security tools cannot monitor and protect containerised apps.
Also, the production environment contains the orchestration software which provides scalability by spinning up containers as required and the registry storing the images. The protection of the orchestrator and repository are also security concerns in terms of integrity of the app images and availability of the orchestrator to generate the services.
Using microservices
Another consideration is the use of microservices. This builds on traditional ideals of modularisation of software, but breaks down an application into a number of separate microservices, each of which can be developed separately using different software environments but communicate with each other (typically over https) to provide an overall service.
While having some of the benefits of scalability and agility, and a similar development approach as containers, different microservices making up the same application can run in a container, on bare metal, on a host OS, or in the cloud. They are typically used for distributed and scalable networking applications (load balancing, for example) and can also be used for security monitoring applications with the ability to monitor inside a container.
Protecting the host OS
In the production environment, the key security considerations are protection of the host OS, protection of the orchestration and registry infrastructure and monitoring of containers. The host OS only needs to respond to calls from containers and the orchestration system, and therefore should be hardened in line with recognised guidelines by removing unnecessary services, and so on.
In addition, regular vulnerability scans of the host should be carried out to detect and fix emerging vulnerabilities. A least-privilege model should also be adopted to limit access to the orchestrator and container registry. Also, any front-end services should be secured from attack using application whitelisting. These and other measures should take account of and defend against the OWASP Top 10 most common web attacks.
Monitoring of the containers themselves is more problematic, and currently the best approach is probably behavioural monitoring of the apps against a previously established secure state, together with monitoring of the communications between them at the network layer.
Security in the development environment
The security of the production environment is only one part of the lifecycle, however, and the security and practices in the development environment are equally important. Traditional waterfall or agile development methods produce a single, monolithic app, which will be rigorously tested and probably deployed for a significant time without being updated.
The DevOps process used for containerised app and microservices development, however, is a continuous development process, which provides updated functionality on an ongoing basis with new versions apps deployed as they become available.
This has advantages and disadvantages from a security point of view – while every new iteration of the app could introduce new vulnerabilities, when a problem is found, it can be fixed quickly without a long patch cycle.
Automated testing
Good development practices such as establishing coding standards and code complexity rules are a first step, but in a fast-paced DevOps environment automated security testing is essential to police standards and ensure vulnerabilities are eliminated as far as possible before deployment.
Testing should be done on external and open source code where possible, as well as in-house-developed code. While some testing can only be done on a completed application, testing should be done as early as possible in the development cycle. Static code analysis can pick up violations of coding standards and potential vulnerabilities like unprotected buffer overflows. Because it doesn’t need executable code, static code analysis can be run overnight, on code written during the day.
dynamic code analysis should be done on compliable code, but again can be an integral part of development as well as final release testing. Other security testing can only be carried out on the full app, including fuzzing and penetration testing. While penetration testing and, to some extent, fuzzing are generally performed manually, solutions using artificial intelligence (AI) are now emerging to help speed up the process, but today at least, a skilled pen tester will be needed.
Though not specific to containers and DevOps, supply chain security and security of the development environment are also important factors applicable to any software development, as is management of open source software use and licensing.
As with any new technology, there will be some aspects that can be exploited to deliver improved security, and others that give us new security challenges. The first thing we need to do is understand the technology and the environment in which it is operating, so we can identify critical assets that need to be protected and the new security approaches we need to develop or adopt to protect them.
