In the third installment of the Detection Engine blog series, we examine the Application Control Engine, one of five detection engines which work together as part of our cloud workload protection platform (CWPP) to detect and block runtime threats impacting cloud workloads. (The first and second blog posts discuss the Static AI Engine and Behavioral AI Engine, respectively.)

• Static AI Engine
• Behavioral AI Engine
• App Control Engine
• Cloud Intelligence Engine
• STAR Rules Engine

Application Control Engine 101

SentinelOne’s Application Control Engine is a highly specialized drift prevention engine within our real-time CWPP agent that is focused on preserving immutability of containers and virtual machines (VMs). It accomplishes this by detecting any binaries or scripts created and executed after the VM or container starts. Stated another way, the Application Control Engine ensures that only executables from the original container image run in the workload instance.

Originally, the engine was designed to protect immutability of containerized workloads running within Kubernetes and other container orchestration systems such as Hashicorp Nomad and AWS ECS. However, the cloud security innovators at SentinelOne expanded the scope to include Linux VMs. In short, the Application Control Engine reduces the attack surface of your immutable container architecture.

Gain Immutable Protection

Most often, the set of executables and scripts found within a running container do not deviate from those of the original container image from which the container was instantiated. This fact offers a big advantage to security teams in that if rogue executables or scripts suddenly appear within a container that is supposed to be immutable, it’s a telltale sign that the container may have been compromised.

Attackers often use custom scripts or executables to automate the work of finding vulnerabilities that allow for privilege escalation or lateral movement. With SentinelOne’s Application Control Engine enabled, these types of attack tools are trivial to identify and prevent.

The functionality is largely based on timestamps, and so requires very little operational overhead. It is easily enabled or disabled in policy. When a new container is instantiated, Singularity Cloud Workload Security (CWS), SentinelOne’s real-time CWPP solution, denotes its timestamp.

From that point forward, CWS compares the timestamp of any file from which a process is spawned against the container’s instantiation timestamp. If the timestamp of the file is more recent than that of the container, we can infer that the file was not in the original container image. In this case, the Application Control Engine will log an incident to the management console and, if configured in policy which the customer controls, prevent the process from running.

On the other hand, if the timestamp of a file precedes the container’s instantiation timestamp, the Application Control check is satisfied and the process is allowed to start. Moreover, any activities from this process are still monitored by the other Static and Behavioral Engines within the autonomous, real-time CWPP agent. As previously mentioned, our five CWPP detection engines each work to complement the other.

Monitoring and preserving immutability with the Application Control Engine is a big win for cloud security practitioners and DevOps alike. It greatly simplifies the identification of anomalous activity, and there is very little operational overhead to maintain it.

Benefit from Maximum Agility

Compared to cumbersome application allowlisting methods of legacy security products, with the Application Control Engine there is:

• No pre-deployment scanning
• No ML training periods, waiting on an algorithm to “learn” what’s in a given image
• No list of paths/executables to maintain.

Pre-deployment scans for legacy solutions create an allowlist of expected processes. While this approach ensures that a container will always run with a predefined set of processes, it adds the overhead of allowlist management.

Training periods for machine-learning algorithms means the ML learns the expected behavior of a container over time, usually in a sandbox and before pushing to production. This approach automatically creates an allowlist, but its effectiveness depends upon the training period duration. Set the training period too low and risk a large number of false positives. Conversely, setting it too high causes long delays when trying to release code to production. This is the very opposite of agility.

The Application Control Engine circumvents the shortcomings of legacy solutions: no allowlists to create and maintain, and no ML training periods to slow you down.

The Advantages of Operational Flexibility

Should you have containers that do change (in controlled and predictable ways) within your environment, exclusions can be applied to accommodate these variances. The classic example of a container that is mutable by nature is a build system like Jenkins, used to build software from source code. Build systems often have pipeline steps that pull code from remote repositories and build executables from that code.

These build steps can cause “false positives” for Application Control because new executables and scripts are being executed in containers whose images did not originally contain them. However, it is both desired and expected that these files be allowed to run.

To allow for this scenario, SentinelOne’s Exclusion feature can be used to exclude files and directories (and optionally their subdirectories) from inspection. This allows for the “known-mutable” areas of a container to function as desired while the rest of the container’s immutability is enforced.

Extending to VMs

As previously mentioned, although originally designed for containerized workloads, the Application Control Engine has been extended to Linux VMs. An example use case is for Amazon Auto Scaling Groups, in which Amazon EC2 instances are created from Amazon Machine Images (AMIs) in response to increased workload demand.

Once an EC2 is instantiated, it is extremely uncommon that one would run yum/apt to install and update packages or load scripts on these live production hosts. Rather, should an update be necessary, the AMI itself would be modified to include the desired packages, scripts, etc. When the new AMI is ready for deployment, DevOps engineers update the machine image version (tag) to point to the newly updated machine image.

From then on, any new VMs (EC2) within the Auto Scaling Group will be created from the updated AMI, and VMs on the outdated AMI decommissioned. This DevOps process promotes uniformity, repeatability, and scalability.

Example: Cryptomining Malware

Let’s extend the explanation of the VM use case to a common threat vector – cryptominers. While the use of cryptomining malware ebbs and flows with the price of Bitcoin, it pays to be prepared to protect your infrastructure from being used by unwelcome guests. After all, they keep the Bitcoin, and you keep the cloud compute bill.

Assume for this example that a threat actor has obtained access credentials to an EC2 compute cluster. The threat actor then simply remote shells to the VM, downloads a crypto miner, makes the file executable, and executes. These steps are easily scripted and launched with a single command line.

Here is what the detection looks like in the SentinelOne management console.

As shown in the image above, the Application Control Engine was not the only engine to trigger a detection. Even so, it’s all consolidated in a single alert. The AI within the agent has assessed a confidence level of MALICIOUS to this detection. The path to the cryptominer – in this case, xmrig – is shown, along with command line arguments, Storyline™ identifier and more. On the right hand side under THREAT INDICATORS, the detection has automatically been mapped to a MITRE TTP. Together, these details help streamline investigation of the detection.

Note that the incident is shown as NOT MITIGATED. This is because the agent policy is set to Detect Mode (as shown). Had the policy been set to Protect Mode, the incident would have automatically triggered a response action. In this example, however, the information is laid out intuitively, and the cloud security engineer can easily initiate remediation with a single click, while also notifying the DevOps owner of the incident so that root cause (credential compromise) can be addressed.

Conclusion

The Application Control Engine is yet another of the detection engines integral to SentinelOne’s real-time CWPP. Originally designed to preserve immutability of containerized workloads, it also protects Linux VMs.

To learn more about the value of real-time CWPP in your cloud security stack, head over to the solution homepage, or see how Singularity Cloud Workload Security works with a 2-minute guided walk-through here. And of course, whenever you are ready, you may connect with one of our cloud security experts for a personalized demo.