5 Best Practices to Reduce the Attack Surface in the Cloud (Virsec Blog)

Written by Matt Ambroziak, Cloud Solutions & Security Architect, Virsec

Over the last 18 months the cloud has gone mainstream. In case you need proof, Gartner forecasts end-user spending on public cloud services to grow 23.1% in 2021 to total $332.3 billion, up from $270 billion in 2020. However, as more organizations move mission-critical workloads to the cloud and scale to meet the demands of a hybrid workforce model, more cloud services and applications inherently increase the attack surface. A study by McAfee found almost 3.1 million external attacks on cloud user accounts throughout 2020.

As the opportunity for attackers to get access to sensitive data is expanding, how do we minimize that and limit exposure if attackers get into these cloud environments? To keep things simple, in this blog we’ll focus on Amazon Web Services (AWS), the leader in the cloud infrastructure services market, and solutions and best practices available to strengthen protection.

When the public cloud emerged, it reimagined how we would deploy applications and infrastructure and forced us to rethink security for this highly dynamic environment. Cloud native security solutions, such as security groups and network access control lists (NACLs), offer an immediate level of protection at no cost and with nothing to deploy. For example, you can use security groups to restrict traffic based on IP addresses. You can quickly and easily microsegment the environment and secure east-west traffic to restrict lateral movement once an adversary is inside. And these security solutions will scale to the size of your environment transparently; policies you define will always be enforced without performance degradation.

Sounds like you’re done, right? Not so fast.

One reason AWS is so popular is because of the many different services offered for consumption – currently 285 and growing approximately 30 per year. Some of those services create more attack surface. So, with the right credentials combined with loose security policies and a growing list of interconnected services, an attacker has many avenues to take advantage of. A seemingly endless perimeter in the public cloud not only exposes platform services to the internet, but also the control plane for the cloud itself.

So, what is the implication? The network perimeter from the pre-cloud era, is now just one of many. As enterprises move to the cloud they must protect four additional perimeters, because one successful penetration on the right resource can lead to a major incident. In fact, the security industry has many examples of damage that can be done in a mere 60 seconds or less.

1. Data perimeters can allow unauthorized users to read, modify, delete, or download your private data directly from the internet.
2. Compute perimeters can allow external entities to run code in your environment, exploiting software vulnerabilities to compromise workloads.
3. Messaging perimeters can allow external entities to receive and send messages to private systems that can trigger code or transport malicious payloads to downstream applications.
4. Identity perimeters can allow external entities full control over your virtualized data center when privileged Identity Access Management (IAM) users, roles, and access keys are compromised.

Cloud-native security tools are crucial. But these five best practices are also important to reduce the attack surface in the cloud.

1. Deploy proper network segmentation and security. Establish security zones in each of your environments and allow traffic through the firewall for only what is needed and scoped. At a minimum, have a separate VPC for each application and environment, but also consider assigning each application environment (development, staging, and production) its own cloud account.
2. Take advantage of the principle of least privilege. Assign access and resources with purpose. For instance, a developer just deploying code should not have administrative rights across the entire cloud account. Nor should a developer have continuous access to a production environment. Give them exactly what they need and nothing more. There are tools available to help scope accounts and users appropriately.
3. Minimize the install base on computer resources. Install what you need, remove what you don’t. For example, with containers, only install the packages and libraries that your application needs to run. Anything superfluous an attacker can use against you.
4. Patch software to fix vulnerabilities. Patching is essential but it doesn’t address every vulnerability. It is dependent on the vulnerability having been seen in the wild; if you have a version of software that has a zero-day threat, it does nothing for you. And, once a patch is published, it’s a race against time to patch it before an attacker has an opportunity to find and exploit that vulnerability in a system.
5. Stop attacker-influenced code with runtime protection. With all this said, exploits still happen and errors occur. True runtime protection acts as a safety net. It enforces what your application should be doing and stops what it shouldn’t be doing in real-time – before an attack happens. Adversaries are blocked before they can exploit a software vulnerability, known or unknown, or take advantage of misconfigurations, outdated security policies, improperly scoped access rights, and insufficient identity or credential management. Dwell time is non-existent, so threat actors never have a chance to install malware or exfiltrate data. And you gain air cover and time to make updates, while still being protected.