Containers have become a staple among large banks and financial services firms, which have used the technology in production. It has captured the attention of the broader market, that hopes to achieve the same technology benefits of improved application delivery and run-time efficiencies.

This modular plug-and-play architecture is more scalable and can deliver more power to the application in a specific area. Any technology requires a thorough security assessment to ensure associated risks are identified and weighed against an enterprise’s appetite for risk. When approaching the risk-tolerance threshold for containers, additional controls may be necessary to mitigate the risk to acceptable levels. There are essentially three broad categories of risk to consider when using containers.

1. Attack Surface

There are many different objects to track, and a noted lack of visibility into how those objects are manipulated. This means a focus on user authentication and authorization, container activity lockdown and image detection and prevention are required.

2. Shared Kernel

All applications generally share the same Linux kernel. This is one of the key benefits of containers from a DevOps perspective, since containers take seconds to run. Whereas, minutes are required to spin up and spin down a virtual machine. This places an emphasis on the integrity or assurance of the image.

3. Vulnerabilities

There is a risk that any vulnerabilities introduced during a development cycle may be exploited by attackers, including malicious insiders.

The big challenge for system architects, DevOps and chief information security officers is how to automate security. DevOps teams are running full speed with Kubernetes and deploying apps every hour of every day. The main threat vector is an attack that attempts to install an older vulnerable package or library and then exploit it.

Container Monitoring Tools

Monitoring tools should consider the behavior of typical file systems being accessed and baseline patterns of file system access. Solutions on the market leverage system calls by monitoring network packets and all activity happening on the host. The better solutions incorporate the context of a specific container to do both monitoring and interception.

To address these high-level issues, organizations running containers in production should ensure adequate controls are in place to monitor user access to containers. They should also establish a role-based, least-privilege approach. The least-privilege principle should apply to container, operating system and network resource access. It should be coupled with enforcement of runtime parameters. Monitoring should be implemented to identify anomalous container behavior, such as access and privilege escalation attempts with prevention capabilities to prevent malicious activity in real-time.

Generally, early adopters found they had limited visibility into container activity until the host has been compromised. The open-source tools often require customization. This is because they only provide partial coverage of the risk categories and often fail factor in the context of the container.

Container platforms focus on images and limit their coverage to their own stack. There is little runtime detection or prevention provided by these platform providers, although some provide policy-driven mechanisms.

These approaches can go a long way to address some of the sources of data risk, but no data security solution is a silver bullet. There may be better strategies that you should pursue. It depends on your enterprise’s risk tolerance, types of sensitive data being stored in these environments and your security team’s capacity.

The IBM Security Data Security team is running an anonymous survey to gather market feedback on customer data security needs. Take the survey (~8 minutes) to share your top priorities concerning data security and what you would like to see in a data security product.