Learn how to implement the Payment Card Industry Data Security Standard (PCI DSS) for your SAQ A-EP business using Google Cloud Platform. This tutorial provides background about the standard, and then provides a set of guidelines for designing, deploying, and configuring a PCI-DSS-compliant payment-processing application. The tutorial also discusses methods for monitoring, logging, and validating your application.
The PCI DSS, created by the PCI Security Standards Council, is an information security standard for businesses that accept credit card information. The PCI Security Standards Council comprises every major credit card company; as such, businesses that take Visa, MasterCard, Discover, American Express, or JCB are expected to be PCI DSS compliant, and can be fined or penalized if they are not.
The PCI DSS includes classifications for several merchant types, from merchants who collect information in person to merchants that outsource payment processing entirely. This tutorial focuses on the SAQ A-EP merchant type, in which the merchant provides an interface for collecting credit card information, but passes the validation and processing of this information to a PCI DSS Certified Payment Processor. As an SAQ A-EP merchant, you must ensure the security of customer credit information up to and including the point at which the information is passed to the PCI DSS Certified Payment Processor.
- Review the payment-processing application architecture
- Set up your payment-processing environment
- Deploy and configure your application servers
- Set up logging and monitoring
- Validate your payment-processing environment
Your company sells subscriptions for an online business-accounting software service. The company is growing fast, and so is the number of payments the company needs to process—in fact, the company is on track to be processing several million transactions a year in the near future.
As your number of transactions increases, your PCI DSS merchant level also increases; and as your merchant level increases, the PCI DSS's compliance guidelines become stricter. At the highest merchant level, Level 1—defined by American Express as 2.5 million annual transactions, and by Visa, Mastercard, and Discover as 6 million annual transactions—the PCI DSS requires a mandatory audit. As such, you must make sure that your payment-processing environment has been audited to support your merchant level.
Because Google Cloud Platform is a Level 1 PCI DSS 3.2 compliant service provider, it can support your PCI DSS compliance needs no matter which merchant level you are.
The payment-processing architecture has been designed to be simple, with few moving components. The architecture centers around a payment-processing application that runs on a group of Google Compute Engine virtual machine instances. These instances exist within a secure private network, and use secure channels to communicate with a small set of services that are external to that network.
At a high level, the payment-processing flow is as follows:
- The customer inputs their credit card information into a payment form that your company owns and maintains.
- When the customer submits their information, the form information is securely passed on to an external payment processor.
- The external payment processor checks the credit card information, and then charges or declines the card.
- The payment processor sends a response back to your payment application, which then passes a message to your core application.
The customer-facing flow of your payment processing application is designed as follows:
When your customer accesses the URL for your payment form, they are routed to the form securely through an HTTPS load balancer. When the customer submits their credit card information, your payment-processing application securely sends the information to an external payment processor. The external payment processor accepts or declines the card, then returns a response to your payment-processing application.
The application's internal flow is designed as follows:
Your payment-processing application receives and parses the response returned by the external payment processor, and then sends some or all of the response data to your company's core application. At this point, your payment-processing application's job is finished. The core application goes on to handle the task of notifying your customer.
Monitoring and logging flow
The monitoring and logging flow is designed as follows:
Every server in the payment-processing application network sends its logs to Stackdriver Monitoring and Stackdriver Logging, using Squid proxy servers to securely transmit the log data.
Set up your payment-processing environment
This section describes how to set up your payment-processing environment. Setup includes:
- Setting up a new Cloud Platform account to isolate your payment-processing environment from your production environment
- Restricting access to your environment
- Setting up your virtual resources
- Design the base Linux image you will use when setting up your application servers
Set up a new account
To simplify access restriction and compliance auditing, you must create a production-quality payment-processing environment that is fully isolated from your standard production environment. To ensure full isolation, create and use a Google Cloud Platform account that is separate from your core production environment account.
Restrict access to your environment
When managing permissions for your payment-processing environment, allow access only to individuals who will be deploying your payment system code or managing your payment system machines. Use Google Cloud Identity & Access Management (IAM) roles to restrict access. See the Cloud IAM docs for more information.
In addition, the PCI DSS requires these individuals to pass a background check, in compliance with local laws, before they are granted access to the environment. To lower the risk of compliance violations, consider performing criminal background checks and reference checks on each individual as well.
Secure your network
To secure inbound and outbound traffic to and from your payment-processing application's network, you need to create the following:
- Compute Engine firewall rules
- A Compute Engine VPN tunnel
- A Compute Engine HTTPS load balancer
Use firewall rules to restrict inbound traffic to each of your Compute Engine instances. Only allow inbound traffic from the following three sources:
- Public HTTPS, so that customers can reach your payments page.
- Your application network, so that your payment-processing application can receive responses from your external payment processor.
- Your internal office network, so that you can access the instances as necessary for auditing and management purposes.
iptables on the individual instances to restrict outbound traffic.
Only allow outbound traffic from your payments form to the
external payment processor. This connection must be HTTPS-only.
Traffic must be restricted as follows:
|Source||Destination||Port||Direction and reason|
|Public load balancer||External payments form||tcp:443||Inbound
Public access to the payment-processing application
|External payments form||External payment processor||tcp:443||Outbound
Forwarding AUTH requests to payment service provider
|External payment processor||Your payment-processing application||tcp:5480||Inbound
Accepting AUTH requests from payment systems (does not contain any cardholder data)
|Your company's office network||vpn-gateway||tcp:8000||Inbound
Access to payment-processing environment for access to logs and development machines
In addition, the following traffic occurs securely within your payment-processing application's internal network:
|card-form||pci-proxy||tcp:5480||Exchange of encrypted card data for payment instrument token|
|All hosts||Squid proxy||tcp:3128||Sending traffic to Google services|
|All hosts||Google NTP servers||udp:123||Time synchronization|
|vpn-gateway||All hosts||tcp:22||SSH connections|
Compute Engine provides a VPN service that you can use to establish a secure VPN tunnel between your on-premises environment and your payment-processing environment.
HTTPS load balancer
You can ensure that incoming customer traffic is secure by creating a Compute Engine HTTPS load balancer. To create an HTTPS load balancer, you need the following:
- A subdomain of your website that will be used for your payment processing form—for example, payments.your-domain-name.com.
- A valid, signed SSL certificate that has been registered for your subdomain.
Make sure that your domain is valid by looking at its DNS settings in your web registrar's domain configuration interface.
Create a base Linux image
The PCI DSS contains a set of rules that describe how to set up machines that are part of an A-EP payment-processing architecture. These rules can be implemented in several ways, but the easiest approach is as follows:
- Create a concrete list of the software and libraries that must be installed on each server in your payment-processing application. To avoid introducing unnecessary vulnerabilities to your system, include only the bare minimum of software and libraries needed to run your application. Candidates might include the Cloud SDK, language-specific runtimes and libraries, or a web server.
- Create a Compute Engine instance that uses one of Compute Engine's preconfigured operating system images.
- Install the libraries and software you listed earlier.
- Make sure that the image follows the best practices for creating a secure Compute Engine image.
- After you've configured your base image, create a custom Compute Engine disk image from your image. This image will allow you to use your base Linux image when creating new virtual machine instances.
Deployment and configuration
Next, set up the deployment and configuration of your instances from your base image.
Deploy your environment
To meet the PCI DSS requirements, you must make sure that you're deploying the correct application every time, that you're deploying the application securely, and that you aren't installing any other software packages during the deployment. To simplify the deployment process, consider creating an automated deployment for your application using Google Cloud Deployment Manager.
Cloud Deployment Manager enables you to describe your entire payment-processing environment, including its firewall rules, gateways, load balancers, and instances. Deploying through Cloud Deployment Manager has the additional advantage of helping you to easily construct an audit trail of how each application environment was created, allowing you to version environments as you make improvements and modifications.
Within this automated deployment, you will also need to verify the integrity of the software being deployed, whether the software is third-party or your own. You can verify your software by running automated checksums against each package as the package is installed. After the checksum is verified, you can then use an automated testing framework to run security and other tests, and to verify that the tests have passed.
Finally, when deploying Compute Engine instances, make sure to design a recovery plan in the event that the instances fail. If your window for acceptable downtime is large enough, a manual recovery plan might be sufficient; if not, you must design an automated recovery plan. See the Disaster Recovery Cookbook, Designing Robust Systems, and Building Scalable and Resilient Web Applications for guidance.
Configure your environment
After your instances have been deployed, make sure that they're configured correctly. Install additional software and libraries on top of each instance's base image as needed. To avoid the complexity, overhead, and overall risk that manual configuration can entail, use an automated configuration management tool such as Chef, Puppet, Ansible, or Salt.
iptables to log all inbound and outbound activity
For each application server, set up
iptables to log all network traffic
into and out of your server. This data is required for PCI DSS compliance
Install the Stackdriver Logging agent
After you set up
iptables on your servers, each server will log
every activity to the server's block storage. To retain these logs
and to generate alerts based on abnormal activity, stream them to
Stackdriver Logging and Stackdriver Monitoring respectively by
installing the Stackdriver Logging agent on each
Integrate an intrusion detection system (IDS)
To help ensure the security of your payment-processing environment, use an intrusion detection system (IDS) to identify when people attempt to attack the system. There are two ways to place an IDS within a payment-processing environment: you can place an IDS at every entry point, or you can install an IDS on every device.
To reduce the complexity of your environment's architecture, install an IDS on each device. After you research and choose the IDS software you'd like to use, you can make its installation part of the standard startup installation script for each server.
IDS logs fall within the purview of PCI DSS compliance, and must be sent to Stackdriver Logging and Stackdriver Monitoring for reporting, alerting, and future auditing purposes.
Automate the deployment of your application
Configure your configuration management tool to securely retrieve and launch the latest version of your application. Your application can be retrieved from any location, such as Google Cloud Storage, as long as that location is secure.
Use a Squid proxy server to restrict traffic between your application's location and your payment-processing environment.
Stream your configuration manager logs to your logging and monitoring endpoints
When setting up your configuration manager, make sure that it logs all installation details and, after completing the configuration process, delivers the logs to Stackdriver Logging and Stackdriver Monitoring.
Logging and monitoring
To ensure PCI DSS compliance, you must make sure that every step taken in payment-processing environment is monitored and recorded. Every server activity on every instance must be logged, and every user action must be able to be examined at a later time if needed.
Set up a Squid proxy server
Stackdriver Logging and Stackdriver Monitoring are external to your payment-processing application network. As such, you need to set up a system that will limit where your monitoring and logging traffic goes after it leaves your controlled environment. You also need to be able to do so in a way that is controlled and auditable.
You can use a Squid proxy server to restrict traffic leaving your payment-processing application network. By using a Squid proxy server, you can send traffic to Stackdriver Logging and Stackdriver Monitoring directly while ensuring that your instances are only allowed to send traffic to those endpoints. Using a Squid proxy server also allows you to track and log additional data that can prove helpful when verifying the security and expectedness of traffic patterns.
For instructions on how to set to up a Squid proxy server on Compute Engine, see Setting up a network proxy. To avoid bottlenecks, set up at least two redundant proxy servers.
Log internal access data
In addition to logging external threats, you must monitor and log the activity of the individuals who have administrative access to your payment-processing environment. To do this, you can log shell commands. Several open source tools are capable of auditing shell commands and send them to logging. Popular choices for this task include OSSEC or Tripwire.
Set up monitoring alerts
Configure Stackdriver Monitoring to send alerts if something goes wrong within your payment-processing environment. Base your alerting strategy on the likely risk or attack vectors for each component of your payment-processing application. For example, Stackdriver Monitoring alerts should be triggered if your IDS detects any intrusion attempts, whether successful or unsuccessful.
Stream logs to BigQuery
Optionally, you can export Stackdriver logs to Google BigQuery for later analysis. Because BigQuery is optimized for performing queries on large sets of data, it is an ideal tool for performing large-scale logs analysis.
After your environment is implemented, but before any production traffic flows through it, you must have the environment validated:
- If you're a Level 1 vendor, your environment must be validated by a Qualified Security Assessor (QSA). A QSA is a firm or individual who has been approved by the PCI Security Standards Council to validate PCI environments and give the seal of approval.
- If you're a Level 2 vendor or lower, you can validate your environment by filling out the Self Assessment Questionnaire.
Try other tutorials
Try out other Google Cloud Platform features for yourself. Have a look at our tutorials.