What is Zero Trust Execution? Definition, Adoption & More

Zero Trust Execution is the industry recommended practice for securing workloads in the cloud. It provides a tight grip on your workloads by allowing only pre-approved code to run and nothing else. It’s considered by market analysts to be the most effective Cloud Workload Protection method for reasons we will explain in this article, namely due to the high predictability of cloud servers and the nature of cloud cyber attacks.

Zero Trust Execution is a security approach that allows only pre-approved code to run in your cloud servers. Similar to Application Control or immutability (data that can only be written, not modified or deleted), Zero Trust Execution prevents any unauthorized code or applications from running on your cloud infrastructure. This allows you to retain a trusted state by stopping any changes or deviations in runtime from the pre-approved baseline.

Instead of searching for anomalies, which is what most solutions are doing today and which can provide a false sense of security as attackers can mimic normal behavior, Zero Trust Execution focuses on the actual code and applications themselves, which is the root cause of cyber attacks as we will explain below.

The security industry has already been adopting the Zero Trust principle, mostly for network traffic. Zero Trust Execution takes the same “default-deny” approach and applies it to the execution of applications. Allow only authorized code, that you will classify as such, to run in your systems.

To truly see the value of Zero Trust Execution, it’s important to understand how a cloud cyber attack is conducted.

On the surface, every cloud cyber attack looks different. Attackers can utilize many attack vectors, or they can exploit vulnerabilities in Docker, Kubernetes, and Linux applications, to name some examples.

One element that stands out is these attacks require the attacker to run unauthorized code or commands somewhere in the victim’s runtime environment. In the illustration below, you can see that regardless of the type of attack, almost every cyber attack eventually requires code to be executed in runtime. Learn about the advantages of runtime vs. pre-runtime protection in this SANS webcast.

In the 2018 Tesla breach, attackers gained access to an unprotected Kubernetes console. One of the console’s storage containers contained credentials for a broader Tesla AWS cloud environment, which the attackers then used to run cryptocurrency mining malware on the company’s Linux servers. Zero Trust Execution would have prevented this attack by alerting on the unrecognized code that was executed after the attacker gained access to the system.

This is one reason why the industry is shifting to a Zero Trust Execution approach.

Unlike endpoints, where it’s difficult to predict what software will be installed onto the device at any given time, cloud environments are fairly predictable. That is, servers and cloud-native applications (Virtual Machines, Kubernetes and Docker instances, etc.) should run only pre-approved software and the operating system itself. Therefore, it’s much easier to maintain a clear baseline in the cloud than it is on an endpoint.

That is another reason why the industry is adopting Zero Trust Execution for cloud workloads. For companies migrating their infrastructure to the cloud, it’s recommended they replace their Antivirus software and Endpoint Detection and Response (EDR) platforms with Cloud Workload Protection Platforms (CWPP) that utilize Zero Trust Execution. Not to mention, Linux threat detection is below average in most antivirus products and organizations require a solution designed to protect their Linux systems, instead of a migration from a Windows endpoint detection platform.

Here are the advantages of adopting Zero Trust Execution for the cloud:

• By preventing unauthorized code from running in your servers you are protected against most cyber attacks.
• Detect and prevent attacks even if they exploit unknown vulnerabilities.
• Provides a last layer of defense as sometimes you don’t always have time to patch vulnerabilities in a timely fashion.
• Greater peace of mind knowing your workloads are constantly running in a trusted state, without allowing any drifts from the pre-approved baseline.

Zero Trust Execution is, in theory, ideal for the cloud due to the high predictability of cloud servers, which is why market analysis firms like Gartner recommend it. In reality, there are many legitimate changes that occur in production which can cause this approach to generate high operational overhead. Below are some of the challenges involved with implementing Zero Trust Execution.

• High overhead: Recent research suggests 90 percent of cloud servers drift from the original trusted baseline. This overly strict policy creates a lot of noise for security teams.
• Coverage of entire cloud native stack: Many solutions apply a Zero Trust Execution approach only for containerized environments. Cloud environments, however, are not just containers. They usually include other assets like database servers that are not part of the structured CI/CD process.
• In-memory visibility: Most solutions that apply Zero Trust Execution do so only on disk (traditional Allow Listing) and therefore don’t enforce this approach in memory. This prevents them from providing protection against vulnerability exploitation or other in-memory threats, since they are only preventing files from executing on disk. The exploitation of critical SaltStack vulnerabilities allowed attackers to execute code remotely with root privileges, meaning they could install backdoors, conduct ransomware attacks, or control servers to mine cryptocurrencies. While fileless malware and in-memory attacks were once limited to sophisticated attackers, they have become the norm in recent years.

Zero Trust Execution has become the industry standard for a reason. It’s important to discern that the aforementioned challenges are a result of implementation and not the approach itself.

Here are some aspects to consider when adopting Zero Trust Execution to alleviate these challenges.

1. Implement Application Control and memory protection: To adopt Zero Trust Execution, the first step is to implement both Application Control and memory protection to defend against fileless and in-memory threats. App Control provides defense against unauthorized applications running from disk, while pairing this with memory protection gives you control over in-memory threats.
2. Apply it to your entire cloud native stack: Seek out vendors who offer immutability to your containers and also to other types of infrastructure. Remember, some vendors apply a Zero Trust Execution strategy only for containers and assets that are part of the continuous integration pipeline. Don’t neglect the entire cloud native stack. You most likely have Virtual Machines and other assets that need to be protected.
3. Adopt a genetic Zero Trust Execution strategy: More about this in the next section.

A genetic Zero Trust Execution strategy is a specific implementation of this approach that addresses some of the challenges that other implementations present.

Genetic-based Zero Trust Execution creates a baseline for every piece of code running in your servers’ memory and monitors for any new process or injected code. Any change in memory is inspected on the code level to determine if it’s unrecognized from your baseline or other trusted software, or if it’s in fact a legitimate change, such as a simple software upgrade or natural change in memory. Unlike other implementations, it doesn’t examine deviations by checking changes in file hashes. Instead, it analyzes the origin of every new piece of code that is introduced to the environment.

This approach presents some advantages over traditional implementations of Zero Trust Execution (like Allow Listing), including:

1. Genetic analysis inspects code in memory and not only on disk.
2. Differentiates between a real deviation and a meaningless drift that doesn’t require any attention. For example, if you have made simple updates to your Apache server, this approach will recognize the new code introduced to your system is from trusted origins and verify the legitimate change.
3. This approach provides context by classifying any new code or application. It can answer questions such as: What is the origin of this software? Is it a cryptominer? An APT? Or code that has never been seen before?

The result is a tight Zero Trust Execution strategy with reasonable flexibility to avoid a high number of false positive alerts.

Learn how Intezer can help you adopt a genetic Zero Trust Execution strategy

Zero Trust Execution provides a tight grasp on your workloads by allowing only pre-approved code to run, making it the industry standard for the cloud. To alleviate some of the high overhead caused by traditional implementations of Zero Trust Execution, consider adopting a genetic approach which can differentiate between real unrecognized code and a trusted change such as a simple software upgrade or natural change in memory.

Intezer

Count on Intezer’s Autonomous SOC solution to handle the security operations grunt work.