How do I make my VPC/VNet egress traffic PCI compliant?

There are a number of requirements, maintained by the Payment Card Industry, that define how companies securely collect, store, process, and transmit credit card numbers. These requirements are broken down into six categories:

• Build and Maintain a Secure Network and Systems

• Protect Cardholder Data

• Maintain a Vulnerability Management Program

• Implement Strong Access Control Measures

• Regularly Monitor and Test Networks

• Maintain an Information Security Policy

This article examines how using the Aviatrix stateful firewall satisfies two specific requirements in the "Build and Maintain a Secure Network and Systems" category for customers in public clouds (including AWS, Azure, or Google Cloud):

1.2.1 Restrict inbound and outbound traffic to only that which is  necessary for the cardholder data environment, and specifically deny all  other traffic. 
 
1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. 

Choose a Cloud-Native Solution

Solutions for achieving and maintaining PCI compliance that may have worked in the data center do not always work when applied in the public clouds. There are two common mistakes when attempting to use data center solutions in the cloud.

Mistake #1: Using a non-cloud native, traditional firewall in every VPC/VNET

In the cloud era, adding a new VPC/VNET happens regularly and only takes a few minutes. In order to keep up with this, your network operations must be automated and agile. You must be able to deploy and teardown firewalls quickly and ideally without human intervention.

Traditional firewalls and their virtual counterparts do not meet this requirement. It is very difficult, often impossible, to fully automate these non-cloud-native appliances in your AWS or Azure environment. This slows everything down and causes friction in your teams. And, as your cloud environment grows having one of these heavy-weight devices in every VPC will quickly become cost-prohibitive as your EC2 instance charges (often these require large instance types to operate) and firewall license charges grow.

Mistake #2: Using a centralized firewall

It may seem like the natural solution to the problems presented with the previous option is to use a single (or multiple) firewall that centralizes both the management and the execution. However, there are numerous problems with this approach:

1. You will need to route the traffic to one (or several) central VPC/VNet. This requires additional work for your operations team and additional costs to connect the VPCs.

2. This design forces a natural choke point on the central VPC/VNet(s).

3. Scaling is not designed into the architecture. The central firewall(s) will be limited to the size of the instance. This forces you to continuously monitor and increase the instance size as bandwidth increases.

4. There are additional, unnecessary egress costs to send the traffic from the VPCs to the central VPC. Packets that eventually pass the firewall rules will incur 2X egress charge (once going out the original VPC and once going out the central VPC).

Aviatrix Inline, Cloud-Native Firewall

Aviatrix's stateful, centrally managed, and locally applied firewall policies solve the problems that traditional firewalls are unable to in the cloud. Aviatrix solution deploys cloud-native, lightweight, fully automated gateways in your VPC/VNet(s) to control traffic in and out. Firewall policies can be defined as IP-based rules (with optional port and protocol) or as full or wildcard host names from a central console web UI (or API). This means you won't be burdened with going to every VPC/VNet to add, change, or review a policy. Instead, policies are automatically deployed to the VPC/VNet from the central controller. With this approach, traffic stays local to the VPC and only leaves if allowed by the firewall policies.

And, to keep up with the demands of today's cloud world, the gateways and policies can be automated using Terraform, CloudFormation, or custom scripts using the API or Python/Go SDKs.

Finally, audit logs provide the perfect way to audit your PCI compliance. Being able to prove, once you are in an audit, that you are compliant is as important as having the actual compliance framework in place. With Aviatrix, audit logs showing what traffic is allowed and what traffic is denied, makes this task easy. Here is one, high-level example of what domains are being accessed by a specific VPC:

Satisfying PCI Requirements

Let's take a look at how using the Aviatrix stateful firewall helps you meet 2 of the PCI requirements.

SECTION  1.2.1 - Restrict inbound and outbound traffic to that which is  necessary for the cardholder data environment, and specifically deny all  other traffic

Controlling traffic flowing in and out of a VPC/VNET can easily be handled with the Aviatrix stateful firewall.

Controlling Traffic with Aviatrix Stateful Firewall

Aviatrix stateful firewall allows users to control what traffic flows in and out of a VPC or VNET. From a central management console, users create, edit, and manage security policies that define the:

• source and destination CIDR,

• protocol(s), and

• port(s)

that can be reached (or not reached).

Policies are defined and maintained centrally, but the execution of the rules happens within the Aviatrix gateway in each VPC or VNET

Validation

The table below outlines how Aviatrix helps you meet each of the PCI DSS testing procedures outlined in the standard document.

SECTION 1.3.4 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet

Aviatrix VPC Egress traffic filtering is designed to address this requirement.

Aviatrix Egress Security Filter

In addition to IP-based policies, Aviatrix gateways can perform egress traffic filtering. This feature allows outbound internet traffic to be filtered using full or wildcard-based host names. You can do this in a distributed fashion from each VPC/VNet

You can do this in a centralized fashion from each VPC/VNet

For example, update sites, such as updates.ubuntu.com and windowsupdate.microsoft.com, can be resolved to many IP addresses so these policies can be configured using their domain names. Other hosts, like services provided by AWS, might be allowed more broadly by specifying a policy which includes a wildcard (for example *.amazonaws.com).

Autodiscover Hosts that Require Access

In many cases your engineers may not know or remember all the external hosts that need to access the internet. For this reason, Aviatrix provides an auto-discovery feature on our gateways. With this feature enabled, the gateway operates in "learning" mode, watching and recording all outbound traffic. At any time during this mode, you can look at what hosts are being accessed and develop your policy from this list with input additional from your engineers.

Validation

The table below outlines how Aviatrix FQDN Filter helps you meet the PCI DSS Testing Procedure defined in the standard document:

Aviatrix Advantage

The Aviatrix firewall (including egress security filter) has several advantages over other solutions:

Inline Execution

All traffic for a VPC or VNET is filtered in the VPC/VNET from which the traffic originates. This means that you do not need to send the traffic to another VPC/VNET or back to your data center to do the filtering before going out to the final destination.

Centrally Managed

Policies that apply to each VPC/VNet are centrally managed while the execution is distributed to the inline traffic filters (Aviatrix gateway). The association of policies to a VPC/VNet is done through a central management console via a web browser or API.

Automation

Aviatrix gateways are fully automated. All functionality you can do with the UI you can also do via a script, CloudFormation template, or Terraform.

Audit Logs

Allowed and/or denied destination IPs and domain names are logged and can be viewed in logging services such as Splunk, Sumo Logic, etc.