AWS Cloud Operations Blog

DevSecOps for auto healing PCI DSS 3.2.1 violations in AWS using custom AWS Config conformance packs, AWS Systems Manager and AWS CodePipeline

If you migrate your workloads to the cloud to modernize your applications or secure infrastructure and operations, you’ll find these migrations are increasingly performed with a DevOps methodology that incorporates continuous development, integration, and testing. It is always a best practice to incorporate security as code in your DevOps workflows to uncover security issues when you start application development and to provide continuous security throughout the development and release process.

Compliance with regulatory frameworks is a security challenge that is often a multi-step process that involves reference to standards and regulatory requirements, individual policy definitions, remediation workflows, and exception procedures. Some remediation steps might require extensive hands-on experience with AWS. This activity is manual and error-prone and it results in a high mean time to remediation (MTTR), which increases risk and operational costs.

AWS Config conformance packs provide a general-purpose compliance framework designed to help you create security, operational or cost-optimization governance checks using AWS Config managed or custom rules and remediation actions. AWS Config now provides an Operational Best Practices for PCI DSS 3.2.1 conformance pack that provides managed rules that are specifically mapped to the Payment Card Data Security Standard (PCI DSS) 3.2.1 standard. These controls detect when your deployed accounts and resources deviate from AWS security best practices required for PCI compliance for your AWS workload.

In this post, I implement a solution that augments the AWS Config Conformance Pack for Operational Best Practices for PCI DSS 3.2.1 with two distinct features:

  • Auto healing for PCI compliance
    • While AWS provides remediations for a few PCI related AWS Config managed rules, we need to implement custom remediations for several of the AWS Config managed rules that relate to PCI compliance. In this blog post I implement custom remediation actions via AWS Systems Manager automation documents for PCI related AWS Config rules in the form of custom conformance packs. This helps you to set up a continuous compliance, self-healing environment for PCI controls in AWS that can also be extended to accommodate your business requirements. Here is a coverage spreadsheet that maps the auto healing and remediation coverage of the solution outlined here with PCI controls in AWS.
  • PCI compliance as code
    • A DevSecOps CI/CD pipeline for PCI compliance helps you to incorporate automated and continuous remediations on detected PCI violations directly in your CI/CD pipelines for DevOps automation. I implement this by integrating custom conformance packs with AWS CodePipeline provided through AWS CloudFormation as infrastructure as code.

Solution architecture

The first step in compliance is visibility and monitoring, which are provided through recording and detection capabilities to ensure that you know the compliance state of your resources. The next step is taking action based on the results you detect. AWS Config conformance packs allow you to define and automate new custom rules for detection and new custom remediation actions. This makes it possible for you to tailor compliance to specific workloads and business requirements.

AWS Config provides a framework for remediation actions. In the conformance pack, remediation actions are defined using the AWS::Config::RemediationConfiguration resource type that links an AWS Config rule with a target. The target is an AWS Systems Manager document with logic to remediate the noncompliant resource. The coverage folder in the GitHub repository for my solution provides a coverage spreadsheet that maps the auto healing and remediation coverage of the solution implemented here with the PCI controls in AWS.

To provide DevSecOps functionality that incorporates security as code into your DevOps workflows, I have used AWS CodePipeline, AWS CloudFormation, AWS Config conformance packs, and AWS Systems Manager to create a CI/CD pipeline. AWS CodePipeline automates the build, test, and deployment phases of your release process every time there’s a code change based on the release model you define.  Figure 1 shows the DevSecOps request flow.

Upon check-in, CodeCommit stage downloads code. CodeBuild stage copies code to staging bucket and uses an AWS CLI command to build and deploy conformance packs.

Figure 1: DevSecOps request flow

  1. There are two stages in AWS CodePipeline: AWS CodeCommit and AWS CodeBuild. The  CodeCommit stage is triggered whenever there is a check-in to the CodeCommit repository. It downloads the updated code (the custom AWS Config conformance pack CloudFormation templates) into the Amazon S3 artifact bucket of AWS CodePipeline.
  2. The AWS CodeBuild stage copies the code (custom AWS Config conformance pack CloudFormation templates) to an S3 staging bucket.
  3. The AWS CodeBuild stage uses the AWS Command Line Interface (AWS CLI) put-conformance-pack command to build and deploy the conformance packs for PCI auto healing in your AWS environment.

Solution components

The entire solution with a detailed README is available here. It consists of the following components:

  • aws-pci-confpack-codepipeline.yml
    • Triggers a CI/CD pipeline whenever there is an update to the source AWS CloudFormation templates in your local Git repository. These templates incorporate the code for the custom AWS Config conformance packs.
    • Provisions an AWS CodePipeline automation with AWS CodeCommit and AWS CodeBuild stages for the build and deployment of the conformance packs.
  • aws-pci-confpack-ssmautomation-v1.yml
    • Provisions custom AWS Systems Manager Automation documents for PCI remediation. These documents are used to provide automated remediations in the provisioned AWS Config rule using the AWS:Config:RemediationConfiguration CloudFormation construct in the conformance pack.
    • Provisions prerequisites for the conformance pack deployment, such as the AWS Systems Manager Automation role, S3 buckets for logging and replication, CloudWatch logs, and a CloudWatch role for remediations related to AWS CloudTrail.
  • Custom AWS Config conformance packs:

For more information, see the README on GitHub.

Walkthrough

This section describes the prerequisites and steps required to set up, deploy, and provide updates through the DevSecOps pipeline.

Prerequisites

  1. Follow the steps in the prerequisites section of the Introducing AWS Config Conformance Packs blog post to deploy and build conformance packs.
  2. Create an AWS CodeCommit repository in your AWS account and integrate it with your local Git repository. For more information, see Setup steps for SSH connections to AWS CodeCommit repositories  in the AWS CodeCommit user guide.
  3. My local Git repository contains the custom AWS Config Conformance Pack templates in a folder structure as outlined below. You can change the names of these folders to whatever you decide. However in that case please remember to use the same names for the folders in the next steps (4 and 5) in the prerequisites section.
  4. Create an S3 staging bucket using this naming convention: s3-pciautohealconfpack-<accountid>-<region>. Create the same three folders (ec2-lambda, cloudtrail-kms-codebuild and redshift-rds-iam) from Step 3 above in your S3 bucket. The folder names here need to match the folder names in your local Git repository. As mentioned in Step 3 you can create these folders with any names as long as those are the same names used while creating your local Git repository there.
  5. In the buildspec.yml file:
    • Replace <accountid> and <region> with your AWS Account ID and Region throughout the buildspec.yml file.
    • If you have used different folder names in Steps 3 and 4 above, then please edit the buildspec.yml to ensure that the AWS Conformance Pack CLI commands use the same folder names. The buildspec.yml uses the AWS CLI put-conformance-pack command to deploy the AWS Config conformance pack.
      • For example, replace the folder name (ec2-lambda) in the command below here with the folder name that contains your aws-pci-conformancepack-v1-1.yml AWS Config conformance pack template in your staging S3 bucket: aws configservice put-conformance-pack --conformance-pack-name="confpack-pci-1" --template-s3-uri="s3://s3-pciautohealconfpack-<accountid>-<region>/ec2-lambda/aws-pci-conformancepack-v1-1.yml" --delivery-s3-bucket="config-bucket-<accountid>"
  6. In each of the custom conformance pack templates, look for the AutomationAssumeRole parameter within the properties section of  AWS::Config::RemediationConfiguration. Replace the <accountid> and <region> in the parameter value with the AWS Account ID and Region in which you are launching this solution. The parameter value looks like arn:aws:iam::<accountid>:role/automationassumerole-<region>  in each of the following templates:

Initial setup

The solution automates the initial setup and deployment in two steps:

Step 1: Setup custom AWS Systems Manager Automation documents and prerequisites related to PCI remediation:

When you run the aws-pci-confpack-ssmautomation-v1.yml template, it provisions all the custom AWS Systems Manager automation documents related to PCI remediation. For example for the “PCI.AutoScaling.1 Auto Scaling groups associated with a load balancer should use health checks” compliance rule, the template provisions the Custom-AutoScalingELBHealthCheck Automation document. To view all the AWS Systems Manager automation remediation documents in the AWS Systems Manager console, from the left navigation pane, choose Documents, and then choose the Owned by me tab.

Step 2: Set up AWS CodePipeline-based DevSecOps automation:

Here’s what happens in this step when you launch the aws-pci-confpack-codepipeline.yml template:

  • The template provisions AWS CodePipeline in your AWS account.
  • The AWS CodeCommit stage of the pipeline downloads the code from the CodeCommit repository and into the S3 artifact repository of AWS CodePipeline.
  • The AWS CodeBuild stage of the pipeline executes the commands in the buildspec.yml file as follows:
    • Copies the custom AWS Config conformance pack templates into their respective folders of our staging Amazon S3 bucket (s3-pciautohealconfpack-<accountid>-<region)
    • Uses the AWS Config conformance pack CLI command to deploy each of the custom AWS Config conformance packs for auto healing in your AWS environment.

Performing updates

Updates are performed directly from the local Git repository. The AWS administrator checks in new or updated custom AWS Config conformance pack source templates. The changes are committed and pushed to a remote CodeCommit repository in a bash terminal using standard git commands. CodePipeline recognizes the commit and uses the AWS Config conformance pack CLI command (aws configservice put-conformance-pack) to deploy the new or updated conformance pack.

Conclusion

In this post, I have implemented a DevSecOps pipeline that adds auto healing to the AWS Config Conformance Pack for Operational Best Practices for PCI DSS 3.2.1 by providing automated remediations using custom AWS Systems Manager automation documents. These custom AWS Systems Manager automation documents are themselves provisioned with a 1-click deployment using AWS CloudFormation.  I hope that you find this solution helpful in your cloud transformation journey. I look forward to your feedback.

About the Author

 

Kanishk has been leading AWS cloud transformation, solution architecture and delivery teams for customers for several years. Currently at AWS, Kanishk specializes in all areas that relate to Devops, management and governance, security and compliance and migrations and modernizations in AWS.