Adopting containers has become increasingly popular — consider that, as of 2019, 33% of global developers indicated that their development organizations currently use containers, and another 25% said they want to do so over the next 12 months. These numbers are not surprising when we consider the value containers offer, such as scalability, agility, and cost reduction. The allure of containers, however, is largely to the benefit of the DevOps side of the house. Security pros are brought in later and left with the suboptimal task of applying existing tools and traditional security mindsets to secure containers — and discovering that those are ill-equipped to the task.
This glaring disadvantage for security orgs led my colleague Andras Cser and I to investigate whether or not there were still best practices that organizations should use to secure containers. Our preliminary expectations were validated: Despite the dynamic, rapidly changing nature of containers, there are best practices that will meet security requirements. In new research, we categorized the most important best practices into technical and non-technical perspectives.
Here are the key ones:
- Automation. Throw manual processes out the window when dealing with containers: Manual processes are slow, inaccurate, and insecure. Instead, ensure that everything is scripted and automated, including vulnerability scanning.
- Templating. Create uniform templates that encapsulate basic security baselines such as secure network and kernel configurations or regulatory specific baselines that meet HIPAA, PCI, CIS, etc., requirements. The build process must carefully log and audit template changes and track which final container images inherit from which templates.
- Training. Containers are different than virtual machines and hosts, and security pros must understand what those differences mean to their organization. Conduct regular training, tailored to team issues, to drive home the required mindset shift.
This post was written by Principal Analyst Sandy Carielli, and it originally appeared here.
