The use of Application Control—commonly referred to as whitelisting or Zero Trust Execution—is considered to be a robust and essential Cloud Workload Protection strategy, largely due to the high predictability of cloud environments. But it does not prevent all cyber attacks.
Attackers can exploit vulnerabilities in trusted applications or utilize whitelisted apps for malicious intent—referred to as Living off the Land (LotL). App Control also presents some operational headaches for cloud security teams, requiring strict and often unrealistic policies.
This article explains how to build a robust Application Control strategy for your workloads that is informed by these challenges.
What are the Advantages of App Control?
App Control is a security strategy that blocks unauthorized applications from running within an IT environment. It has many benefits, including:
- Identify all applications running within your environment
- Control which applications have the authorization to run within your environment
- Prevent all unauthorized applications from executing within your environment, including malicious, untrusted, or potentially unwanted applications (PUAs). This approach is referred to as Zero Trust Execution
Market analysts regard App Control as both an effective and essential Cloud Workload Protection strategy, largely due to the high predictability of cloud servers. In theory, cloud servers and cloud-native applications should include only the operating system and some other pre-approved software. All unauthorized applications or any deviation from the baseline are blocked. This is in stark contrast to a traditional on-premise environment, where it’s much more difficult to predict what software a user will download and subsequently install onto the endpoint.
App Control is Not Impenetrable to Hackers
App Control has been used to protect more traditional, on-premise environments for years. However, it has struggled with low adoption due to the challenges it presents for security teams. Some of those challenges being, it’s not impenetrable to hackers and it presents operational headaches.
In-Memory Threats
Attackers can bypass whitelisting by exploiting vulnerabilities in trusted applications and then injecting code into memory. Since App Control is only preventing files from executing on disk, it doesn’t defend against fileless and in-memory threats.
As we saw recently, attackers exploited vulnerabilities in the popular SaltStack infrastructure automation software to infect cloud servers and install cryptocurrency mining malware. This is one of the reasons why market analysts recommend App Control should be paired with memory protection capabilities to gain full threat coverage in runtime. While fileless malware and in-memory attacks used to be leveraged only by advanced attackers, they have become the norm in recent years.
Recommendation: Pair App Control with memory protection or exploit prevention capabilities to continuously monitor all code running in memory and detect malicious code injections and other fileless threats.
Living off the Land
The term Living off the Land (LotL) refers to malware-less attacks that use an operating system’s own native tools against it. As cyber defenses have improved—yes, this type of threat is the result of improved security defenses and patching—it has become much more difficult for an attacker to run malicious code on any given system.
All operating systems have tools and commands that can help system admins perform various administrative and troubleshooting tasks. Since these tools are often whitelisted, attackers use them instead of their own tools which won’t be allowed to run on the target operating system. For attackers, the operating system has become a gold mine of programs and scripts they can abuse.
According to Ed Skoudis, a security instructor with the SANS institute, LotL attacks can range widely: ransomware operators using software deployment tools to deliver the ransomware code, for example, or nation-state actors using Mac and Linux machines as a place to hide while they handcraft attack tools using built-in scripting languages like Perl or Python.
A high profile example of this was the Petya/NotPetya ransomware attack of 2017, which used the legitimate Windows Management Instrumentation (WMI) command line tool to spread across networks.
Recommendation: 1) To combat LotL attacks, DevOps teams and developers should strip their containers and servers to the bare minimum required to run their application. For example, there’s almost always no need for the “ftp” command to maintain your application’s functionality. For attackers, however, it’s a useful tool for exfiltrating data.
2) Cloud security teams should pair App Control with heuristic or anomaly detection capabilities to detect suspicious commands or abnormal usage of any unwanted applications in the cloud server’s operating system.
3) The LotL project page on Github and the GFTOBins open source project provide a list of binaries, scripts, and libraries that are often abused in LotL attacks, including bash, cmdkey, shell32, and rundll32. Most users have no need to run many of those programs and cloud security teams should consider configuring their application whitelisting tools to prevent execution of them.
Operational Headaches
In theory, cloud infrastructure should not make any deviations from the CI/CD pipeline. However, in reality, nearly 90 percent of all cloud environments drift from their baseline, which happens due to routine changes or maintenance operations. It’s understandable that security teams may sometimes have special requirements, such as patches, software updates, or occasional maintenance needs. While this may be realistic for only one or two servers, it’s not scalable for organizations with 100, yet alone 5,000 servers.
Nearly all App Control solutions are not flexible to signature changes, meaning they block any new software upgrade or update that is not the exact same hash. This can cause operational headaches for cloud security teams in terms of creating strict and often unrealistic policies, as it can be tedious to alert the DevOps team about unblocking an application after every minor update. In addition, this can generate false positives and create more work for the security team to investigate these alerts.
Recommendation: Look for Cloud Workload Protection solutions which offer a combination of adequate threat detection and low overhead. Here are some questions you can ask your vendor:
1) How does your solution deal with automatic updates?
2) How does your solution deal with special one-time maintenance operations?
3) How many alerts do you produce on average per day?
4) How do you handle the continuous baselining of apps that are not part of the CI/CD pipeline (e.g. Database servers, VPN servers, and standalone VMs)?
Conclusion
Despite its shortcomings, Application Control is an integral part of any Cloud Workload Protection strategy, largely due to its ability to automate the restriction of malicious, untrusted, and or potentially unwanted applications (PUAs).
However, it does not defend against the full scope of cyber attacks—most notably fileless and in-memory attacks—which is why market analysts state that it is only one layer of Cloud Workload Protection. Security teams looking to invest in a Cloud Workload Protection Platform (CWPP) should ensure their vendor also provides memory protection capabilities and other layers of IaaS security, such as EDR-like visibility, Anti-malware, and System Integrity.
Zero Trust Execution Meets Low Overhead
The Intezer Protect Cloud Workload Protection Platform (CWPP) provides protection against unauthorized code, encompassing file-based, fileless and Living off the Land attacks, without the overhead. Our Genetic Analysis approach identifies the origins of all applications running on your cloud servers in order to differentiate between a real deviation and a natural drift that is in fact legitimate. Learn more
Count on Intezer’s Autonomous SOC solution to handle the security operations grunt work. Try it yourself for free: analyze.intezer.com