If your organization stores or processes credit cardholder data, here’s a fact you’re probably already quite familiar with: Maintaining PCI DSS compliance internally is no easy feat.
Points of weakness for a data breach can occur anywhere in the network chain. Without proper isolation, that makes identifying and monitoring entry points for unauthorized access a huge operational headache.
So what does proper isolation look like? Check out the following example using an INAP Dedicated Private Cloud.
Isolated Security Zones in a PCI Compliant Private Cloud
Employing multi-layer security architecture, the Cardholder Data Environment (CDE) in the above architecture diagram is securely isolated from other networks and applications in the cloud.
(Note: This configuration will also work for dedicated server architectures and the security principals outlined apply generally to a broad range of use cases.)
Let’s go through it step-by-step:
- A shopper accesses an e-commerce retailer’s website from the public web.
- The customer’s request is first sent to a Load Balancer, which helps maintain application and network stability by distributing traffic to web servers based on the number of existing connections. Each load balancer includes a SSL certificate that encrypts and authenticates each session.
- The load balancers also contain a Web Application Firewall (WAF), which protect against application-level coding issues that may allow illicit requests to enter the protected network and permit cardholder data to be exposed.
- When the customer is ready to make a purchase and enter their credit card number and personal information, the request leaves the web network (the DMZ) and enters the CDE (Trusted Zone). After passing through a redundant firewall, the request goes directly to the application servers, which power the payment portal. Note that the application servers process business logic for the website while the web servers render web pages and communicate with customer browsers. The firewall only allows the web servers to communicate with the app servers, securing the customer’s checkout process.
- The app servers communicate directly with the database servers, which search and store records. In this example, a clustered pair shares the data, though this could be a single VM.
- The AD servers (Active Directory) are required for server clustering. However, some environments may use AD or LDAP (Lightweight Directory Access Protocol) for storing usernames and credentials.
- But here’s the important thing to remember – passing a PCI DSS Audit requires more than just isolating and securing the CDE. You must ensure procedures are in place and resources allocated to monitoring and scanning to comply with specific sub-requirements. If you’re an INAP Shield Plus Compliance customer, that’s covered for you.
- Threat Manager is a combined intrusion detection sensor (IDS) and vulnerability scanner. The vulnerability scanner meets a sub-requirement designated in the PCI DSS, which dictates that scans be performed quarterly. Threat Manager allows for more frequent scanning, however, and includes the option for on-demand scans, providing the INAP Shield Plus Security Operations Center (SOC) team with up-to-date information on the environment. The IDS sensor included in Threat Manager is also required under the DSS and is monitored 24/7 by the SOC.
- PCI DSS requires that logs be inspected daily. With Shield, technicians take care of these critical, but tedious, inspections for you. Log Manager streamlines all your logs, including operating system event logs and application logs, into a single, chronological list so that logging can be more easily correlated.
- The Management Zone, which includes cloud backups and your cloud management console. This has restricted access and is well-protected using two factor authentication for administration.
Updated: January 2019