Tools Resources Plans

Why Securing Your Cloud Is Completely Different From Securing Your On-prem Environment

Vladi Sandler

Thursday, Apr 29th, 2021

There’s a new generation of attackers among us, that can’t be denied. Offensive methodologies are constantly changing, and as organizations aggressively move to the cloud, these need to be understood before they can be protected against.

One key challenge I’ve seen in cloud security is how to encourage companies to move away from their traditional on-premises security concepts to protect cloud-native environments.

In this article, I’ll look at two attack concepts that are extremely familiar to anyone in the security industry, initial access and lateral movement, and application layer attacks. I’ll compare the methods of protecting your environments for on-prem and for a cloud environment, including both Blue Team and Red Team approaches, and I’ll explain the differentiation.

Initial Step Access and Lateral Movement

On-premises, malicious office macros, and PowerShell deployments are still the most common method of attacking organizational environments, usually via Phishing scams. The Blue Team approach is to use workload protection such as EDR platforms, or configuring Intrusion Detection Systems (IDS/IPS) that usually compare network packets to a list of known threats to flag your attention to an attack.

From a Red Team angle, an attacker will complete reconnaissance on the workstation, and look for a way to get around the Local Security Authorization. The attacker may pull or brute force NTLM hashes to find local or domain admin credentials, or they might use a Man-in-the-Middle attack to get the credentials that they are looking for. Examples of techniques used in this approach include ARP attacks that alter the routing, and MDNS or LLMNR attacks where the hacker forces communication with their own system by spoofing an authoritative source.

Attack and Protection Strategies from the Perspective of a Cloud Environment

Firstly, the same Blue Team approach. The layer of permissions and configurations in an on-premises environment simply doesn’t exist on the cloud. The Blue Team can’t use tools like EDR to protect against cloud threats. Even if you consider cloud-workload protection platforms (CWPP) that were intended to meet this threat on the cloud, they by design only alert you to problems once they have already occurred.

Now, the Red Team approach. Without Layer 2 on the cloud, an ARP poisoning attack would be impossible, and AWS automatically blocks these kinds of attacks anyway. It’s clear that this kind of Man-in-the-Middle is firmly an on-premises problem.

In terms of stealing credentials, the environment is also managed completely differently to an on-premises one. Cloud environments are handled and protected using permissions and configurations such as IAM and Security Groups, so therefore the attackers will need to exploit a different layer of the cloud to achieve lateral movement. That doesn’t mean that lateral movement and persistency aren’t possible. In fact, it’s a real risk, especially if you’re only well-versed in on-premises threats. On the cloud, lateral movement and privilege escalation occurs when organizations have missed vulnerabilities in configuration, such as “Privilege Escalation via ec2:RunInstances Permission”.

Application Layer

OWASP Top 10 is the standard awareness document that security teams use in order to identify critical application security risks. A Red Team approach that mimics an attacker will try to exploit these and see whether they can obtain data, or cause financial or reputational damage. The attacker can use the same application security offensive methodologies for any application, whether it’s on server or serverless architecture. The attacker may also opt for flooding or Denial of Service attacks to breach the application.

On the other side of the table, your Blue Team will be using defenses such as Web Application Firewalls, anti-bot to monitor applications, and serverless runtime protection solutions.

Turning back to the cloud, none of these approaches are relevant. Your CSP (cloud service provider) will be responsible for protecting the customer against bot attacks, and your attention should be on common application and platform layer misconfigurations. Here are a few common examples that I’ve seen:

- Default credentials for the UAA service of AWS Cloud Foundry which can lead to a platform takeover. - Kubernetes Argo CD API exposed to the internet with an admin cluster role, allowing attackers to perform a takeover of the whole cluster. - Lambda function with risky internet-facing permissions giving the ability to invoke access to the cloud infrastructure. - Denial of Wallet attacks, similar to DoS attacks on-prem, but on serverless, these fictitious requests will cause resources to continue to scale.

Your Blue Team will likely turn to cloud compliance based solutions like the CWPP we’ve discussed above. Unfortunately, compliance-based solutions are not aimed at shoring up cloud security. In fact, all the companies that were hacked in the past few years were fully compliant, they just weren’t secure.) Your organization may choose to keep using the on-premise tools like runtime protection, but these will only detect part of the attack surface.

Your Cloud Deserves Its Own Security Strategy

Digital transformation has changed everything. The benefits are huge for forward-thinking companies who are leveraging new technologies, and many of the old risks have been removed from the attack surface.

However, it would be naïve to assume that new technology doesn’t equal new risks, and these two examples put that reality in the spotlight. New risks require us to fundamentally change the way we approach security. You can’t rely on what you think you know about on-premises environments to protect yourself on the cloud. Both from the perspective of the attacker, and for your own defensive strategy, it’s time to think again.

Ready to see how Panoptica does it? Schedule a call.

Get Started

Solutions

Tools

Resources

Plans