Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Answers

How To Apply Network Security To a Cloud Environment To Support PCI Compliance

There are several requirements, established by the Payment Card Industry, which dictate how companies securely collect, store, process, and transmit credit card numbers. These requirements are divided into six categories:

  1. Build and Maintain a Secure Network and Systems
  2. Protect Cardholder Data
  3. Maintain a Vulnerability Management Program
  4. Implement Strong Access Control Measures
  5. Regularly Monitor and Test Networks
  6. Maintain an Information Security Policy

This article discusses how the Aviatrix Secure Egress and Distributed Firewalling solutions fulfill two specific requirements in the “Build and Maintain a Secure Network and Systems” category for customers in public clouds (such as AWS, Azure, or Google Cloud):

1.2.1 Limit inbound and outbound traffic to only what is necessary for the cardholder data environment, and explicitly deny all other traffic.

and

1.3.4 Prevent unauthorized outbound traffic from the cardholder data environment to the Internet.

Opt for a Cloud-Native Solution

Approaches to achieving and maintaining PCI compliance that may have been effective in the data center do not always work when implemented in public clouds. There are two common mistakes when attempting to use data center solutions in the cloud.

Mistake #1: Distribute traditional firewalls in every VPC/VNET

In the cloud era, creating a new VPC/VNET is a frequent occurrence and only takes a few minutes. To keep up with this pace, your network operations must be automated and agile. You should be able to deploy and tear down firewalls quickly and ideally without human intervention.

Traditional firewalls and their virtual counterparts do not meet this requirement. It is very challenging, often impossible, to fully automate these non-cloud-native appliances in your AWS, Azure or GCP environments. This makes security a bottleneck and can cause friction among your teams. Moreover, as your cloud environment expands, having one of these heavyweight devices in every VPC will quickly become cost-prohibitive due to increasing IaaS charges (often requiring large instance types to operate), and firewall licenses.

Mistake #2: Centralize firewalls in an “Inspection Hub/VPC”

This solution involves creating a single, centralized, inspection VPC either leveraging virtual machines or cloud-native firewalling services. While this is a common solution, it can create several significant challenges. issues presented with the previous option is to

use a single (or multiple) firewall that centralizes both management and execution. However, numerous problems arise with this approach:

  1. This often requires major network architecture changes, and can cause significant challenges, especially for Internet Egress security where IP addresses may need to change.
  2. Traffic needs to be routed to one (or several) central VPC/VNet, requiring extra work for your operations team and additional costs to connect the VPCs. Complex, manual routing, and load-balancing is then required to steer traffic through the firewall.
  3. This design creates a natural choke point on the central VPC/VNet(s).
  4. Scaling requires additional load-balancers which add cost to the solution, and are complex to configure. While auto-scaling is possible, adding instances to the load-balancing pool can take 30 minutes.
  5. There are additional, unnecessary data transfer costs to send traffic from the VPCs to the central VPC. Packets that eventually pass the firewall rules will incur 2x data transfer charges (once leaving the original VPC and once leaving the central VPC).

Security That’s Built-In, not Bolted-On

Satisfying PCI Requirements: Aviatrix Distributed Firewalling

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

In the context of PCI, segmentation aims to limit lateral movement, preventing attackers from exploiting systems outside the Cardholder Data Environment and accessing sensitive data within the network. Segmentation also narrows the scope of PCI security requirements. Aviatrix Distributed Firewalling integrates security into the network, providing centralized policy management, visibility, and control while distributing policy enforcement near the application environment. Unlike traditional firewalls, the Aviatrix Secure Cloud Networking architecture leverages cloud-native design principles for improved scalability, performance, and cost optimization.

Aviatrix deploys automated, lightweight gateways within your VPC/VNet(s) to manage inbound and outbound traffic. With cloud applications being more dynamic, IP addresses prove inefficient for defining policies. Aviatrix’s Distributed Firewalling policies use “SmartGroups” – dynamic policy objects whose membership is based on cloud-native tags and attributes. Policies reference SmartGroups as sources and destinations, applying Layer 4 and Layer 7 (FQDN/SNI) restrictions. The Aviatrix controller automatically provisions the appropriate policies on the necessary gateways, keeping traffic local to the VPC unless permitted by firewall policies.

To accommodate modern cloud demands, gateways and policies can be automated using Terraform, CloudFormation, custom scripts, or API and Python/Go SDKs. Audit logs facilitate PCI compliance assessment, proving compliance during audits as crucial as having the framework in place. Aviatrix audit logs display allowed and denied traffic for easy evaluation.

The Aviatrix Stateful Firewall allows users to control traffic within a VPC or VNET from a central management console. Users can create , edit, and manage security policies that define the following:

  • Source and Destination SmartGroups
  • Protocol(s)
  • Port(s)
  • L7 profiles such as allowed FQDNs

Policies are centrally defined and maintained, while rule execution takes place within the Aviatrix gateway in each VPC or VNET. This approach ensures a seamless and efficient security framework, tailored to the dynamic nature of cloud environments.

Satisfying PCI Requirements: Aviatrix Secure Egress

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

The Aviatrix Secure Egress solution is designed to address this requirement.

Internet egress security is a critical part of achieving PCI compliance. PCI gives some high-level recommendations. Aviatrix Secure Egress can easily be integrating with existing architecture as a 1:1 replacement for cloud-native NAT gateways, and can be deployed either via a GUI or Terraform.

In addition to IP-based and tag-based policies, Aviatrix gateways can perform egress traffic filtering. This feature allows outbound internet traffic to be filtered using full or wildcard-based hostnames.

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 that includes a wildcard (for example *.amazonaws.com).

In addition to least-privilege access filtering, Aviatrix Secure Egress layers on advanced security such as Threat Prevention, and Geoblocking.

Discover Zero Trust Policy Automatically

In numerous instances, your engineering team might not be aware of or recall all the external hosts requiring internet access. To address this, Aviatrix offers automatic policy discovery. By enabling this feature, the gateway operates in a “learning” mode, monitoring and recording all outbound traffic. During this mode, you can review the accessed hosts

and create your policy based on this list, incorporating additional input from your engineers as needed.

Aviatrix Advantage

The Aviatrix Network Security offers several advantages over other solutions:

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.

Distributed Enforcement

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.

Small Failure Domains

Systems with PCI data are business critical. Distributed policy enforcement reduces the impact a potential failure.

Lower TCO

Aviatrix Secure Cloud Networking Gateways are built for the cloud and can utilize low-cost burstable instances rather than large, expensive compute. Local egress security reduces unnecessary data transfer charges to a centralized inspection VPC.

Automation

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

Built-In Audit Logs

All traffic (flows, rule hits, domains) and configuration changes are centrally logged, and can be viewed with Aviatrix CoPilot or sent to centralized logging services such as Splunk, Sumo Logic, etc.