Why behavior-based threat detection is critical for cloud workload security

Cloud environments change with the blink of an eye. Every minute of every day brings the potential for new applications or services to be deployed to the cloud. These applications, which come in all shapes, sizes, and architectures, are cloud workloads that require continuous runtime security as  they are vulnerable to attacks in various ways. How exactly, you ask?

Open source software and hidden vulnerabilities

Pretty much all new and existing software leverages open source code because nobody wants to reinvent the wheel. A recent report from Synopsis explains that open-source code is so common that it was found in 100 percent of systems related to computer hardware and semiconductors, cybersecurity, energy and clean tech, “Internet of Things” devices, and internet and mobile app software. And it is not a negligible amount of open-source code—78 percent of the code reviewed was open source. This proves it is a very common practice for open source libraries to leverage other open source libraries as a foundation to build on top of, which only increases the complexity of open source dependencies.

However, this gives a competitive advantage to developers, enabling them to build more functional software, faster than ever. But could there be hidden dangers in open source code? If there are a large number of maintainers for open source repos, then as security vulnerabilities are discovered, a new CVE might be filed to warn against vulnerable versions of those open source software (OSS) components. But what if someone is using some OSS library that’s maintained by a single person who doesn’t really have the time or capacity to file a new CVE for their code base?

Can we really blame them? Most of the time, people develop new OSS libraries as a hobby but still have full time jobs, families, and other personal commitments. Some developers purposely bypass filing a formal CVE thinking that this would only raise awareness of a security vulnerability that could be widely exploited. At the end of the day, everyone is human and all decisions are objective.

In the end, maybe a developer just fixes the problem and creates a new version of their OSS library with a few commit messages detailing the fix. Without a CVE, security tools that use vulnerability databases such as the National Vulnerability Database (NVD), have no way to identify a new security risk in code or deployment artifacts as they’re being scanned. This creates hidden vulnerabilities in older versions of OSS libraries.

If an older version of a vulnerable OSS package is pinned in a configuration file, there is the chance that it can be running in your environment and exploited by stealthy hackers who have the same public visibility into the OSS repos as anyone else. What you now have is the potential for attacks using an unknown (or unknown from a vulnerability database perspective) vulnerability leading to potentially breached systems and data.

Now, if you don’t believe there could be hidden vulnerabilities, we should all be reminded that the single biggest, most critical vulnerability in recent history had been sitting in the codebase of Apache’s Log4j OSS since 2013. It went undetected for almost a decade before it was discovered and set the internet on fire. There could be many other hidden dangers in OSS packages that simply haven’t been exploited yet. This comic depicts how complicated and potentially unstable modern software and systems could be:

How much is OSS used?

“It has been estimated that Free and Open Source Software (FOSS) constitutes 70-90% of any given piece of modern software solutions.” – The Linux Foundation

There is plenty of additional data around the use of open source software, such as what’s noted in this article:

“An April 2022 industry study found that 97 percent of software contains some amount of open source. Most concerningly, 81 percent of the codebases containing open source had at least one vulnerability, with an average of five high-risk or critical vulnerabilities per application that remain unpatched.”

A common saying in cloud security is – you can’t secure what you can’t see. That’s why phase one of most security practices focus on increasing visibility and inventorying everything that runs in your cloud environment. The next phase is typically focused on identifying risk in the form of cloud misconfigurations and vulnerabilities that might exist in your environment. To find issues even earlier, security scanning can be embedded into the software development process, so known OSS vulnerabilities can be detected and fixed before ever being deployed in the first place.

But, if risk can’t be identified because a vulnerability is present but hidden (or lacks a CVE ID), how will an organization know if they are exposed to possible exploits in the wild? Unfortunately, there’s no way to secure something you can’t see. So what can you do?

Behavior-based threat detection to the rescue!

Behavior-based threat detection is a cloud security capability that involves understanding what’s normal about your cloud and what’s not. By detecting anomalies in cloud workload behaviors, you can detect activity that signals malicious intent.

When a system is compromised, it behaves differently than usual. What if you could observe a cloud environment, its resources, and applications that are running, learning what’s normal and healthy? For example, App A (which was built with OSS dependencies) runs particular processes every day and connects to the same endpoints every day. Then one day, something new is running. Did a developer change the app’s functionality, introducing new features? Could be. But it’s different, which makes it noteworthy. All of a sudden, the app starts making calls to new and different cloud APIs or endpoints, which seems strange. When new anomalous behavior is observed, a behavioral based threat detection solution will raise an alert and provide full context around why the alert has been generated so a team can investigate.

In this fictitious example, it turns out there was a remote code execution (RCE) vulnerability present and an attacker escalated privileges and started to discover details about the application environment. Luckily, the threat was detected by the abnormal activity that was observed and a security analyst was able to contain and remove the threat before any real damage took place.

Unknown threats need to be uncovered and secured

Whether vulnerabilities are well known or completely unknown, behavior-based threat detection can be the safety net necessary to catch bad actors in your cloud environment. And while we used the idea of hidden vulnerabilities in open source software to illustrate an unknown threat, there could be other variants of unknown threats lingering around or ones that haven’t even been developed yet.

Developers are creating and shipping new workloads into cloud environments at breakneck speed. Because cloud workloads are dynamic, ephemeral, and generate  absurd amounts of data,securing cloud workloads requires a novel and dynamic solution that can leverage that data to comprehend healthy behavior so anomalies can be surfaced for immediate inspection. But if this is so critical in cloud security, why don’t more vendors offer this capability? Short answer – it’s incredibly difficult to deliver this type of data-driven cloud security. However, it is necessary. Because a solution that can only detect known threats and identify known vulnerabilities in software might be contributing to a significant visibility gap. Nobody wants to operate blindly in the cloud.

If you want to learn more about how the Lacework Polygraph Data Platform® delivers behavior-based threat detection so you can discover anomalous activity and zero in on true threats, visit polygraph.com.