Tools Resources Plans

Context is The Key to Achieving Security in the Cloud

Vladi Sandler

Tuesday, Nov 24th, 2020

Background

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.

Types of Configuration Vulnerabilities

Misconfigurations – human error in configuration; i.e., you intended to set x but instead set y (for example, public instead of private access)
Weak Configurations – configurations that do not follow best practice for an asset or entity that can be hardened (for example, using tls 1.1 instead of tls 1.3)
Dangerous Defaults – the default configuration created by the Cloud Service
Provider causes a security issue (for example, data not encrypted, by default)

Other common issues can be detected in the cloud:

CVEs (Common Vulnerabilities and Exposures)
Compromised assets
Unprotected (Kubernetes) Secrets
Risky Permissions / Risky Relations

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.

Cloud Environment from the attacker's perspective

Why isn't CSPM enough?

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:

An attacker exploits an application CVE and gains remote access to an EC2 Instance which is exposed to the internet (e.g. 0.0.0.0/0 to port 443).
The compromised EC2 instance is attached with an IAM role, which includes a policy with the action EC2:RunInstances. This action can be used to create an EC2 Instance and even define it as public.
The attacker has two options of exploitation:
1. To create the EC2 instance in an unused region, to gain long term persistency.
2. To create in the local subnet in use to start performing lateral movement.
Now the attacker can gain access to the instance in a few different ways. One way would be to create/import an SSH key and associate it with the instance on creation, so they can SSH into it.

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.

Get Started

Solutions

Tools

Resources

Plans