|
|
One of the principles of cloud-native workloads is that they are built from immutable images containing everything an application needs in order to run. Whereas desktop and laptop users require the need to install new software, this is not the case for cloud workloads. Based upon the image of the containerized microservice, every process which runs inside a container is fully expected, from the moment the container is spawned until it is killed. Because containerized microservices are dynamic by nature, preserving the immutable state during runtime is crucial for defending against threats such as malware, cryptojacking, and zero-days.
Many solutions today rely upon static allow-lists (formerly, “whitelists”) of all processes that are cleared to run inside the containerized workload, with any deviation from that list considered a threat to be mitigated. There are two different approaches to automatically creating such allow-lists for containerized workloads:
- Pre-deployment scanning. In this approach, the container image is scanned, creating an allow-list of (expected) processes. While this approach ensures that a container will always run with a predefined set of processes, it adds the overhead of managing allow-lists for new versions of images used in the organization. This overhead creates friction in the gears of agility.
- Learning during runtime. Here, ML learns the behavior of a container over a period of time, usually in a sandbox, before pushing to production. While this approach provides an auto-generated allow-list, its effectiveness depends on the time period being set. Set it too low and you can miss processes that were not yet triggered yet, generating a high rate of false positives. Conversely, setting it too high causes long delays when pushing new versions to production.
Having seen organizations struggle to protect their containerized workloads with current solutions, we decided to take a different approach that requires zero-intervention by our customers and which does not compromise on security.
No More Allow-Lists
We are proud to introduce the Application Control Engine, built to protect cloud-native workloads, providing advanced “lockdown” capabilities that guarantee the immutable state of containerized workloads. It requires no special configurations and does not add complexity or delay to the software delivery chain. This engine protects container workloads from the get-go, whether they run as Kubernetes pods or as plain containers in Docker servers, and can be enabled by one simple click to secure the workloads.
How Does the Application Control Engine Work?
When the Application Control Engine detects a process that impairs the immutable state of a containerized workload, it immediately reports that process as a threat, mitigates it by killing the process, and moves relevant files into quarantine.
Let’s see it in action. Here we have a Node.js application running as a Kubernetes deployment:
Now let’s connect to the pod of this application, download a coin miner binary using wget, provide execute permissions, and run it:
Once executed, the Application Control Engine (1) identifies the execution of the foreign minerd binary as a threat, (2) eliminates it by running a mitigation action that kills the minerd process (exit code 137), and (3) moves the minerd binary to quarantine.
Now, let’s look at the forensics view of the threat:
This view reveals the command line used to initiate the threat (./minerd), the engine used for detection (Application Control) and the mitigation action taken to eliminate the threat (KILLED).
The forensics view also provides complete visibility to container and Kubernetes details including pod name, labels, namespace, and image name:
Now let’s switch to a different view that illustrates the chain of events that led to the execution of the coin miner:
We can clearly see how the kubectl exec command started a bash session inside the node-web-app pod, that was later used to download and execute the minerd binary using wget and chmod commands. The example above shows how Application Control eliminates a coin miner threat started as a binary, but it will, of course, provide the same level of protection for threats based on scripting languages, whether they run as standalone scripts or binaries.
Conclusion
The Application Control Engine is the answer to the security needs of containerized cloud workloads. It helps secure runtime from known and unknown threats with a simple click of a button, and it does so without any ML training period or unwelcome delays to production release. The Application Control Engine feature is available starting Linux Agent 4.4 and Kubernetes Agent 4.4, which is in early availability, and requires the Liberty management console (now in GA).
