How to Boost Security in Amazon Virtual Private Cloud

Home / Blog / How to Boost Security in Amazon Virtual Private Cloud
Sourced blog How to Boost Security in Amazon Virtual Private Cloud

At its best, cloud is a secure environment offering ways to meet or exceed the most rigorous regulatory standards. Yet unless certain measures are implemented, inherent security problems can undermine efforts to protect systems and data.

Organisations that are new to the cloud are most susceptible to this problem, especially following a time-pressured migration. For instance, virtual private cloud (VPC) networks may be compromised by security gaps or issues that nobody is aware of.

Here we highlight some common cloud security threats related to VPCs, suggesting how to reduce risk with improved security practices.

Examples in this blog relate to the author’s specialist knowledge of Amazon Web Services (AWS). Check out his previous blogpost which looks at how to get cloud security off to a strong start in AWS.

The Inherent Risks of VPC

One major security issue relates to cloud providers’ default VPC network configurations. They use public subnets which, by definition, have a network path to/from the internet potentially exposing the network to malicious actors. Things can be done to address this, and most organisations’ firewalls will control any inbound access. However, data exfiltration is a risk factor which may be overlooked. Proactive steps must be taken to mitigate this, such as rerouting default VPC configurations to improve security and auditing controls.

Another factor to be aware of is the use of service endpoints to facilitate communication between VPC-deployed resources and services. From an Amazon VPC perspective, this exposure to the public internet as the default configuration of service endpoints allows access to all related AWS resources in the region. The associated risks extend beyond AWS, since network and gateway load balancers in unrelated AWS entities can potentially be used as a vector by external individuals or organisations.

The below diagram shows how the gateway VPC service endpoints of S3 buckets can be abused by cybercriminals. These are simple examples to illustrate the point, but in reality, there are many other possibilities.

In the first scenario, an S3 VPC endpoint provides a network path to all S3 buckets in that region. An attacker with an unauthorised AWS account creates an S3 bucket which is loaded with malware and downloaded to an EC2 instance in the enterprise account. To achieve this, the attacker bypasses the EC2 instance’s default identity and access management (IAM) policies and permissions. The EC2 instance is instructed not to use the enterprise’s IAM Role credentials, but to use the unauthorised account’s credentials instead.

The second scenario follows the same principle, but the malware in the attacker’s S3 bucket is more dynamic. Instead of downloading the malware directly, the attacker uses the compromised EC2 instance to upload a text file which contains instructions to download another external file. Next, the S3 Event Notifications property is used to trigger a Lambda function. This parses the instructions in the text file, using them to download a file from the internet which is then placed in the S3 bucket from where the attacker can download it.

Sourced abuse of VPC service endpoints diagram

Interface VPC endpoints such as AWS PrivateLink endpoints offer ways to establish connectivity between VPCs and AWS services without exposing data to the internet. Public AWS services are presented as private IP addresses, which helps secure application traffic when data is being exchanged. However, VPC endpoints are not immune to risk either.

So, what’s the best way to leverage the advantages of VPCs while managing and mitigating the security risks?

Four Ways to Enhance Cloud Security When Using VPCs

Classic layered approaches to security are very effective in the cloud, but to enable security at scale they must be implemented in a reliable and repeatable way that doesn’t hinder productivity. While VPCs offer a ‘private’ environment, individual assets still need to be protected as well as the network perimeter. It’s also important to identify any potential routes cybercriminals might take to exfiltrate data or compromise the network. Here’s a top-line overview of four approaches that can enhance security.

1. Establish AWS VPC Endpoint Policies

Endpoint policies can be used alongside resource-specific or identity policies, controlling which IAM Principals access the endpoint service.

To maximise cost-efficiency think about centralising endpoints (and thereby the policies attached to them) for production and non-production environments. This might happen in conjunction with an AWS Organisations strategy where accounts are categorised as production, non-production, or portfolio and separated accordingly. However, it’s not possible to attach more than one policy to a single endpoint, so this approach may not be suitable in circumstances where more granular control is required.

Since there is no simple one-size-fits-all solution, threat modeling is a useful exercise when determining the best way to secure endpoints. This might involve looking at the pros and cons of centralised versus decentralised endpoints. Alternatively, it could explore methods such as the use of ‘explicit denies’ applied at the root of an AWS Organisation.

2. Secure the Perimeter

To overcome potential issues linked to the ingress and egress of application traffic, steps should be taken to secure the network perimeter. These measures become more sophisticated when cloud-native approaches are adopted as standard.

Ingress might be allowed directly into an AWS account as long as sufficient security controls are in place. With internet egress, it can be useful to centralise traffic in services accounts or dedicated perimeter accounts, using forward proxies.

A forward proxy operates as an intermediary between a resource deployed in an AWS VPC and a resource on the internet. It provides an extra layer of security by inspecting and filtering network traffic. Without a proxy, clients are directly connected to the internet, leaving them vulnerable to various security risks. Forward proxies allow administrators to manage this proactively.

For instance, a forward proxy in whitelist mode only allows access to approved websites or resources. It acts as a gatekeeper, so clients can’t access unauthorised or potentially malicious websites where malware might be accidentally downloaded. Similarly, whitelisting can hinder payload execution, preventing techniques such as reverse shell where attackers gain access to remote systems.

Compared to transparent proxies, forward proxies offer more control and customisation over network traffic. With a transparent proxy, all network traffic is automatically routed through, and clients are unaware of its presence. In contrast, clients must be configured to use a forward proxy, and administrators can specify which websites or resources are accessible. This aligns with the ‘zero-trust’ ethos whereby a VPC-deployed resource cannot reach the internet if it is not aware of the correct proxy. Typically, this is provided to the VPC-deployed resource via automation. It is also important to note that in the ‘reverse shell’ example, an exploit payload may be unaware of the proxy, and will not be able to return status to the attacker. It is possible that the exploit could hunt for a proxy or otherwise find it in the system, but it is an extra step which is not required with transparent proxies.

3. Think Like a Cybercriminal

Data exfiltration is one of the most significant security threats facing cloud-based systems. Malicious actors are continuously looking for vulnerabilities and new ways to exploit them, so keeping one step ahead is essential.

Non-standard data exfiltration vectors should be identified and guarded against. This includes AWS PrivateLink endpoints which can provide direct network access to AWS accounts which may be under the control of a malicious third party. Another risk factor is the domain name system (DNS) where data can potentially be exfiltrated via the Amazon Route 53 Resolvers. Internet Control Message Protocol (ICMP) can also be manipulated and used to encapsulate data.

All these issues and more can be resolved with a meticulous approach to networking rooted in threat modelling. Unauthorised parties can only gain access if they find a means to connect with the system, so fastidious use of standard techniques such as routing domains and transit gateway routes can prove very effective.

4. Make use of Repeatable Patterns

Patterned outcomes offer a great mechanism for the primary control of cloud networks. They can be implemented off-the-shelf by developers, enabling secure and compliant cloud self-service at scale.

Services can be packaged individually or in multiples. For instance, a DynamoDB database might be positioned as a standalone entity whereas a public-facing, load balanced and auto-scaled EC2 fleet could be bundled with a web application firewall.

While a repeatable pattern takes time to set up, it’s a worthwhile investment. After it has passed through security, compliance, and operations reviews, it can be consumed wholesale, with developers adapting it according to their needs. Another benefit is that application teams can inherit new opinions made by the organisation. So, a load balancer could be upgraded to disable an old transport layer security (TLS) version with known vulnerabilities, or new TLS certificates could be provisioned for enhanced security.

Real-World Security Challenges Demand Advanced Cloud Skills

Many aspects of effective cloud security are rooted in the checks, controls, and scanning that underpin standard IT security routines. The challenge is ensuring these are replicated thousands of times across the organisation, especially for large enterprises with a dispersed global team of developers.

When organisations first move to the cloud, there’s a common tendency to underestimate the scale of this challenge. Security is handled in an ad hoc way, quickly leading to vulnerabilities that can easily be exploited. Success lies in the use of cloud native approaches such as automation and self-service, enabling proven security techniques to be built-in, then rolled out repeatedly and reliably as the cloud environment expands. Understanding where vulnerabilities lie, and how to address them cost-effectively from the ground up, is key. Armed with these insights and advanced cloud capabilities, organisations can confidently leverage cloud benefits knowing that security is under control.

Find out more about our cloud security solutions here.

James Peek is based in Toronto, having been with Sourced Group for 4 years. His passions include helping businesses enable secure public cloud consumption at scale. In his free time, he enjoys skydiving, scuba diving and motorbikes.