In my previous blog, I performed a runtime comparison of the “Top Ten” critical capabilities of the Kernel Plugin vs. Container Native Application Protection. In this blog, let’s complete the same exercise for the Privileged Container approach.
As in the previous comparison, I’m going to consolidate a number of critical capabilities into the “Top 10”. These “Top 10” address the critical runtime capabilities across four key runtime domains.
This domain focuses on initial deployment and supported technology requirements of the solution. For this domain, I’ve included the same five key deployment capabilities combined into the first three of our “Top Ten” for comparison:
- Does not require changes to container infrastructure (i.e., kernel module, host agent, etc.)
- Supported technologies, including:
- Support for Container as a Service (i.e., AKS, ECS, EKS, GKS, etc.),
- Support for Function as a Services (i.e., Lambda), and
- Support for Serverless Computing
- Does not require root privileges/commands to run (i.e., nsenter, capsysadmin, etc.)
The privileged container does not require a kernel plugin or agent to be installed on the host, but it may require changes to the orchestrator. Kubernetes supports privileged containers natively through daemon sets, but Swarm does not. Also, the need for root privileges also limits such solutions portability to Container-as-a-Service, Function-as-a-Service, and Serverless Computing offerings.
This domain focuses on identifying cybersecurity events and detection processes for running containers. For this domain, I’ve included the same four key detection capabilities combined into the fourth of our “Top Ten” for comparison:
- Dynamic, or runtime, analysis, including:
- Monitor system calls
- Monitor storage activity (i.e., read, write, volume mounts)
- Monitor network communication (i.e., ports, services, protocols)
- Monitor application calls
The privileged container has some weaknesses and strengths over the kernel plugin. Although the privileged container runs with root or administrative system privileges, these solutions have limited system call support. Here, the kernel plugin has better capabilities.
On the other hand, the privileged container can provide better application call support, at least at layer 7. However, deeper inspection of the application calls will require additional capabilities, specific to the application languages(s).
This domain focuses on implementing appropriate protective safeguards for containers, specifically at runtime. For this domain, I’ve included the same nine key protection capabilities combined into the next five of out “Top Ten” for comparison:
- Support for dynamic policy enforcement (i.e., real-time policy updates)
- Dynamic, or runtime, protection, including:
- Enforce system call activity/behavior
- Enforce storage activity/behavior (i.e., read, write, volume mounts)
- Enforce network communication (i.e., ports, services, protocols)
- Enforce application call activity/behavior
- Additional file/storage protection, including:
- Enforce binary whitelist
- Enforce file/binary integrity
- Isolate/segment container-level communication (i.e., micro-segmentation)
- Enforce application call path
The same limitations and strengths from above impact the comparison here, as well. Although the privileged container runs with root or administrative system privileges, these solutions can’t intercept or enforce any policies on system calls. These solutions also have limited application enforcement, including the lack of application call path support.
This last domain focuses on actions to address cybersecurity events, commonly known as incident response. For this domain, I’ve included the same three key response capabilities combined into the last of our “Top Ten” for comparison:
- Alerts and notifications, including:
- Support allow and alert
- Support allow, capture, and alert
- Support block and alert
The same limitations and strengths from above impact the comparison here, as well. The privileged container has limited response capabilities for system calls. Also, these solutions can provide basic application response, but lack deeper application call response, including the application call path.
Although the privileged container covers one half to three quarters or more of the critical capabilities across the Detect, Protect, and Respond domains, it’s deployment capabilities are lacking. If your organization is looking to migrate to Container-as-a-Service, Function-as-a-Service, or Serverless computing options, then the privileged container approach will require you to re-architect your security solution. Additionally, key system call and deeper application call support is lacking.
On the other hand, a Container Native approach provides the added system and deeper application protection, along with flexible deployment options. You can learn more by visiting layeredinsight.com/solutions/, requesting a demo here, or contacting us at [email protected]