Why choose Panoptica?
Four reasons you need the industry’s leading cloud-native security solution.
Before AWS, before buckets, and before SLAs, the term “cloud” referred to white puffs in the sky telling us if rain was on the horizon or not. Security in on-prem environments focused heavily on the constructs of the perimeter. Point solution strategies, which were seen as the way to protect these castle-and-moat architectures, involved using independent tools to solve each issue. This construct worked well until the cloud-native era began, heralding a far more flexible environment. And at the same time, the countless settings and configuration options that exist within every cloud deployment, if not implemented properly, can lead to major vulnerabilities. These configuration vulnerabilities can occur for lots of reasons, but they primarily happen due to human error in the setting stage.
Other common issues can be detected in the cloud:
In light of the multiple potential issues, we have seen the evolution to security strategies that focus on meeting compliance standards with the intention of preventing breaches. Called Cloud Security Posture Management tools (CSPM), these tools help organizations identify risks and adhere to compliance regulations via security assessments and monitoring. In theory, CSPM tools should create transparency and enable a reduction in attacks and breaches. But this isn't the complete truth. Current CSPM tools are lacking, and relying on them solely to protect your cloud-native environment may put your organization at risk.
To start, CSPM tools fail to take into account the fact that while one configuration on its own might be a-okay, when paired up with another one, it might actually result in a risky situation.
For example, let’s imagine you have an EC2 instance exposed to the internet and Lambda that has a permission to remove EC2 instances is fine. But if the EC2 has invoked Lambda, that creates a problem. Since the EC2 instance which is exposed to the internet has now high permission, an attacker who compromises the EC2 can invoke Lambda, which can remove other EC2 instances in the environment.
Another issue is that these tools do not prioritize between major threats and less pressing ones, and often fail to catch important events altogether.
For example, how can our cloud security analyst make a decision, regarding which findings should be taken care of first--clear text credentials in environment variables or an EC2 instance with an exposed port 22 to 0.0.0.0/0?
The answer is based on the impact and potential damage that this finding can lead to, and not the severity of the finding themselves. Think about it; following the CIS Benchmark, the port 22 finding is High -- but if this server is an empty test server without any Security Groups and with no IAM roles attached, there won’t be any impact!
On top of that, these tools rely on using overly strict permission policies which create far more alerts and white noise than necessary. Moreover, relying on alerts to find out about incidents is inherently a reactive stance.
A significant element missing in the world of CSPM is the context, i.e., the full view into the circumstances that act as the background or setting for an event. Understanding the context of incidents in your cloud environment is essential. The thing is that attackers don't look for, and honestly don't care about, specific vulnerabilities. They look for the easiest and fastest way to reach their target. Attackers look at systems as graphs, searching out the best path between the different nodes.
When looking at the attack path, a low-risk finding, such as a known CVE, plus a specific over-permissive policy, can come together to create a critically risky path that may leave sensitive cloud assets vulnerable to attackers. And your CSPM tool would never even detect that “staring-you-in-the-face” issue.
Here's an example of how a configuration vulnerability, taking advantage of a malicious EC2 Instance creation, can expose organizations to threats:
As you see, the combination of the above elements, whether exploitable on their own or not, can lead to a potential attack path or a risky topology that you wouldn't have anticipated by relying on being compliant alone. And this is how an attacker sees your environment -- they don't see the independent vulnerabilities -- instead they see the easiest and most direct routes into your cloud environment, and use any configuration vulnerabilities and relationships between them to access your environment.