How to Better Protect Cloud Workloads and Your Crown Jewels

This blog was originally published by Virsec here.

Written by Matt Ambroziak, Virsec.

Previously, I discussed how the attack surface is expanding in the cloud and the cloud-native security tools and best practices available to help mitigate risk. Now, let’s dig a little deeper into how attacks can play out without best practices in place, why cloud workloads are so vulnerable, and how runtime protection fully protects your software and reduces the attack surface.

How attacks can unfold

There are many scenarios under which an attack can happen, for example:

• If you don’t protect your root account with a strong password and multi-factor authentication (MFA), an attacker can gain full administrative rights to spin up new resources or delete your entire account and all the data inside – but not before stealing it.
• When privileged Identity Access Management (IAM) credentials are stolen, threat actors can conduct long-term reconnaissance to achieve a greater goal.
• Misconfigured security groups or firewalls can expose a compute resource to malicious actors who may brute-force attack SSH passwords, or provide network access to web applications that should be locked down.
• Attackers that bypass the firewall, web application firewall (WAF) or other security tools, enter the runtime to exploit a host (a virtual machine (VM), container or serverless function) and run their own code, which is their ultimate goal.

Why cloud workloads are so vulnerable

So, what can an attacker do with one minute of dwell time on your system? In the cloud, the larger attack surface means exploits can move farther, faster and have exponentially greater impact. In the public cloud, you have connections to multiple data sources, network segments and identities, such as IAM users and roles. Identities, vulnerabilities, and misconfigurations are gateways to more data and services and provide the opportunity to move laterally to other hosts within the same virtual private cloud (VPC) or peer VPCs. Worse yet, these points of access may provide connections back to your private data center. The Capital One data breach is one of the most publicized examples of an exploit that unfolded much the same way. Ultimately, the attacker stole credentials to gain read access to locked down, private cloud storage. From there, they had the option to download more than 100 million records to a cloud instance, and then to their local computer.

Once an attacker is “living off the land” within a cloud instance, they have plenty of time and resources to deepen the level of access and further their attack. With specific intentions in mind, their goal is to move closer and closer to the CPU to ultimately execute code of their own. Once they start executing their own code, they have officially entered the runtime of a server workload and have access to the crown jewels as that’s where high-value data is located.

How to protect cloud workloads

There are many cloud-native security solutions to help mitigate risk to your cloud environment. If you look at the solutions offered by Amazon Web Services (AWS) alone, protection against a variety of threats and vulnerabilities is readily available. From AWS Shield to protect against DDoS attacks and AWS WAF to protect against the top OWASP attacks, to services that mitigate risk from misconfigurations and vulnerabilities, protect sensitive data and IAM, and provide continuous threat monitoring and detection.

But we need to do more. Given the many and varied scenarios in which a cloud instance can be weaponized against us, our top priority should be to reduce the attack surface on the server workload. Some best practices that organizations overlay on top of the security solutions available through their cloud service provider, include:

Compliance. Implementing Infrastructure-as-Code to help with cloud oversight. Think of it as templating cloud resources. This ensures tracking when you deploy and un-deploy resources and that no residual assets are left behind that can expose you to risk. Remember that compliance is a continual process and requires constant attention. Most organizations want a person to review any findings, so assets remain exposed until that is complete.

Vulnerability Scanning: Identifying potential points of exploit and patching vulnerabilities. This is essential but is often easier said than done. A risk analysis is required for prioritization, and scans only identify known vulnerabilities for which a patch exists. You remain exposed to unknown threats.

Endpoint Detection and Response (EDR). Collecting and analyzing endpoint activity and data to identify potential threats, contain the threat, and notify personnel. Some tools use a probabilistic approach to determine malicious activity based on machine learning and algorithms. However, results are often laden with false positives and these tools trigger after an event so dwell time is lengthy. One major EDR vendor touts dwell time of less than 36 minutes, but we already know one minute is too much.

True runtime protection. Runtime protection based on what is happening at the host, memory, and web application layers (all the layers that make up the server workload), is aimed specifically at reducing the attack surface in the cloud. Using a deterministic approach, a golden image of a workload’s runtime is taken. With visibility into what is actually happening at runtime, any workload that deviates from its intended purpose is instantly identified and protected. Dwell time is non-existent. And attackers never have a chance to run their own code.

Some organizations have the view that if an attacker wants to get in, they will. But there’s no need for defeatist thinking. There is a lot we can do to reduce the attack surface and protect server workloads in the cloud. Watch this webinar to learn more.