By Harish Kumar GS, Head of Sales, India and SAARC, Check Point Software Technologies
In the dynamic and swiftly changing digital world, more organizations are turning to cloud-native solutions to fuel their business growth. Projections indicate that the cloud security market in India will grow by 31.45% between 2024 and 2029, reaching a market size of $125.70 million by 2029. According to a report by NASSCOM, cloud technology is set to comprise 8% of India’s GDP by 2026, potentially contributing between $310 and $380 billion to the economy and creating 14 million jobs by that time. With a dedicated and strategic approach, cloud investment could see an annual growth rate of 25-30% from 2022 onward, reaching $18.5 billion, thereby enabling India to fully leverage the cloud market.
Despite these promising prospects, the increasing dependency on cloud infrastructure necessitates stronger security measures. A recent survey reveals that 52% of Indian organizations consider cloud-related threats to be their primary cyber risk concern over the next year. This highlights the urgent need for comprehensive cloud security solutions to protect sensitive information and maintain the integrity of cloud environments. 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.
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.
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 why 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… and so, 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:
- misconfigurations or hidden credentials,
- known vulnerabilities – which may allow malicious activity until patched and…
- 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:
- undiscovered software vulnerabilities, that may cause a software component to deviate from its original assignment and allow access or manipulation.
- vulnerable backdoors, some by design (for example a forgot password function) and unintentional backdoors – discovered by malicious actors or
- 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 according to Statista – 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!
