How do I make my VPC egress traffic PCI compliant?
Learning Center | Answers | Egress Filtering
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:
- 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.
- This design forces a natural choke point on the central VPC/VNet(s).
- 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.
- 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
that can be reached (or not reached).
An example of a Security Policy in Aviatrix Controller user interface.
Policies are defined and maintained centrally, but the execution of the rules happens within the Aviatrix gateway in each VPC or VNET
The table below outlines how Aviatrix helps you meet each of the PCI DSS testing procedures outlined in the standard document.
|PCI DSS Testing Procedure||How Aviatrix Helps|
|1.2.1.a Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.||Firewall rules can be managed from a central console allowing you to examine your firewall rules in one place. If you are automating your verification of VPCs, you can automate this step using Aviatrix APIs (or with one of our SDKs).
In addition, Aviatrix tag-based policies (aliases for your CIDR range(s)) make policies easy to read for you and your auditor.
Finally, Aviatrix includes an audit log which provides deep audit capabilities including a graphical dashboard of what IPs and domains were allowed and which were denied.
|1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.|
|1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.||Aviatrix stateful firewall allows you to specify a base policy of “deny all”. This means that all traffic, by default, is denied.|
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.
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.
The table below outlines how Aviatrix FQDN Filter helps you meet the PCI DSS Testing Procedure defined in the standard document:
|PCI DSS Testing Procedure||How Aviatrix Helps|
|1.3.4 Examine firewall and router configurations to verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized.||Centrally managed policies make examining the configuration simple with Aviatrix. Each VPC (or VNet) is associated with a set of policies that control what domain(s) and IP address(es) traffic from that VPC (or VNet) is allowed to access. These rules are readily available in the central console along with an audit log of what domains and IPs were allowed outbound to the internet and what domains and IPs were blocked.|
The Aviatrix firewall (including egress security filter) has several advantages over other solutions:
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.
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.
Aviatrix gateways are fully automated. All functionality you can do with the UI you can also do via a script, CloudFormation template, or Terraform.
Allowed and/or denied destination IPs and domain names are logged and can be viewed in logging services such as Splunk, Sumo Logic, etc.