Cloud native security measures are primarily focused on safeguarding against identifiable threats, employing innovative technologies like big data and AI to monitor and preempt potential attacks. Despite these efforts, however, no system can ever be completely impervious to threats. Even with state-of-the-art protections in place, cloud security is never truly good enough if there remain unidentified vulnerabilities. In this article, we explore how CloudGuard‘s next-generation Web Application and API Protection can help mitigate these unknown risks and strengthen your overall security posture.

Security experts focus on known risk indicators.

Our industry typically focuses on examining potential avenues for exploitation by attackers and identifying methods for avoiding errors in our coding. However, the most detrimental attacks are those that catch us completely unaware, and we only become aware of their presence when they are already in the process of attacking us. Our discussion today centers on identifying these types of threats early on and preventing them altogether with the use of CloudGuard WAF.

A brief history of cloud so far

It Started around 12 years ago with our new ability to run much stronger algorithms.

  • We were finally able to collect and analyze data in a big way… in fact that’s what we called it: big data.
  • But we also needed a way to store this data in a cost-efficient way and hence virtual networks were born.
  • Meanwhile with mobile applications blowing up all over the world, data suddenly needed to move around, be everywhere… we got cloud ISPs.  Cloud computing challenges were addressed by running everything as scalable code that’s broken down into services that run on virtual machines that become active on call.
  • By this time, Machine learning was introduced to optimize our data and generate deep insights.
  • Kubernetes was introduced to provide further granularity for coding and running services.
  • Crypto drove to the rise of GPU processing and generative AI became a thing.
  • And finally, it was Covid that gave the cloud its biggest push.

Remote end points, data accessed from everywhere, and the speed of technology all require cloud services. Today, businesses small to large are already on the cloud or getting there.

The cloud is not a problem – it’s a solution.

The Cloud has become an integral part of our daily lives, having matured to a point where its presence is ubiquitous. As cloud professionals, we often find ourselves engrossed in resolving its associated challenges, and it is easy to forget just how magnificent the cloud truly is. The cloud has afforded us numerous benefits and possibilities that were once impossible to imagine. Admittedly, it has also presented its fair share of problems. However, it is imperative that we realize that the cloud is not the problem; it is the solution. By harnessing the benefits of the cloud, we can improve security measures in the coming years, and amplify what we do to the next level.

It’s all about data exchange:

Applications are based on two main channels of data exchange: The cloud front door, where users submit requests for various services from the cloud application via public internet, mobile networks, and VPNs. Then there’s the service door – from which code and data is continuously pushed into to keep the application running. So, basically, we protect the wiring. We try to understand each request that is made, and we have a set of tools to confirm that the exchange is safe.

Each user request is a potential threat….

But this wealth of data exchange through various channels and hybrid clouds… can also mean trouble. If you look at this simplified supply chain diagram, you can immediately see the many components that exchange data and can potentially serve as backdoors for hackers to penetrate your environment.

Each time data is exchanged between components, there is a risk that the exchange will be breached or manipulated. Add to that, the fact that you rely on so many 3rd party feeds and services exchanging data, that may also have their own set of vulnerabilities.

We prepare our troops for battle and do everything you we can to protect our assets in the field… but our main target should be to avoid the war in the first place….

To safeguard our business, we employ various security measures such as WAF for the front door, CSPM and workload protection for the cloud contents, and code scanning and network security for the end point. With these measures in place, we feel confident that we can handle any known risks. However, we cannot discount the possibility of unknown risks, which is why we remain vigilant and adaptable in our approach to security.

Let’s try to understand what we are protecting ourselves from starting with some basic definitions:

Known vulnerabilities means either stuff that we do ourselves such as:

  1. misconfigurations or hidden credentials,
  2. known vulnerabilities – which may allow malicious activity until patched and…
  3. dynamic risk indicators based a wide database of attack indicators such as suspicious behavioral patterns, malicious IPs, attack patterns etc.

By continuously looking for these issues and indicators we can provide posture, protection, and zero-tolerance across your application network.

Unknown vulnerabilities may be:

  1. undiscovered software vulnerabilities, that may cause a software component to deviate from its original assignment and allow access or manipulation.
  2. vulnerable backdoors, some by design (for example a forgot password function) and unintentional backdoors – discovered by malicious actors or
  3. and finally, simply new attack techniques and methods which hackers are busy inventing all the time and we don’t know about yet…

Because we don’t really know how to protect against these unknown risks – they are of-course exactly what attackers are looking for and that’s also why zero-day exploits have become so common.

CVEs are Unknown Until We Have a Signature

The basic way in which we communicate unknown vulnerabilities is by using CVEs or Common Vulnerability and exposure – it’s our way to keep security teams updated with the latest problems and often with their solutions and patches.

In 2022 alone, over 25,000 new CVEs were discovered by internet users worldwide – that’s the highest reported annual figure to date. This means that on average, our poor security guy would start his morning with 68 CVEs, one third of which would be high or critical risks. That’s 68 NEW CVEs every single day of the year.

But it’s also interesting to point out that resolving a CVE takes 65 days on average, so until there is a stable patch to fix the core issue the only line of defense you have is you WAF, and your WAF is blind to unknown attacks until a signature is released.

Let’s continue this story focusing on log4shell as our main use case.

Log4Shell is a great example because it ticks all the boxes:

  • Log4j is a java logging library that is used by hundreds of millions of machines. There can hardly be a large application that does not utilize it in some way or form.
  • It was hacked over 800,000 times in its first 72 hours, both because it was easy to hack and allowed attackers to gain deep access.
  • It’s almost impossible to evaluate the number of attacks since 2021 but we do have an estimate of over 1.5 billion dollars’ worth of damages so that should give you some kind of indication.
  • And interestingly, 1 out of 4 apps still have problematic log4j versions, because you couldn’t get to all of them even if you tried.

 

Log4shell also shows how things can get worse before they improve.

  • In this case the vulnerability was discovered on November 24th and assigned a CVE number two days later.
  • A week later in December first, there had already been evidence of exploitation in the wild.
  • The real mess started on December 9th – which was the first time Apache publicly disclosed the vulnerability, this included a patch for the affected log4j2. I seemed that organizations could start their mitigation immediately; however, it took another five long days for Apache to realize that the even more popular log4j1 was in fact vulnerable as well, so patching had to start over.
  • To make things even more complicated and additional CVE was published on Dec 17th disclosing many more exploit scenarios… in fact over a month later, issues and variants were still being disclosed, and only after 35 days, security teams were finally able to start patching critical assets. Now it’s simple math here folks – if it took 35 days to contain and on average it’s going to take you another 65 days to remediate, that means you are exposed to the worst kind of attacks for a hundred days!! That’s a lot of days.
  • An attacker can easily attach a malicious string to a simple login or search request taking advantage of a java logging vulnerability.

Log4Shell is an exploit of Log4j’s “message substitution” feature—which allowed for programmatic modification of event logs by inserting strings that call for external content. The code that supported this feature allowed for “lookups” using the Java Naming and Directory Interface (JNDI) URLs. So, all an attacker will need to do is to insert text with embedded malicious JNDI URLs into requests to software using Log4j in the LDAP logging Server—these URLs result in remote code being loaded and executed by the logger. Attackers have been exploiting the vulnerability to compromise virtualization infrastructure, install and execute ransomware, steal system credentials, take broad control of compromised networks, and exfiltrate data.

 

From Static Analysis to contextual AI

So, was there a way to block log4Shell? The simple answer is YES. And the way to do that is of course by using machine learning and artificial intelligence to their fullest potential.

In the past AI has allowed us great things – it started with the ability to optimize the way we handle large amount of data or to improve processes… and with the rise of CNAPP and data consolidation we can now look at our threat data as a whole and derive insights that help us improve and scale our security.

But what if we could use the same AI to look inwards rather than outwards? If we gain a deep understanding of the application’s normal behavior, we should be able to detect anything that falls outside of that norm and simply block it!

Let’s take a look at how we use CloudGuard WAF to do exactly that.

CloudGuard WAF uses a patented machine learning engine to continuously analyses users’ web and API requests over HTTP. WAF’s AI engine learns how users normally interact with your web application and automatically detects requests that fall outside of normal operations. These requests are further analyzed to decide whether the request is malicious or not. This precision brings with it almost 0 false positives and allows us to block issues without relying on signatures or rules.

CloudGuard WAF is a new generation of web application firewalls. It is distributed as nano agents within the cloud environment, effectively intercepting all http interactions and analyzing them in real time. CloudGuard WAF does not rely on signatures or rules to block attacks, we use two steps to ensure we are protected against both known and unknown risks.

In stage 1, the machine-learning-based enforcement engine looks for attack indicators within the HTTP request. The evaluation is based on a supervised model that identifies indicators and associates them with a specific, statistical likelihood or “score” of being part of an attack.

Scores are assigned for each indicator by itself and for pairs of indicators. In addition, indicators are associated with certain attack families in which they typically occur. The scoring process allows CloudGuard to take an accurate initial decision about the attack likelihood of the HTTP request.

This is where your traditional WAF stops.

But the second part is where the interesting stuff happens:

Suspicious requests are analyzed in the contextual machine learning evaluation engine to gain further confidence, that any HTTP request, which was indicated as being potentially malicious, is indeed an attack. We correlate additional parameters such as: application structure, user/crowd behavior, user content and transactions, and more.

This results in extremely precise detection, effectively flagging any irregular or harmful request and blocking it from entry.

CloudGuard WAF has successfully blocked ALL major zero-day attacks in past years including Log4Shell, Spring4Shell and MOVEit. Our customers were protected from day one, they didn’t even need to run an update.

Watch the following video for the full story and learn how you can protect yourself from known and unknown threats using CloudGuard CNAPP.

UNIFIED, PREVENTION-FIRST CLOUD SECURITY PLATFORM

CloudGuard CNAPP serves as a unified platform dedicated to securing your cloud environment. With its prevention-first approach, it allows for consistent and repeatable enforcement across cloud providers. We cover you from risks, regardless of their origin, before they reach production and at runtime, known and unknown alike.

 

You may also like