Minimizing the PCI Compliance Burden Using Containerization, Microservices, and AWS

By Josh Quint, Sr. Director of Cloud Solutions at ServerCentral Turing Group (SCTG)

Payment Card Industry (PCI) compliance can become complicated rather quickly. Because of the nature of compliance requirements, anything cardholder data touches becomes in-scope for the audit, and is then subject to the scrutiny of the auditor.

Dealing with this fact is cumbersome and time-consuming, and increases the risk of non-compliance.

Compliance with the PCI Data Security Standard (DSS) relies on a number of controls and checkpoints to ensure sensitive cardholder data is not exposed to unauthorized access. The focus is to ensure encryption of data transmission and data storage, as well as the security of the software, hardware, and network the data itself comes in contact with.

There are also controls that have to do with access to the data and infrastructure. These include user access controls, network firewalls, physical access to the hardware, and even the workstations developers and systems administrators use to access the environment.

Two classic strategies for reducing the compliance burden are segmentation of cardholder data, and transfer of responsibilities to a third party. Segmentation helps quarantine parts of the environment so the whole network is not subject to evaluation. Transferring responsibilities to a third party can reduce workload and systems/equipment acquisition, and enable faster time to compliance.

While these strategies often eliminate many compliance-related tasks, you can use cloud-based technologies to further reduce the scope and eliminate even more compliance tasks.

In this post, I will demonstrate how a combination of segmentation and Amazon Web Services (AWS) technologies can help organizations reduce their PCI compliance burden.

ServerCentral Turing Group (SCTG) is an AWS Partner Network (APN) Advanced Consulting Partner and Managed Service Provider (MSP) with AWS Competencies in DevOps and Government. Our MSP and consulting services provide assessment, development, migration, management, and optimization so customers can focus on their core business.

The Situation

A major small business accounting SaaS provider approached SCTG to help offload some of their PCI compliance burden. Since they are a SaaS company, this firm wanted to get back to their core mission of developing innovative software for customers around the world, and spend less time navigating the PCI compliance landscape.

The application in scope for PCI compliance was a fairly standard three-tiered software-as-a-service (SaaS) application. The application itself, however, did not depend on cardholder data for its core operation. Cardholder data was only used to process payments of users who registered for access to the environment.

Recognizing this, the firm’s development team had already segmented the payment processor service from the core application, and was running this on separate hardware in their data centers. This segmentation allowed for a smaller compliance footprint within their application and data centers; however, the firm was still fully responsible for all controls in the PCI specification.

Although they had reduced the number of systems in scope for PCI compliance, they had not reduced the number of PCI compliance controls they were responsible for.

Figure 1 – Distribution of PCI controls between the client, SCTG, and AWS – starting point.

The firm felt their next logical step in reducing PCI compliance scope was to move the payment processor service out of the data centers. This was the initial ask of SCTG—to assist the accounting firm in building a PCI-compliant infrastructure on Amazon Web Services (AWS) and reduce the number of PCI compliance controls they had to manage.

The Solution

These are the major steps SCTG took toward a solution:

1. Remove the physicality controls.
2. Move up the stack.
3. Automate us out of responsibility.

Step 1: Removing the Physicality Controls

A PCI compliance audit is like any other kind of audit—meet the requirements, demonstrate the results, and earn the checkmark.

As AWS holds service-provider level PCI compliance, and many AWS services are already PCI compliant, simply moving the workloads to the cloud would transfer many PCI compliance tasks to AWS.

Studying the AWS Shared Responsibility Model, it became clear that physical, infrastructure, and backbone network components would be the responsibility of AWS.

Figure 2 – AWS Shared Security Responsibility Model.

The firm’s payment processor service ran on fairly standard Linux servers. These were deployed using a standard Linux package manager and were exposed by an HTTPS API endpoint with its own fully-qualified domain name (FQDN).

So, the firm’s concept of a lift-and-shift migration of the service from data center hardware to Amazon Elastic Compute Cloud (Amazon EC2) instances and AWS Application Load Balancers would reduce their burden for any items related to physical security, as well as some backbone and edge networking items.

However, this still left the SaaS firm responsible for the management of the server’s operating systems and user access control to those servers. The burden to ensure patching, antivirus, and proper user roles were all up-to-date, and compliance was still significant.

SCTG’s managed services offerings on AWS offered some relief to the SaaS firm’s responsibility, but the SCTG AWS architecture team continued to look for improvements.

Figure 3 – Distribution of PCI controls between the client, SCTG, and AWS – after lift and shift.

Step 2: Moving Up the Stack

During the early discovery phase of the engagement, SCTG found that while the application in scope was being deployed as a standard Linux service, the development team was using Docker containerization in their local development environments. This presented an opportunity to make a significant change to the infrastructure architecture to further limit the amount of compliance responsibility for the SaaS firm and SCTG.

SCTG designed an infrastructure based on Amazon Elastic Container Service (Amazon ECS) running on AWS Fargate to run the payment processing service in the Docker container the development team was already using for testing purposes. This had a profound impact on the PCI compliance burden and the resiliency and scalability of the payment processing service.

In terms of resiliency and scale, this opened up a far more flexible architecture for this service. Given the critical nature of the service, the firm opted to go for a multi-region architecture. SCTG designed and built identical Amazon ECS environments running on AWS Fargate in two US regions using AWS CloudFormation and Amazon Route 53 Domain Naming Service (DNS) routing with health checks.

SCTG configured AWS Fargate to run at least two containers of the service in each region in multiple AWS Availability Zones. Auto scaling was also set up to launch additional containers as needed to respond to user demand.

From a PCI compliance standpoint, this pushed the controls around securing and patching the operating systems onto AWS, as neither SCTG or the SaaS provider had access to the underlying instances.

This effectively shifted most of the infrastructure controls onto AWS. SCTG was left with the responsibility of maintaining security group and network access control lists (NACLs), AWS Identity and Access Management (IAM) access, and API endpoint security. The SaaS provider only had to focus on the compliance within the application itself.

Step 3: Automating Us Out of Responsibility

Even with the PCI compliance scope minimized from an infrastructure standpoint, there were still improvements to be made around the process of maintaining compliance.

The firm’s development team had already begun some of the groundwork for automating the build and local deployment of the payment processor service. They had built a series of Jenkins jobs to handle code checkout and Docker container builds. This opened the door for adding PCI compliance-related tasks to the deployment automation.

SCTG built a companion Jenkins server on the edge of the AWS environment to handle full end-to-end deployments into the production environment. It gave the development staff no direct access to the cardholder data environment.

SCTG expanded on the original Docker image build jobs to include jobs that run Common Vulnerability and Exposure (CVE) scans against the image once it’s pushed up to Amazon Elastic Container Registry (Amazon ECR).

Any high priority vulnerabilities trigger a failed build and an alert to the development team. This eliminated the requirement to manually scan the environment when material changes were made, as scans were performed for every code release. Additionally, the necessary quarterly scans were scheduled in the same system.

Figure 4 – Architecture of the system SCTG designed to automate build and deployment.

To reduce the amount of work on SCTG’s managed services engineers, we implemented further automation to ensure the continuous compliance of the environment. SCTG used Amazon GuardDuty for edge intrusion detection in the environment, and configured it to send alerts via Amazon Simple Notification Service (Amazon SNS) to SCTG’s Slack and ticketing systems.

AWS Config was heavily used to ensure IAM and other account-level security conditions, such as password strength and multifactor authentication (MFA) enforcement, and key rotation were continuously monitored.

SCTG ensured endpoint security by using Application Load Balancers with PCI-compliant cipher suites installed, and AWS WAF configured with a PCI-compliant commercial ruleset.

SCTG also used functionality from CloudCheckr to monitor and alert on any changes to the environment reported by AWS CloudTrail. This ensured no unauthorized changes were made to IAM, security groups, NACLs, and other resources within the AWS environment.

Continuous Results

Once the final architecture was running, the only part of the application the SaaS provider needed to worry about was the application itself. All other components are managed by AWS or SCTG’s automation-focused managed services.

With the automation in place and the use of an AWS-managed infrastructure, the compliance burden on SCTG staff is minimal. The only necessary intervention involved gathering reports from the automated systems to present to the auditors, and responding to any new CVEs or updates from the development team.

Figure 5 – Distribution of PCI controls between the client, SCTG, and AWS – after automation

One of the key benefits of a fully automated deployment and compliance architecture is that all resources that come in contact with cardholder data are completely hands-off from developers and systems administrators. This effectively eliminates the potential for data leakage into untrusted environments.

Additionally, SCTG’s managed services teams are freed from having to continually check the infrastructure against compliance controls, as they are alerted if anything falls outside of spec the moment it happens.

Considering the pay-per-use pricing model of AWS Fargate, and the fact the payment processor service is lightweight, costs to run the environment are significantly lower than running a traditional server-based environment. The cost to run this multi-region, auto scaling, and auto-healing environment is less than half of the anticipated cost to run on a pair of traditional Amazon EC2 instances in a single region.

Interestingly, the cost of the resources to deploy and scan the environment for vulnerabilities is actually more than the run cost of the service itself.

When we presented our solution to the PCI auditors, it took them some time to evaluate. We had to collaboratively analyze the architecture to determine the PCI implications and create a PCI responsibilities matrix. With an auditor who had cloud experience, however, our audit discovery meeting, which was slated for a whole day, took only 45 minutes.

Conclusion

Leveraging cloud-based microservices is not a solution that works for everyone or every application, but it’s one more point in favor of transitioning legacy applications to microservices.

If you’re already looking to re-architect, consider it an opportunity to spin out regulated data into separate containers. From there, it’s not much more effort to move those containers to AWS.

Even if the rest of your applications stay where they are, you can lift most of the compliance burden off your team and get the agility, security, and efficiency of the cloud.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

.

ServerCentral Turing Group – APN Partner Spotlight

SCTG is an AWS Competency Partner and Managed Services Provider. Their MSP and consulting services provide assessment, development, migration, management, and optimization so customers can focus on their core business.

Contact SCTG | Practice Overview

*Already worked with SCTG? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.