Containers are hot and container security is booming. At present there are a lot of websites dedicated to this topic. It’s highly technical and the number of subtopics is very large. Specialized knowledge is required to put container security into practice. Companies will benefit from this knowledge to make their applications and containerized environments more secure. However, it’s difficult to pinpoint what actually contributes most to your organization. That’s why here is a business point of view on container security.
Getting started
There are multiple ways to get started with container security topics. This is different for all organizations but there are patterns. Some considerations:
- Do you build your container images yourself or is this provided by a third party vendor?
- Do you manage the run-time environment for containers yourself or is this done by a third party vendor?
- Who in your organization is in charge of the container infrastructure?
The right knowledge
One of the first questions you should ask yourself is: where to get the knowledge from when it comes to container security? An which knowledge do you need? Your organization might have a security department but within DevSecOps the teams itself should handle security related aspects themselves. Containers are just like regular artifacts, they are building blocks of the applications which the teams create.
The (central) security department might not understand the functional use cases of the applications which are crafted by the developers and the developers are not specialized in (container) security. Their focus is to deliver business features. Security can be seen as “overhead” to their work.
One of the solutions is to establish a small expert team which includes a number of developers and security specialists. They will acquire all of the knowledge about the security related topics and make sure the other developer teams are aligned. Best is not to isolate the team too much: it should be a team which helps the other developer and operations teams. As soon as the expert team has sufficient knowledge they can provide presentations, workshops and best practices to the organization. The knowledge will be distributed across the entire organization and this will prevent a brain-drain if people of the team move to another department or leave the company.
How to prioritize
Do you know how many applications you have? How many individual components? Assume they all run inside a container. The more applications and components (micro-services) the more important to prioritize which containers to secure first. Some considerations which can help you to prioritize:
- Ask your vendor to secure the images they deliver to you. You can help them with security scans and possible fixes.
- Start to secure the applications which processes the most sensitive information. For example privacy related information about customers.
- Start to secure the applications which are internet facing: they have probably the highest attack surface.
- Secure the applications which have a high number of (highly demanding) customers: applications which process a big stream of data which is used by a lot of other departments is more important than an intranet application to share holiday pics of co-workers.
- Secure the components which are used by multiple applications. Since a lot of applications depend on it, it’s crucial to make it secure. Make a plan to keep them secure as well.
- Do a quick scan of the container images which are currently being used (and no one looked at the potential vulnerabilities) and start to secure the images which have the most critical violations.
Start with the base
Base images are Docker images which act as a “base” or “parent” for other images. A developer team can extend a base image for their application. The last couple of years I noticed a lot of organizations suffer when it comes to the governance of base images. Base images act as a layer between the infrastructure and the application layer – it’s difficult to pinpoint who is/should be responsible for it. One of the reasons to setup the expert team is to cover the governance around this problem.
Container security topics should be “steered” from within this team to give developers freedom to use these base images. As soon as a lot of developer teams use them it becomes crucial to secure them.
Input criteria
The following criteria provide input for you:
- Every base image which adheres to the desired security standards should be approved (by the expert team) so developer teams know they can use it safely for their applications.
- Don’t support more than 2 or 3 levels of base images – it will be too complicated to manage. From a security point of view, it also becomes very challenging to check all levels since security violations on parent levels are not always visible at first glance.
- Create a system which checks the base images on regular times (e.g. weekly). As soon as there is a critical violation found – alert the central security team. Developer teams should be aware of this violation since it puts their application(s) at risk.
- Help developer teams to patch the images, write common strategies for them (e.g. how to properly upgrade a package as part of a container image)
- Adding meta-data (e.g. maintainer, version, security violations) to the base images is as important as the image itself. Make sure developer teams can view the meta-data in an easy way. For example: images in a container registry should be linked to the actual source code.
- Use a consistent scheme for naming conventions, tags, filenames, etc. This is very important to quickly find the differences between base images which (at first glance) look similar. It also helps to prevent the creation of similar (and potentially insecure) images.
Wrap up
Securing the base images is just the beginning of the journey – there is so much more to explore. Container security is a huge topic which affects a lot of disciplines throughout the entire organization. Stay tuned for the next articles of this interesting topic.
