The way enterprises build applications has changed dramatically in the past decade. Containers have become the clear favorite for modern enterprises due to their speed and mobility. Furthermore, they run directly on the OS kernel, so users don’t deal with many operations headaches. Despite these strengths, containers lack the proper levels of security.
Many enterprises turn to container security solutions to improve functionality. However, solutions in this space still need time to grow. No provider offers an all-encompassing container security tool. Some enterprises use multiple container security tools to build a more expansive suite. Integration between these solutions often proves difficult though. This was the primary takeaway when I asked industry experts their thoughts on overlooked container security concerns.
Container security solutions often lack diverse coverage. Each falls into a specific category of coverage but may lack strengths elsewhere. Forrester recently divided functionalities into three segments – container security specialists, security suites, and security platforms. Due to the underlying complexity of containers, creating all-encompassing solutions proves difficult.
Of this, Twistlock CTO John Morello said:
“A lot of point solutions out there focus on 1 aspect of security. For example, only providing vulnerability management. At the same time, there are some existing legacy security vendors starting to add compatibility with containers.
I think both of these miss the big opportunity here. If you’re using a modern security platform that leverages the core characteristics of containers, you can do security that’s more automated, more efficient, more effective, and more complete than traditional solutions. A point solution may do one thing well, but if you have to integrate 4 or 5 of them together, it’s impractical to operationalize. If you have a legacy, heavy, agent-based approach to security that requires lots of manual configuration and rules, you lose a lot of the potential advantage to doing security in a more cloud-native way, one that scales along with the apps it protects.”
“Containers are relatively new and do not always support the fine granularity of configuration desired. An example is configuring resource quotas or tighter control on namespace access. There is still a great deal of reliance on host configuration for complete security. Many common security monitoring tools have immature container support, or lack support altogether. Native image signing and encryption are not available or are immature.”
Multiplicity of Solutions
Specialties are inevitable in any solution category. Some vendors do x better while another does y better. Container security solutions fit in this trend. As John Morello pointed out, many focus on 1 aspect of security while failing in other categories. This sentiment was further illustrated in my recent conversation with Alert Logic’s global VP of solution engineering, Mark Brooks. He stated:
“Most container security solutions only focus on log output from the platform and associated applications. While logs are a great source of information, they are ‘after the fact’ and can leave gaps in visibility that could lead to container and application compromise. Not to mention, if compromised, the source of the log is under attacker control, leaving the possibility of corruption and/or deletion.
“One of the most recent innovations in container security is an agent that deploys in a traditional IDS mode – listening to intra-container traffic and leveraging a detection set that will identify pre and post compromise activity. This is important because depending on configuration and deployment, there can be any number of dark corners where bad actors can hide or mask behaviors. Log output relies primarily on events being written to the system after the event has already occurred. IDS provides visibility to attacks against the container host or application in near real time, even if the activity is not logged by the system.”
Although security must be a priority for enterprises, ineffective practices prevent optimal performance elsewhere. We chatted with Ixia’s Kris Raney to gain a deeper understanding of this concern:
“The biggest omission I see today is the detrimental effect of false positives or overly restrictive policy. You want your security to be tight, of course, but you’ll never achieve perfection, and also rolling forward with new versions of the thing you’re protecting means that there will be subtle changes to what it needs over time. One possible outcome of mistakes or changes is that you leave something open that can be exploited. People put lots of thought into that.
“The other possibility is you restrict something that is legitimate and necessary. The question becomes, how does this affect the behavior of the system? Unless you’re careful, it will manifest as inscrutable, hard-to-diagnose failures. You don’t see a “the security system blocked me” error. You just see a failure to communicate. It may seem intermittent since the specific situation security is interfering with may only come up under particular circumstances. This is especially true in a microservices architecture where you have zillions of tiny components interacting with each other. Your sincere attempt to keep security tight can turn into a debugging nightmare. It looks like a buggy app when it’s really an overzealous security layer.”