PCI Case Study: Hotelier Automates AWS Security Best-Practices

PCI Case Study: Hotelier Automates AWS Security Best-Practices

By Flux7 Labs
November 25, 2019

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for any organization that processes credit card data. The standard was created to increase controls around cardholder data to reduce credit card fraud. While PCI has been around for almost 15 years now, new challenges around the standard emerge as companies migrate systems that are subject to PCI Auditing to the cloud. In today’s blog post, we’ll share the story of how a hospitality giant, worked with the AWS Consultants at Flux7 to build automated compliance into its AWS PCI-related systems.

As part of a larger IT 2.0 initiative, the customer sought to lead with a cloud-first approach which results in infrastructure moving to the cloud that supports systems subject to PCI auditing. For the customer, Flux7 implemented AWS security best practices to ensure the infrastructure it deployed is PCI compliant. Following Flux7’s security best practice of Security by Design, which builds security in as infrastructure is built, PCI compliance was easily obtained. Compliance is often a by-product of security best practices and this infrastructure build is a case-in-point. 

To reduce the scope of customer’s PCI audits, we separated PCI and non-PCI resources. This not only reduces the firm’s audit-related activities but also serves to limit PCI resource exposure, further securing the PCI environment. 

PCI Case Study Hotelier Automates AWS Security Best Practices

For those systems subject to audit, not all PCI requirements can be met via infrastructure; many are dependent upon the correct systems and configurations to ensure (and prove) compliance. To give you an idea of the AWS approach we took to achieve this goal, the following is a snapshot of specific PCI Compliance requirements and how Flux7 met them with the help of AWS tools and technologies.  

 

PCI Requirement AWS Tool / Flux7 Implementation
10 Track and monitor all access to network resources and cardholder data  AWS GuardDuty, AWS Config, VPC Flow Logs, AWS CloudTrail, Amazon CloudWatch
10.1 Implement audit trails to link all access to system components to each individual user.  Amazon CloudWatch logs aggregate AWS CloudTrail monitoring, ensuring that all the API calls in AWS and manual operations in the console are monitored.
10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.2 All actions taken by any individual with root or administrative privileges  AWS GuardDuty flags any unusual IPs and the CIS benchmark monitors use of the AWS root user. 
10.6 Review logs and security events for all system components to identify anomalies or suspicious activity  AWS GuardDuty analyzes VPC Flow Logs, CloudTrail, and DNS logs.
10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.  The customer’s runbook is updated with all the AWS security policies and operational procedures; security is implemented as code. 
11 Regularly test security systems and processes  AWS Inspector scans all servers. Teams test systems with Game Day scenarios. 
11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.  AWS Config event notifications; container-based immutable infrastructure which cannot be modified.

While Amazon offers a PCI Quick Start, the solution Flux7’s cloud automation consulting team implemented for the customer is much more feature-rich and includes advanced technologies that address PCI and AWS security architecture at a deeper level. Let’s dive into these technologies and how their sophisticated features help simultaneously achieve PCI Compliance and AWS security best practices.

 

CIS Benchmarks 

Best practices for the secure configuration of systems, CIS benchmarks are applied to both the customer’s PCI and non PCI environments. This benefits the customer by giving them a single set of rules to manage for all its accounts, rather than managing multiple options. It also ensures that all systems meet the highest security standards. And, with applications that are promoted from non-production, which is out of compliance scope, to PCI production and in compliance scope, it’s important to know if any code change will be out of compliance before it reaches the PCI production environment. 

Amazon GuardDuty

Amazon GuardDuty continuously monitors for malicious or unauthorized behavior to help protect AWS accounts and workloads. It monitors:  

  • Unusual API calls
  • Potentially unauthorized deployments 
  • Detects potentially compromised instances

Reconnaissance by attackers. 

Flux7 deployed a GuardDuty stack

Flux7 deployed a GuardDuty stack that monitors via a service-linked IAM role.

AWS Config

AWS Config helps ensure the configuration of AWS resources is in a known-compliant state.  Through AWS Config monitoring, we can create Config Rules which can be set up to meet — and ensure continuous compliance to — regulatory standards. To further expound on that, a CloudWatch Event Rule has been put in place to monitor for any Event changes, which can be published to an SNS Topic. What this essentially translates to is the ability to catch Config Event messages, reformat them, and push them out as a notification. With AWS Config, Flux7 has deployed CIS profile Level 2 Rules which regularly audit VPCs to ensure Flow Logs are enabled. If even a single VPC is not enabled with the Flow Log, the rule is considered to be in non-compliance. 

AWS Config Event Notifications

To monitor environment configurations, AWS Config rules have been put in place; every rule has a set of criteria that deem whether an AWS resource is compliant or non-compliant.   For this use case, Flux7 has associated a unique SNS Topic to that target, which is setup to invoke Slack notifications using a Lambda function. We set Event notifications for components necessary to maintain a continuous state of PCI compliance, such as AWS security groups compliance, EC2 instances compliance, AMI IDs, AWS Access Key Rotation, etc.  

AWS Patch Manager 

Flux7 developed a custom AWS Patch Manager solution that automatically patches OpenShift EC2 instances per the Patch baseline set by the customer’s team. A patch baseline is an object in the patch manager which flexibly helps control the deployment of patches; when hundreds of instances are patched automatically, the customer uses the compliance dashboard for visibility into all the managed instances which have been patched by the patch manager. This ensures that its systems are updated to reflect fixes to known issues and/or vulnerabilities, keeping the customer as secure as possible. 

Research by the Ponemon Institute finds that of companies who had a breach last year, 57%  said that they were breached due to a vulnerability for which a patch was available but had not yet been applied in their environment. 

AWS Inspector

An automated security assessment service, Amazon Inspector helps improve the security and compliance of applications deployed on AWS. When deployed, a YAML file (which is a CloudFormation template customized by Flux7) sets up a process wherein golden AMIs are assessed weekly by AWS Inspector. Specifically: 

Inspector scans all the Parameter Store Golden AMIs weekly.

 

Inspector sends the scan findings via email to the UNIX team.

 

For continuous assessment, any new Golden AMI published by the pipeline from a release git tag is added to the AMI metadata — from here it is picked up by Lambda.

Read more about it on the Flux7 Blog: Golden AMIs help drive DevOps automation agility and stability

 

Data at Rest Encryption

To protect data when not in transit, all storage medium is encrypted. This includes S3 buckets, EFS, EBS volumes and snapshots; S3 and CloudWatch logs have retention and archival policies, too. An active config rule checks for unencrypted volumes and sends a notification if there is anything non-compliant in AWS. 

Misconfigured S3 buckets alone have been a major source of credit card skimming. According to RiskIQ data, just one group of bad actors has compromised S3 buckets at more than 17,000 domains.

Root & Secondary Volume Encryption

In order to achieve PCI compliance, we encrypted instance root volumes. By default, the root volume of AMI product instances created from the community or the AWS marketplace is not encrypted. 

Encryption in Transit

Encryption in transit is important as it further reduces the risk of unauthorized access or exposure. For encryption in transit, we use AWS Certificate Manager (ACM) which helps create and manage SSL/TLS certificates for AWS based websites and applications. 

Automated Log Retention Compliance Solution

The Log Retention compliance solution is deployed through a Lambda Function in the Shared Services account. It is executed daily and sets the retention period for all the log groups in all PCI accounts. This sets the log retention for all accounts deployed in the customer’s infrastructure. 

Jenkins Jobs Delivery Pipelines

Jenkins Pipelines ensure that infrastructure is deployed to the correct account: infrastructure subject to PCI compliance deploys to PCI accounts and infrastructure not subject to PCI requirements deploys to non-PCI accounts. Jenkins pipelines subject to PCI are not able to listen to changes in non-PCI branches and vice-versa.

To enable an infrastructure that is PCI Compliant, Flux7 created several Jenkins jobs. These multi-pipeline jobs cater to complex and continuous delivery requirements. The customer now has Jenkins pipelines that deploy the CloudFormation template (see AWS Inspector above for additional details) to: audit the AWS components of accounts, security accounts, shared-services accounts, and application accounts. 

Specifically, the PCI IAM pipeline deploys the AWS CloudFormation template which defines all IAM roles and access policies for all AWS accounts at the customer’s end, including those where the customer needs controlled access. The purpose of the Jenkins pipeline is to centralize IAM role/policy management and deployment. Said another way, the pci-iam-access-pipeline deploys to the PCI  Jenkins instance where it deploys to all PCI-related accounts. Conversely, the Jenkins pipeline can deploy IAM roles and policies to all accounts not subject to PCI. (You can read the full Tutorial on how to use IAM roles as Infrastructure as Code for secured access control in our new Tech Tutorials.)

Using the AWS security best practices and AWS tools mentioned in this article, the process of deploying and maintaining PCI Compliant infrastructure is fully automated whilst providing best practice monitoring, encryption, and overall security. While using different AWS tools to secure the infrastructure is a start, architecting them in an automated way and having feedback loops/notifications gives a deeper view of the infrastructure. To learn more how AWS services can help ensure your infrastructure stays secure with monitoring, up-to-date configurations and patch management, reach out to us today for a free quote.  

Technology is always changing. Stay in the loop with the Flux7 Blog

Written by Flux7 Labs

Flux7 is the only Sherpa on the DevOps journey that assesses, designs, and teaches while implementing a holistic solution for its enterprise customers, thus giving its clients the skills needed to manage and expand on the technology moving forward. Not a reseller or an MSP, Flux7 recommendations are 100% focused on customer requirements and creating the most efficient infrastructure possible that automates operations, streamlines and enhances development, and supports specific business goals.

Subscribe Here!