Do you know where your VPC egress traffic is headed?

null

Securing cloud egress traffic is a huge issue for any organisation operating in the public cloud. No matter what industry you compete in, you undoubtedly must comply with internal best practices and/or industry regulations that require you to maintain tight control over all the data traffic leaving your cloud, to guard against both internal threats and external attacks.

Public cloud environments may complicate your ability to see and control the data leaving a virtual private cloud (VPC) as it heads to an external location, due to issues such as the lack of firewalls or span ports to monitor all the network traffic exiting each VPC. The lack of visibility creates serious issues. For example, Payment Card Industry (PCI) standards dictate how companies must securely collect, store, process, and transmit credit card-related information

PCI standards mandate that organisations have controls and restrictions in place to deny unauthorised outbound traffic related to cardholder data. The PCI Security Standard explicitly calls out requirements for internet-bound traffic, specifying that companies must restrict traffic to only the data necessary for cardholder transactions, while actively denying all other traffic. Organisations failing to comply with PCI standards, or unable to prove compliance, risk significant financial penalties.

But as you add more and more VPCs—usually as silos spun up by various internal DevOps and cloud teams—legacy networking tools make it difficult for your cloud teams to provide corporate compliance officers with information about whether network traffic is violating regulatory requirements or exposing confidential intellectual property or personally identifiable information (PII).

In other words, VPC egress traffic has become a blind spot for cloud and IT teams, making it nearly impossible for cloud engineers to distinguish between legitimate and illegitimate destinations. For that reason, VPC egress security—including gaining visibility and applying controls—has become a vulnerability for the entire organisation.

Public cloud infrastructure and legacy networking approaches may fall short

It’s not as if cloud or traditional networking vendors are ignoring the issue of VPC egress security.

As one example, Amazon Web Services (AWS)—the leading public cloud infrastructure vendor by any measure—offers its customers a number of methods for securing resources in their VPC networks. These methods include subnet-level routing rules, stateful EC2 instance security group rules, stateless subnet network access control list (ACL) rules, VPC flow logs, VPC endpoints, and AWS network address translation (NAT) gateways.

Through its AWS partner network, AWS also offers host-based network security solutions, including OS-native capabilities such as iptables or Windows Firewall as well as third-party security software; forward proxy servers, which act as intermediaries for requests from internal users and servers.

Because these solutions are largely designed to support only basic access to VPC segments, they are unsuitable or limited when it comes to securely connecting multiple segments that may be globally distributed within a cloud provider, let alone distributed across multiple clouds and on-premises datacentres. Networking is not a primary focus for any of the public cloud infrastructure vendors because it’s not their main business. As a result, public cloud vendors can be expected to offer only partial solutions for things like VPC egress security.

To overcome the limitations of cloud providers’ network services, the traditional networking vendors have taken the approach of modifying their legacy hardware-based networking and security equipment to operate in public cloud environments. Networking vendors have introduced virtualised routers (called vRouters) based on their hardware equipment, along with virtualised firewall products.

vRouters are essentially instance-based software routers that can be deployed on public cloud compute instances. Their role is to connect an enterprise’s VPCs within the public cloud, as well as connect on-premises and off-premises enterprise entities such as datacentres and branches.

These vRouters are not integrated with the public cloud infrastructure and do not understand the public cloud providers’ ‘underlay’ networking constructs and services. Their inherent complexity means that operating them still requires heavily certified and specialised network engineering expertise—as well as long timelines to set up, change, or maintain even the most rudimentary networking functionality.

These vRouters include legacy capabilities and functions, as well as outdated operational interfaces that do not fit well with the DevOps ways and cloud-speed practices of modern cloud networking. vRouters also strain operational efficiency by requiring egress traffic requests to undergo a tedious process of trouble tickets and manual configuration and testing. Similarly, open-source web proxies, which cache and forward website requests, often require manual configuration of policies on a per-VPC basis and offer limited protocol support (e.g. http only), making them insufficient for use in cloud deployments where a myriad of other protocols are also used.

Organisations trying to use legacy networking vendors’ vRouters struggle to see and control VPC egress traffic to the satisfaction of strict regulatory requirements, or even industry best practices. As a result, they face uncertainty about whether or not they are in compliance with security standards such as PCI—and proving compliance is nearly impossible.

How software-defined cloud routers can enable VPC egress security

As public cloud adoption grows in both scale and importance, it’s no longer good enough to try making traditional, complex networking a little less complex, or a little more bearable. Instead, issues such as VPC egress security demand an approach that is designed for how the cloud—and today’s cloud engineer—works.

One such new approach is the software-defined (SD) cloud router. Although they fall generally under the cloud router umbrella, SD cloud routers represent a new category. They are not adapted from hardware-based networking technology, as vRouters or virtual firewalls are. Instead, SD cloud routers are purpose-built to be public cloud-aware, to support modern cloud networking, and to be operated by modern cloud and DevOps teams. And because they function as inline gateways, SD cloud routers enable connectivity but also include built-in security to support requirements such as egress traffic filtering.

SD cloud routers enable you to build public cloud-centric IT architectures, rapidly and easily, while overcoming networking and security limitations of the cloud providers’ native network services. This new generation of cloud routers supports the new requirements, use cases, and operational practices that are essential for modern cloud networking.

SD cloud routers have the following key attributes:

  • Simplicity with centralised control via APIs and deep integration with public cloud providers’ native network services and control plane.
  • High degree of automation – treat the network like infrastructure as code so that cloud and DevOps teams can implement use case-driven network services themselves, without needing advanced network engineering skills or certifications.
  • Built-in security services and encryption to protect enterprise data and enable enterprises to achieve compliance with security and data privacy regulations.
  • High performance, with wire-speed IPSec on virtual machines.
  • Multicloud capability that spans AWS, Microsoft Azure, and Google Cloud environments as well as on-premises environments.

Using SD cloud routers, it’s easy for enterprise cloud teams to distinguish legitimate outbound VPC traffic—such as conducting enterprise software updates, making API calls, or using a third-party application or software-as-a-service (SaaS) solution over the internet—from illegitimate requests that can put enterprise data at risk or result in a failed compliance audit. Once acceptable and unacceptable sites are identified, an engineer can easily create allow/deny rules to support the security and regulatory requirements of the organisation.

Unlike previous approaches that specified egress policies at the IP address level, SD cloud routers can handle domain names with multiple IP addresses, and they can overcome public cloud providers’ limitations on the number of IP addresses that can be filtered. By providing Layer 7, fully qualified domain name (FQDN) discovery from AWS EC2 instances in the VPC, SD cloud routers allow you to filter for specific IP addresses, hostnames, and websites across any port and protocol.

By overcoming the limitations of the public cloud providers’ tools, virtualised firewall appliances, and virtualised hardware routers, SD cloud routers open new possibilities for enterprises that rely increasingly on the public cloud for their core business operations. Now, you have a powerful, easy-to-use tool for visualising and centrally managing security for all your VPCs, including discovery and control over egress traffic.

And you can finally answer ‘yes’ to the all-important question: Do you know where your VPC egress traffic is headed?

Frank Cabri, Vice President of Marketing, Aviatrix
Image Credit: Everything Possible / Shutterstock