6.1 Describe prevention, detection and remediation workflow

Whether it is in or out of the cloud, most IT compliance usually comes in the form of a multitude of checklists – like the one you see below. It might be a spreadsheet, website, or other "digital" tool but, in the end, it is still checklists that software teams must comply with by filling out forms and then – ideally – fixing the discovered issues.

In many cases, in order to maintain adherence to internal and external compliance requirements, teams distribute these types of checklists to hundreds of teams and/or conduct audits around release events or randomly in order to ensure compliance. While this does not scale for any organization, without automation, it is particularly difficult to scale a model like this in the cloud where you can provision thousands of resources at the click of a button.

To many, so much of this seems more of a burden in order to satisfy compliance requirements (a form of "risk management theater") rather than something that truly helps reduce organizational and system risks that protect their end users. It does not have to be this way.

Architecture and Implementation

In the figure below, you see the architecture for launching a deployment pipeline that gets source assets from CodeCommit, builds with CodeBuild, and deploys a Lambda function to AWS.

The components of this solution are described in more detail below:

• Amazon SNS – Provisions a Simple Notification Service (SNS) Topic using the AWS::SNS::Topic resource. The SNS topic is used by the CodeCommit repository for notifications.
• Amazon S3 – There are several buckets defined in the template using the AWS::S3::Bucket resource. One bucket to store the AWS Config configuration items, another to store Lambda source artifacts, and another bucket to store the CodePipeline artifacts. There’s also an AWS::S3::BucketPolicy resource to define Config artifacts.
• AWS CloudFormation – All of the resource provisioning of this solution is described in CloudFormation, which is a declarative code language that can be written in JSON or YAML. In addition, CloudFormation is used as a deploy action in CodePipeline to deploy a Lambda function using the AWS Serverless Application Model (SAM).
• AWS CodeBuild – Creates a CodeBuild project using the AWS::CodeBuild::Project resource. CodeBuild is used to run commands that builds the Lambda function using SAM.
• AWS CodeCommit – Creates a CodeCommit Git repository using the AWS::CodeCommit::Repository resource. The contents for the repository are initialized using a zip file stored in S3.
• AWS CodePipeline – Creates CodePipeline's stages and actions in the CloudFormation template, which includes using CodeCommit as a source action, CodeBuild as a build action, and CloudFormation for a deploy action (For more information, see CodePipeline concepts).
• AWS Config – Creates the AWS::Config::ConfigurationRecorder, AWS::Config::DeliveryChannel, and AWS::Config::ConfigRule resources. The Configuration Recorder turns on AWS Config so that it records changes for all available AWS resources. The delivery channel is configured to identify the S3 bucket and SNS Topic to record configuration items and the Config Rule defines which resources will be monitored for compliance to the rules that are important to your organization and/or team.
• AWS IAM – An Identity and Access Management (IAM) Role is provisioned using the AWS::IAM::Role resource which defines the resources that the pipeline and others resources can access.

The figure below illustrates a workflow for detecting and remediating when S3 buckets allow public writes.

Here are the high-level steps in the workflow:

1. Step 1 – An engineer creates AWS resources within an automated provisioning tool like AWS CloudFormation. They commit their changes to a Git source code repository.
2. Step 2 – An AWS CodePipeline pipeline (which is automated through a bootstrapping process in CloudFormation as well) starts and runs preventive checks against all CloudFormation templates in the Git repository using the open source cfn_nag framework which notifies engineers about any security vulnerabilities. Most notably, cfn_nag provides rules for detecting whether encryption has been defined as part of provisioning certain AWS resources.
3. Step 3 – CodePipeline calls CloudFormation to configure the AWS resources within the AWS account.
4. Step 4 – AWS Config Rules monitor changes to AWS services. Running one of the AWS Managed Config Rules, it detects changes and flags a resource as noncompliant because the S3 Bucket allows public writes to the bucket.
5. Step 5 – CloudWatch Events gets triggered once the Config Rule is run and runs a Lambda function.
6. Step 6 – The Lambda function automatically removes the S3 bucket policy from S3 buckets that allow public writes.

This scenario provides an automated incident response workflow for data protection across an AWS account. Similar solutions can be deployed across multiple AWS accounts using a combination of services such as Amazon GuardDuty, Amazon Macie, Amazon Inspector, AWS CloudFormation StackSets, AWS Organizations, and so on.