Hotelier Automates AWS Security Best Practices

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 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, I’ll share the story of how a hospitality giant, worked with our AWS Consultants 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, we implemented AWS security best practices to ensure the infrastructure it deployed is PCI compliant. Following the 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.

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 they were met with the help of AWS tools and technologies.

While Amazon offers a PCI Quick Start, the solution we 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.
  

NTT DATA 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, we 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, we 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
We 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.

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 NTT DATA) 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.

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 and secondary volume encryption
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, we 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.

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.

*This was originally written by Flux7 Inc., which has become Flux7, an NTT DATA Services Company as of December 30, 2019