Product logo
DocsBlogPricing

Control types for @turbot/aws-pciv3-2-1

AWS > PCI v3.2.1

The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Below is a high-level overview of the 12 PCI DSS requirements.

PCI Data Security Standard – High Level Overview

Build and Maintain a Secure Network and Systems

  1. Install and maintain a firewall configuration to protect cardholder data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

  1. Protect stored cardholder data
  2. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

  1. Protect all systems against malware and regularly update anti-virus software or programs
  2. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

  1. Restrict access to cardholder data by business need to know
  2. Identify and authenticate access to system components
  3. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

  1. Track and monitor all access to network resources and cardholder data
  2. Regularly test security systems and processes

Maintain an Information Security Policy

  1. Maintain a policy that addresses information security for all personnel.

To obtain the latest version of the official guide, please visit https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/pci
Parent
Category

AWS > PCI v3.2.1 > Auto Scaling

This section contains recommendations for configuring Auto Scaling resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/autoScaling
Parent
Category

AWS > PCI v3.2.1 > Auto Scaling > 1 Auto Scaling groups associated with a load balancer should use health checks

This control checks whether your Auto Scaling groups that are associated with a load balancer are using Elastic Load Balancing health checks.

PCI DSS does not require load balancing or highly available configurations. However, this check aligns with AWS best practices.

Remediation

To enable Elastic Load Balancing health checks

  1. Open the Amazon EC2 console
  2. On the navigation pane, under Auto Scaling, choose Auto Scaling Groups
  3. To select the group from the list, choose the right box
  4. Choose Edit
  5. For Health Check Type, choose ELB
  6. For Health Check Grace Period, enter 300
  7. Choose Save

PCI requirement(s): 2.2

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/autoScalingGroupWithLbUseHealthCheck
Parent
Category
Targets

AWS > PCI v3.2.1 > CloudTrail

This section contains recommendations for configuring CloudTrail resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/cloudTrail
Parent
Category

AWS > PCI v3.2.1 > CloudTrail > 1 CloudTrail logs should be encrypted at rest using AWS KMS CMKs

This control checks whether AWS CloudTrail is configured to use the server-side encryption (SSE) AWS KMS customer master key (CMK) encryption.

If you are only using the default encryption option, you can choose to disable this check.

Remediation

To enable encryption for CloudTrail logs

  1. Open the CloudTrail console at CloudTrail.
  2. Choose Trails.
  3. Choose the trail to update.
  4. Under General details, choose Edit.
  5. For Log file SSE-KMS encryption, select Enabled.
  6. Under AWS KMS customer managed CMK, do one of the following:
    • To create a key, choose New. Then in AWS KMS alias, enter an alias for the key. The key is created in the same Region as the S3 bucket.
    • To use an existing key, choose Existing and then from AWS KMS alias, select the key.
    • The AWS KMS key and S3 bucket must be in the same Region.
  7. Choose Save changes.

PCI requirement(s): 3.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/cloudTrailTrailLogsEncryptedWithKmsCmk
Parent
Category
Targets

AWS > PCI v3.2.1 > CloudTrail > 2 CloudTrail should be enabled

This control checks whether CloudTrail is enabled in your AWS account.

However, some AWS services do not enable logging of all APIs and events. You should implement any additional audit trails other than CloudTrail and review the documentation for each service in CloudTrail Supported Services and Integrations.

Remediation

To create a new trail in CloudTrail

  1. Sign in to the AWS Management Console using the IAM user you configured for CloudTrail administration.
  2. Open the CloudTrail console at CloudTrail.
  3. In the Region selector, choose the AWS Region where you want your trail to be created. This is the Home Region for the trail.
  4. The Home Region is the only AWS Region where you can view and update the trail after it is created, even if the trail logs events in all AWS Regions.
  5. In the navigation pane, choose Trails.
  6. On the Trails page, choose Get Started Now. If you do not see that option, choose Create Trail.
  7. In Trail name, give your trail a name, such as My-Management-Events-Trail.
  8. As a best practice, use a name that quickly identifies the purpose of the trail. In this case, you're creating a trail that logs management events.
  9. In Management Events, make sure Read/Write events is set to All.
  10. In Data Events, do not make any changes. This trail will not log any data events.
  11. Create a new S3 bucket for the logs:
    1. In Storage Location, in Create a new S3 bucket, choose Yes.
    2. In S3 bucket, give your bucket a name, such as my-bucket-for-storing-cloudtrail-logs.
    3. The name of your S3 bucket must be globally unique. For more information about S3 bucket naming requirements, see the AWS CloudTrail User Guide.
  12. Under Advanced, choose Yes for both Encrypt log files with SSE-KMS and Enable log file validation.
  13. Choose Create.

PCI requirement(s): 10.1, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 10.2.7, 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/cloudTrailEnabledAllRegions
Parent
Category
Targets

AWS > PCI v3.2.1 > CloudTrail > 3 CloudTrail log file validation should be enabled

This control checks whether CloudTrail log file validation is enabled.

It does not check when configurations are altered.

To monitor and alert on log file changes, you can use Amazon EventBridge or CloudWatch metric filters.

Remediation

To enable CloudTrail log file validation

  1. Open the CloudTrail console at CloudTrail.
  2. In the navigation pane, choose Trails.
  3. In the Name column, choose the Trail Name to edit.
  4. Under General details, choose Edit.
  5. Under Additional settings, for Log file validation,, select Enabled.
  6. Choose Save.

PCI requirement(s): 10.5.2, 10.5.5

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/cloudTrailTrailValidationEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > CloudTrail > 4 CloudTrail trails should be integrated with CloudWatch Logs

This control checks whether CloudTrail trails are configured to send logs to CloudWatch Logs.

It does not check for user permissions to alter logs or log groups. You should create specific CloudWatch rules to alert when CloudTrail logs are altered.

This control also does not check for any additional audit log sources other than CloudTrail being sent to a CloudWatch Logs group.

Remediation

To enable CloudTrail log file validation

  1. Open the CloudTrail console at CloudTrail.
  2. In the navigation pane, choose Trails.
  3. Choose a trail that there is no value for in the CloudWatch Logs Log group column.
  4. Scroll down to the CloudWatch Logs section and then choose Edit.
  5. For Log group field, do one of the following:
    • To use the default log group, keep the name as is.
    • To use an existing log group, choose Existing and then enter the name of the log group to use.
    • To create a new log group, choose New and then enter a name for the log group to create.
  6. Choose Continue.
  7. For IAM role, do one of the following:
    • To use an existing role, choose Existing and then choose the role from the drop-down list.
    • To create a new role, choose New and then enter a name for the role to create.
    • The new role is assigned a policy that grants the necessary permissions. To view the permissions granted to the role, expand the Policy document.
  8. Choose Save changes.

PCI requirement(s): 10.5.3

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/cloudTrailTrailIntegratedWithLogs
Parent
Category
Targets

AWS > PCI v3.2.1 > CloudWatch

This section contains recommendations for configuring CloudWatch resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/cloudWatch
Parent
Category

AWS > PCI v3.2.1 > CloudWatch > 1 A log metric filter and alarm should exist for usage of the 'root' user

This control checks for the CloudWatch metric filters using the following pattern:

{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

It checks the following:

  • The log group name is configured for use with active multi-Region CloudTrail.
  • There is at least one Event Selector for a Trail with IncludeManagementEvents set to true and ReadWriteType set to All.
  • There is at least one active subscriber to an Amazon SNS topic associated with the alarm.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

  1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
  2. Create an Amazon SNS topic that receives all CIS alarms.
  3. Create at least one subscriber to the topic.
  4. For more information about creating Amazon SNS topics, see the Amazon Simple Notification Service Developer Guide.
  5. Set up an active CloudTrail trail that applies to all Regions.
  6. To do this, follow the remediation steps in CIS v1.3.0 3.1 Ensure CloudTrail is enabled in all Regions.
  7. Make a note of the associated log group name.

To create a metric filter and alarm

  1. Open the CloudWatch console.
  2. Choose Logs, then choose Log groups.
  3. Choose the log group where CloudTrail is logging.
  4. On the log group details page, choose Metric filters.
  5. Choose Create metric filter.
  6. Copy the following pattern and then paste it into Filter pattern.
    {$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
  7. Enter the name of the new filter. For example, RootAccountUsage.
  8. Confirm that the value for Metric namespace is LogMetrics.
  9. This ensures that all CIS Benchmark metrics are grouped together.
  10. In Metric name, enter the name of the metric.
  11. In Metric value, enter 1, and then choose Next.
  12. Choose Create metric filter.
  13. Next, set up the notification. Select the select the metric filter you just created, then choose Create alarm.
  14. Enter the threshold for the alarm (for example, 1), then choose Next.
  15. Under Select an SNS topic, for Send notification to, choose an email list, then choose Next.
  16. Enter a Name and Description for the alarm, such as RootAccountUsageAlarm, then choose Next.
  17. Choose Create Alarm.

PCI requirement(s): 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/logMetricFilterRootLogin
Parent
Category
Targets

AWS > PCI v3.2.1 > CodeBuild

This section contains recommendations for configuring CodeBuild resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/codeBuild
Parent
Category

AWS > PCI v3.2.1 > CodeBuild > 1 CodeBuild GitHub or Bitbucket source repository URLs should use OAuth

This control checks whether the GitHub or Bitbucket source repository URL contains either personal access tokens or a user name and password.

You can use CodeBuild in your PCI DSS environment to compile your source code, run unit tests, or produce artifacts that are ready to deploy. If you do, your authentication credentials should never be stored or transmitted in clear text or appear in the repository URL.

You should use OAuth instead of personal access tokens or a user name and password to grant authorization for accessing GitHub or Bitbucket repositories. This is a method to use strong cryptography to render authentication credentials unreadable.

Remediation

To remove basic authentication / (GitHub) Personal Access Token from CodeBuild Project Source

  1. Open the CodeBuild console
  2. Select your Build project that contains personal access tokens or a user name and password.
  3. From Edit, choose Source.
  4. Choose Disconnect from GitHub / Bitbucket.
  5. Choose Connect using OAuth and then choose Connect to GitHub / Bitbucket.
  6. In the message displayed by your source provider, authorize as appropriate.
  7. Reconfigure your Repository URL and additional configuration settings, as needed.
  8. Choose Update source.

PCI requirement(s): 8.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/codeBuildProjectSourceRepoOauthConfigured
Parent
Category
Targets

AWS > PCI v3.2.1 > CodeBuild > 2 CodeBuild project environment variables should not contain clear text credentials

This control checks whether the project contains environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

You can use CodeBuild in your PCI DSS environment to compile your source code, runs unit tests, or produce artifacts that are ready to deploy. If you do, never store the authentication credentials AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in clear text.

Using environmental variables to store credentials in your CodeBuild project may violate the requirement to use strong cryptography to render authentication credentials unreadable.

Remediation

To enable Elastic Load Balancing health checks

  1. Open the CodeBuild console
  2. Expand Build, choose Build project, and then choose the build project that contains plaintext credentials.
  3. From Edit, choose Environment.
  4. Expand Additional configuration and then scroll to Environment variables.
  5. Choose Remove next to the environment variable.
  6. Choose Update environment.

To store sensitive values in the Amazon EC2 Systems Manager Parameter Store and then retrieve them from your build spec

  1. Open the CodeBuild console
  2. Expand Build, choose Build project, and then choose your build project that contains plaintext credentials.
  3. From Edit, choose Environment.
  4. Expand Additional configuration and then scroll to Environment variables.
  5. In AWS Systems Manager, create a Systems Manager parameter that contains your sensitive data. For instructions on how to do this, refer to the tutorial in the AWS Systems Manager User Guide.
  6. After you create the parameter, copy the parameter name.
  7. Back in the CodeBuild console, choose Create environmental variable.
  8. For name, enter the name of your variable as it appears in your build spec.
  9. For value, paste in the name of your parameter.
  10. From type, choose Parameter.
  11. Choose Remove next to your noncompliant environmental variable that contains plaintext credentials.
  12. Choose Update environment.

PCI requirement(s): 8.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/codeBuildProjectPlaintextEnvVariablesNoSensitiveAwsValues
Parent
Category
Targets

AWS > PCI v3.2.1 > Config

This section contains recommendations for configuring AWS Config.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/config
Parent
Category

AWS > PCI v3.2.1 > Config > 1 AWS Config should be enabled

AWS Config rule: None. To run this check, Security Hub runs through audit steps prescribed for it in Securing Amazon Web Services. No AWS Config managed rules are created in your AWS environment for this check.

This control checks whether AWS Config is enabled in the account for the local Region and is recording all resources.

It does not check for change detection for all critical system files and content files, as AWS Config supports only a subset of resource types.

The AWS Config service performs configuration management of supported AWS resources in your account and delivers log files to you. The recorded information includes the configuration item (AWS resource), relationships between configuration items, and any configuration changes between resources.

Remediation

To configure AWS Config settings

  1. Open the AWS Config console.
  2. Choose the Region to configure AWS Config in.
  3. If you have not used AWS Config before, choose Get started.
  4. On the Settings page, do the following:
    1. Under Resource types to record, choose Record all resources supported in this region and Include global resources (e.g., AWS IAM resources).
    2. Under Amazon S3 bucket, either specify the bucket to use or create a bucket and optionally include a prefix.
    3. Under Amazon SNS topic, either select an Amazon SNS topic from your account or create one. For more information about Amazon SNS, see the Amazon Simple Notification Service Getting Started Guide.
    4. Under AWS Config role, either choose Create AWS Config service-linked role or choose Choose a role from your account and then choose the role to use.
  5. Choose Next.
  6. On the AWS Config rules page, choose Skip.
  7. Choose Confirm.

For more information about using AWS Config from the AWS CLI, see the AWS Config Developer Guide.

You can also use an AWS CloudFormation template to automate this process. For more information, see the AWS CloudFormation User Guide.

PCI requirement(s): 10.5.2, 11.5

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/configEnabledAllRegions
Parent
Category
Targets

AWS > PCI v3.2.1 > DMS

This section contains recommendations for configuring AWS DMS resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/dms
Parent
Category

AWS > PCI v3.2.1 > DMS > 1 AWS Database Migration Service replication instances should not be public

This control checks whether AWS DMS replication instances are public. To do this, it examines the value of the PubliclyAccessible field.

A private replication instance has a private IP address that you cannot access outside of the replication network. A replication instance should have a private IP address when the source and target databases are in the same network, and the network is connected to the replication instance's VPC using a VPN, AWS Direct Connect, or VPC peering.

You should also ensure that access to your AWS DMS instance configuration is limited to only authorized users. To do this, restrict users’ IAM permissions to modify AWS DMS settings and resources.

Remediation

Note that you cannot change the public access setting once a replication instance is created. It must be deleted and recreated.

To configure the AWS DMS replication instances setting to be not publicly accessible

  1. Open the AWS Database Migration Service console.
  2. In the left navigation pane, under Resource management, navigate to Replication instances.
  3. To delete the public instance, select the check box for the instance, choose Actions, then choose delete.
  4. Choose Create replication instance. Provide the configuration details.
  5. To disable public access, make sure that Publicly accessible is not selected.
  6. Choose Create.

For more information, see the section on Creating a replication instance in the AWS Database Migration Service User Guide.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/dmsReplicationInstanceNotPubliclyAccessible
Parent
Category
Targets

AWS > PCI v3.2.1 > EC2

This section contains recommendations for configuring EC2 resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/ec2
Parent
Category

AWS > PCI v3.2.1 > EC2 > 1 Amazon EBS snapshots should not be publicly restorable

This control checks whether Amazon Elastic Block Store snapshots are not publicly restorable by everyone, which makes them public. Amazon EBS snapshots should not be publicly restorable by everyone unless you explicitly allow it, to avoid accidental exposure of your company’s sensitive data.

You should also ensure that permission to change Amazon EBS configurations are restricted to authorized AWS accounts only. Learn more about managing Amazon EBS snapshot permissions in the Amazon EC2 User Guide for Linux Instances.

Remediation

  1. Open the Amazon EC2 console.
  2. In the navigation pane, under Elastic Block Store, choose Snapshots and then select your public snapshot.
  3. Choose Permissions tab from metadata view section, click Edit
  4. Choose Private in This snapshot is currently
  5. Choose Save

PCI requirement(s): 1.2.1, 1.3.1, 1.3.4, 1.3.4, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/ebsSnapshotNotPubliclyRestorable
Parent
Category
Targets

AWS > PCI v3.2.1 > EC2 > 2 VPC default security group should prohibit inbound and outbound traffic

This control checks that the default security group of a VPC does not allow inbound or outbound traffic.

It does not check for access restrictions for other security groups that are not default, and other VPC configurations.

Remediation

To remediate this issue, create new security groups and assign those security groups to your resources. To prevent the default security groups from being used, remove their inbound and outbound rules.

  1. Open the Amazon VPC console.
  2. In the navigation pane, choose Security groups. View the default security groups details to see the resources that are assigned to them.
  3. Select a default security group, and choose the Inbound rules tab. Choose Edit inbound rules. Then delete all of the inbound rules. Choose Save rules.
  4. Repeat the previous step for each default security group.
  5. Select a default security group and choose the Outbound rules tab. Choose Edit outbound rules. Then delete all of the outbound rules. Choose Save rules.
  6. Repeat the previous step for each default security group.

Create a set of least-privilege security groups for the resources. For details on how to create security groups, see Creating a security group in the Amazon VPC User Guide.

PCI requirement(s): 1.2.1, 1.3.4, 2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/vpcDefaultSecurityGroupRestrictsAllTraffic
Parent
Category
Targets

AWS > PCI v3.2.1 > EC2 > 3 Unused EC2 security groups should be removed

This control helps you maintain an accurate asset inventory of needed security groups in your cardholder data environment (CDE). It does so by checking that security groups are attached to Amazon EC2 instances or to an ENI. A failed finding indicates you may have unused Amazon EC2 security groups.

Unless there is a business need to retain them, you should remove unused resources to maintain an accurate inventory of system components.

Remediation

You must perform the following steps for each security group not attached to an ENI.

  1. Open the Amazon VPC console
  2. In the navigation pane, under Security, choose Security groups.
  3. Select the check box for the security group to delete.
  4. From Actions, choose Delete security group.
  5. Choose Delete.

PCI requirement(s): 2.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/vpcSecurityGroupAssociated
Parent
Category
Targets

AWS > PCI v3.2.1 > EC2 > 4 Unused EC2 EIPs should be removed

This control checks whether Elastic IP addresses that are allocated to a VPC are attached to Amazon EC2 instances or in-use elastic network interfaces (ENIs).

A failed finding indicates you may have unused Amazon EC2 EIPs.

This will help you maintain an accurate asset inventory of EIPs in your cardholder data environment (CDE). Unless there is a business need to retain them, you should remove unused resources to maintain an accurate inventory of system components.

Remediation

To remediate this issue, create new security groups and assign those security groups to your resources. To prevent the default security groups from being used, remove their inbound and outbound rules.

  1. Open the Amazon EC2 console.
  2. In the navigation pane, under Network & Security, choose Elastic IPs.
  3. Choose the Elastic IP address, choose Actions, and then choose Release Elastic IP address.
  4. When prompted, choose Release.

PCI requirement(s): 2.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/vpcEipAssociated
Parent
Category
Targets

AWS > PCI v3.2.1 > EC2 > 5 Security groups should not allow ingress from 0.0.0.0/0 to port 22

This control checks whether security groups in use disallow unrestricted incoming SSH traffic.

It does not evaluate outbound traffic.

Note that security groups are stateful. If you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out regardless of outbound rules.

Remediation

Perform the following steps for each security group associated with a VPC.

  1. Open the Amazon VPC console.
  2. In the navigation pane, under Security, choose Security groups.
  3. Select a security group.
  4. In the bottom section of the page, choose Inbound rules.
  5. Choose Edit inbound rules.
  6. Identify the rule that allows access through port 22 and then choose the X to remove it.
  7. Choose Save rules.

PCI requirement(s): 1.2.1, 1.3.1, 2.2.2

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/vpcSecurityGroupRemoteAdministration
Parent
Category
Targets

AWS > PCI v3.2.1 > EC2 > 6 VPC flow logging should be enabled in all VPCs

This control checks whether VPC flow logs are found and enabled for VPCs. The traffic type is set to REJECT.

With VPC Flow Logs, you can capture information about the IP address traffic to and from network interfaces in your VPC. After you create a flow log, you can use CloudWatch Logs to view and retrieve the log data.

Security Hub recommends that you enable flow logging for packet rejects for VPCs. Flow logs provide visibility into network traffic that traverses the VPC. They can detect anomalous traffic and provide insight into security workflows.

By default, the record includes values for the different components of the IP address flow, including the source, destination, and protocol. For more information and descriptions of the log fields, see VPC Flow Logs in the Amazon VPC User Guide.

Remediation

To enable VPC flow logging

  1. Open the Amazon VPC console.
  2. In the navigation pane, under Virtual Private Cloud, choose Your VPCs.
  3. Select a VPC to update.
  4. At the bottom of the page, choose Flow Logs.
  5. Choose Create flow log.
  6. For Filter, choose Reject.
  7. For Destination log group, choose the log group to use.
  8. If you chose CloudWatch Logs for your destination log group, for IAM role, choose the IAM role to use.
  9. Choose Create.

PCI requirement(s): 10.3.3, 10.3.4, 10.3.5, 10.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/vpcFlowLogsEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > ELBV2

This section contains recommendations for configuring Elastic Load Balancer resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/elbv2
Parent
Category

AWS > PCI v3.2.1 > ELBV2 > 1 Application Load Balancer should be configured to redirect all HTTP requests to HTTPS

This control checks whether HTTP to HTTPS redirection is configured on all HTTP listeners of Application Load Balancers. The control fails if any of the HTTP listeners of Application Load Balancers do not have HTTP to HTTPS redirection configured.

Before you start to use your Application Load Balancer, you must add one or more listeners. A listener is a process that uses the configured protocol and port to check for connection requests. Listeners support both the HTTP and HTTPS protocols. You can use an HTTPS listener to offload the work of encryption and decryption to your load balancer. To enforce encryption in transit, you should use redirect actions with Application Load Balancers to redirect client HTTP requests to an HTTPS request on port 443.

Remediation

To enable VPC flow logging

  1. Open the Amazon EC2 console.
  2. In the navigation pane, under Load Balancing, choose Load balancers.
  3. Choose an Application Load Balancer.
  4. Choose Listeners.
  5. Select the check box for an HTTP listener (port 80 TCP) and then choose Edit.
  6. If there is an existing rule, you must delete it. Otherwise, choose Add action and then choose Redirect to....
  7. Choose HTTPS and then enter 443.
  8. Choose the check mark in a circle symbol and then choose Update.

PCI requirement(s): 2.3, 4.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/elbApplicationLbRedirectHttpRequestToHttps
Parent
Category
Targets

AWS > PCI v3.2.1 > Elasticsearch

This section contains recommendations for configuring Elasticsearch resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/elasticsearch
Parent
Category

AWS > PCI v3.2.1 > Elasticsearch > 1 Amazon Elasticsearch Service domains should be in a VPC

This control checks whether Amazon Elasticsearch Service domains are in a VPC.

It does not evaluate the VPC subnet routing configuration to determine public reachability.

This AWS control also does not check whether the Amazon ES resource-based policy permits public access by other accounts or external entities. You should ensure that Amazon ES domains are not attached to public subnets. See Resource-based policies in the Amazon Elasticsearch Service Developer Guide.

Remediation

If you create a domain with a public endpoint, you cannot later place it within a VPC. Instead, you must create a new domain and migrate your data.

The reverse is also true. If you create a domain within a VPC, it cannot have a public endpoint. Instead, you must either create another domain or disable this control.

See the information on migrating from public access to VPC access in the Amazon Elasticsearch Service Developer Guide.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/esDomainInVpc
Parent
Category
Targets

AWS > PCI v3.2.1 > Elasticsearch > 2 Amazon Elasticsearch Service domains should have encryption at rest enabled

This control checks whether Amazon ES domains have encryption at rest configuration enabled.

Remediation

By default, domains do not encrypt data at rest, and you cannot configure existing domains to use the feature.

To enable the feature, you must create another domain and migrate your data. For information about creating domains, see the Amazon Elasticsearch Service Developer Guide.

Encryption of data at rest requires Amazon ES 5.1 or later. For more information about encrypting data at rest for Amazon ES, see the Amazon Elasticsearch Service Developer Guide.

PCI requirement(s): 3.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/esDomainEncryptionAtRestEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > GuardDuty

This section contains recommendations for configuring AWS GuardDuty resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/guardDuty
Parent
Category

AWS > PCI v3.2.1 > GuardDuty > 1 GuardDuty should be enabled

This control checks whether Amazon GuardDuty is enabled in your AWS account and Region.

While GuardDuty can be effective against attacks that an intrusion detection system would typically protect, it might not be a complete solution for every environment. This rule also does not check for the generation of alerts to personnel. For more information about GuardDuty, see the Amazon GuardDuty User Guide.

Remediation

To remediate this issue, you enable GuardDuty.

Refer here for more Getting started with GuardDuty.

PCI requirement(s): 11.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/guardDutyEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM

This section contains recommendations for configuring AWS IAM resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iam
Parent
Category

AWS > PCI v3.2.1 > IAM > 1 IAM root user access key should not exist

This control checks whether user access keys exist for the root user.

Remediation

To delete access keys

  1. Log in to your account using the root user credentials.
  2. Choose the account name near the top-right corner of the page and then choose My Security Credentials.
  3. In the pop-up warning, choose Continue to Security Credentials.
  4. Choose Access keys (access key ID and secret access key).
  5. To permanently delete the key, choose Delete and then choose Yes. You cannot recover deleted keys.
  6. If there is more than one root user access key, then repeat steps 4 and 5 for each key.

PCI requirement(s): 2.1, 2.2, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamRootUserNoAccessKeys
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 2 IAM users should not have IAM policies attached

This control checks that none of your IAM users have policies attached. IAM users must inherit permissions from IAM groups or roles.

It does not check whether least privileged policies are applied to IAM roles and groups.

Remediation

To resolve this issue, do the following:

  1. Create an IAM group
  2. Assign the policy to the group
  3. Add the users to the group

The policy is applied to each user in the group.

To create an IAM group

  1. Open the IAM console.
  2. Choose Groups and then choose Create New Group.
  3. Enter a name for the group to create and then choose Next Step.
  4. Select each policy to assign to the group and then choose Next Step.
  5. The policies that you choose should include any policies currently attached directly to a user account. The next step to resolve a failed check is to add users to a group and then assign the policies to that group.
  6. Each user in the group gets assigned the policies assigned to the group.
  7. Confirm the details on the Review page and then choose Create Group.

To add users to an IAM group

  1. Open the IAM console.
  2. Choose Groups.
  3. Choose Group Actions and then choose Add Users to Group.
  4. Choose the users to add to the group and then choose Add Users.

To remove a policy attached directly to a user

  1. Open the IAM console.
  2. Choose Users.
  3. For the user to detach a policy from, in the User name column, choose the name.
  4. For each policy listed under Attached directly, to remove the policy from the user, choose the X on the right side of the page and then choose Remove.
  5. Confirm that the user can still use AWS services as expected.

PCI requirement(s): 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamUserNoInlineAttachedPolicies
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 3 IAM policies should not allow full '*' administrative privileges

This control checks whether the default version of AWS Identity and Access Management policies (also known as customer managed policies) do not have administrator access with a statement that has "Effect": "Allow" with "Action": "*" over "Resource": "*".

It only checks for the customer managed policies that you created, but does not check for full access to individual services, such as "S3:*".

It does not check for inline and AWS managed policies.

Remediation

  1. Open the IAM console.
  2. Choose Policies.
  3. Choose the radio button next to the policy to remove.
  4. From Policy actions, choose Detach.
  5. On the Detach policy page, choose the radio button next to each user to detach the policy from and then choose Detach policy.
  6. Confirm that the user that you detached the policy from can still access AWS services and resources as expected.

PCI requirement(s): 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamPolicyNoStar
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 4 Hardware MFA should be enabled for the root user

This control checks whether your AWS account is enabled to use multi-factor authentication (MFA) hardware device to sign in with root user credentials.

It does not check whether you are using virtual MFA.

To address PCI DSS requirement 8.3.1, you can choose between hardware MFA (this control) or virtual MFA PCI.IAM.5(Virtual MFA should be enabled for the root user).

Remediation

To enable hardware-based MFA for the root account

  1. Log in to your account using the root user credentials.
  2. Choose the account name at the top right of the page and then choose My Security Credentials.
  3. In the warning, choose Continue to Security Credentials.
  4. Choose Multi-factor authentication (MFA).
  5. Choose Activate MFA.
  6. Choose a hardware-based (not virtual) device to use for MFA and then choose Continue.
  7. Complete the steps to configure the device type appropriate to your selection.

PCI requirement(s): 8.3.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamRootUserHardwareMfaEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 5 Virtual MFA should be enabled for the root user

This control checks whether users of your AWS account require a multi-factor authentication (MFA) device to sign in with root user credentials. It does not check whether you are using hardware MFA.

PCI requirement(s): 8.3.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamRootUserVirtualMfa
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 6 MFA should be enabled for all IAM users

This control checks whether the IAM users have multi-factor authentication (MFA) enabled.

PCI requirement(s): 8.3.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamUserMfaEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 7 IAM user credentials should be disabled if not used within a predefined number of days

This control checks whether your IAM users have passwords or active access keys that have not been used within a specified number of days. The default is 90 days.

PCI requirement(s): 8.1.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamUserUnusedCredentials90
Parent
Category
Targets

AWS > PCI v3.2.1 > IAM > 8 Password policies for IAM users should have strong configurations

This control checks whether the account password policy for IAM users uses the following minimum PCI DSS configurations.

PCI requirement(s): 8.1.4, 8.2.3, 8.2.4, 8.2.5

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/iamAccountPasswordPolicyStrong
Parent
Category
Targets

AWS > PCI v3.2.1 > KMS

This section contains recommendations for configuring AWS KMS resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/kms
Parent
Category

AWS > PCI v3.2.1 > KMS > 1 Customer master key (CMK) rotation should be enabled

This control checks that key rotation is enabled for each customer master key (CMK). It does not check CMKs that have imported key material.

You should ensure keys that have imported material and those that are not stored in AWS KMS are rotated. AWS managed customer master keys are rotated once every 3 years.

Remediation

To enable CMK rotation

  1. Open the AWS KMS console.
  2. To change the AWS Region, use the Region selector in the upper-right corner of the page.
  3. Choose Customer managed keys.
  4. In the Alias column, choose the alias of the key to update.
  5. Choose Key rotation.
  6. Select Automatically rotate this CMK every year and then choose Save.

PCI requirement(s): 3.6.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/kmsCmkRotationEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > Lambda

This section contains recommendations for configuring Lambda resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/lambda
Parent
Category

AWS > PCI v3.2.1 > Lambda > 1 Lambda functions should prohibit public access

This control checks whether the Lambda function resource-based policy prohibits public access.

It does not check for access to the Lambda function by internal principals, such as IAM roles. You should ensure that access to the Lambda function is restricted to authorized principals only by using least privilege Lambda resource-based policies.

For more information about using resource-based policies for AWS Lambda, see the AWS Lambda Developer Guide.

Remediation

To remediate this issue, you update the resource-based policy to change the publicly accessible Lambda function to a private Lambda function. You can only update resource-based policies for Lambda resources within the scope of the AddPermission and AddLayerVersionPermission API actions. You cannot author policies for your Lambda resources in JSON, or use conditions that don't map to parameters for those actions using the CLI or the SDK.

To use the AWS CLI to revoke function-use permission from an AWS service or another account

  1. To get the ID of the statement from the output of GetPolicy, from the AWS CLI, run the following:

    aws lambda get-policy —function-name yourfunctionname

This command returns the Lambda resource-based policy string associated with the publicly accessible Lambda function.

  1. From the policy statement returned by the get-policy command, copy the string value of the Sid field.

  2. From the AWS CLI, run

    aws lambda remove-permission --function-name yourfunctionname —statement-id youridvalue

To use the Lambda console to restrict access to the Lambda function

  1. Open the [AWS Lambda console](AWS Lambda console).

  2. Navigate to Functions and then select your publicly accessible Lambda function.

  3. Under Designer, choose the key icon at the top left. It has the tool-tip View permissions.

  4. Under Function policy, if the policy allows actions for the principal element "*" or {"AWS": "*"}, it is publicly accessible.

    • Consider adding the following IAM condition to scope access to your account only.

        "Condition": {
          "StringEquals": {
            "AWS:SourceAccount": "<account_id>"
            }
          }
        }

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/lambdaFunctionRestrictPublicAccess
Parent
Category
Targets

AWS > PCI v3.2.1 > Lambda > 2 Lambda functions should be in a VPC

This control checks whether a Lambda function is in a VPC.

It does not evaluate the VPC subnet routing configuration to determine public reachability.

Note that if Lambda@Edge is found in the account, then this control generates failed findings. To prevent these findings, you can disable this control.

Remediation

To configure a function to connect to private subnets in a virtual private cloud (VPC) in your account

  1. Open the AWS Lambda console.
  2. Navigate to Functions and then select your Lambda function.
  3. Scroll to Network and then select a VPC with the connectivity requirements of the function.
  4. To run your functions in high availability mode, Security Hub recommends that you choose at least two subnets.
  5. Choose at least one security group that has the connectivity requirements of the function.
  6. Choose Save.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/lambdaFunctionInVpc
Parent
Category
Targets

AWS > PCI v3.2.1 > RDS

This section contains recommendations for configuring RDS resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/rds
Parent
Category

AWS > PCI v3.2.1 > RDS > 1 RDS snapshots should prohibit public access

This control checks whether Amazon RDS DB snapshots prohibit access by other accounts. You should also ensure that access to the snapshot and permission to change Amazon RDS configuration is restricted to authorized principals only.

Note that if the configuration is changed to allow public access, the AWS Config rule may not be able to detect the change for up to 12 hours. Until the AWS Config rule detects the change, the check passes even though the configuration violates the rule.

Remediation

To remove public access for Amazon RDS Databases

  1. Open the Amazon RDS console.
  2. Navigate to Snapshots and then select the public Snapshot you want to modify
  3. From the Actions list, choose Share Snapshots
  4. From DB snapshot visibility, choose Private
  5. Under DB snapshot visibility, select for all
  6. Choose Save

PCI requirement(s): 1.2.1, 1.3.1, 1.3.4, 1.3.6, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/rdsDbSnapshotProhibitPublicAccess
Parent
Category
Targets

AWS > PCI v3.2.1 > RDS > 2 RDS DB Instances should prohibit public access

This control checks whether RDS instances are publicly accessible by evaluating the publiclyAccessible field in the instance configuration item. The value of publiclyAccessible indicates whether the DB instance is publicly accessible. When the DB instance is publicly accessible, it is an Internet-facing instance with a publicly resolvable DNS name, which resolves to a public IP address. When the DB instance isn't publicly accessible, it is an internal instance with a DNS name that resolves to a private IP address.

The control does not check VPC subnet routing settings or the Security Group rules. You should also ensure VPC subnet routing does not allow public access, and that the security group inbound rule associated with the RDS instance does not allow unrestricted access (0.0.0.0/0). You should also ensure that access to your RDS instance configuration is limited to only authorized users by restricting users' IAM permissions to modify RDS instances settings and resources.

Remediation

To remove public access for Amazon RDS Databases

  1. Open the Amazon RDS console.
  2. Navigate to Databases and then choose your public database.
  3. Choose Modify.
  4. Scroll to Network & Security.
  5. For Public accessibility, choose No.
  6. Scroll to the bottom and then choose Continue.
  7. Under Scheduling of modifications, choose Apply immediately.
  8. Choose Modify DB Instance.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/rdsDbInstanceProhibitPublicAccess
Parent
Category
Targets

AWS > PCI v3.2.1 > Redshift

This section contains recommendations for configuring AWS Redshift resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/redshift
Parent
Category

AWS > PCI v3.2.1 > Redshift > 1 Amazon Redshift clusters should prohibit public access

This control checks whether Amazon Redshift clusters are publicly accessible by evaluating the publiclyAccessible field in the cluster configuration item.

Remediation

  1. Open the Amazon Redshift console.
  2. On the navigation pane, choose Clusters and then select your public Amazon Redshift cluster.
  3. From the Cluster drop-down menu, choose Modify cluster.
  4. In Publicly accessible, choose No.
  5. Choose Modify.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/redshiftClusterProhibitPublicAccess
Parent
Category
Targets

AWS > PCI v3.2.1 > S3

This section contains recommendations for configuring S3 resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3
Parent
Category

AWS > PCI v3.2.1 > S3 > 1 S3 buckets should prohibit public write access

This control checks whether your S3 buckets allow public write access by evaluating the Block Public Access settings, the bucket policy, and the bucket access control list (ACL).

It does not check for write access to the bucket by internal principals, such as IAM roles. You should ensure that access to the bucket is restricted to authorized principals only.

Remediation

  1. Open the Amazon S3 console.
  2. Choose the name of the bucket identified in the finding.
  3. Choose Permissions and then choose Public access settings.
  4. Choose Edit, select all four options, and then choose Save.
  5. If prompted, enter confirm and then choose Confirm.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3BucketRestrictPublicWriteAccess
Parent
Category
Targets

AWS > PCI v3.2.1 > S3 > 2 S3 buckets should prohibit public read access

This control checks whether your S3 buckets allow public read access by evaluating the Block Public Access settings, the bucket policy, and the bucket access control list (ACL).

Unless you explicitly require everyone on the internet to be able to write to your S3 bucket, you should ensure that your S3 bucket is not publicly writable.

It does not check for read access to the bucket by internal principals, such as IAM roles. You should ensure that access to the bucket is restricted to authorized principals only.

Remediation

  1. Open the Amazon S3 console.
  2. Choose the name of the bucket identified in the finding.
  3. Choose Permissions and then choose Public access settings.
  4. Choose Edit, select all four options, and then choose Save.
  5. If prompted, enter confirm and then choose Confirm.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.6, 7.2.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3BucketRestrictPublicReadAccess
Parent
Category
Targets

AWS > PCI v3.2.1 > S3 > 3 S3 buckets should have cross-region replication enabled

This control checks whether S3 buckets have cross-region replication enabled.

PCI DSS does not require data replication or highly available configurations. However, this check aligns with AWS best practices for this control.

In addition to availability, you should consider other systems hardening settings.

Remediation

  1. Open the Amazon S3 console.
  2. Choose the S3 bucket that does not have cross-region replication enabled.
  3. Choose Management, then choose Replication.
  4. Choose Add rule. If versioning is not already enabled, you are prompted to enable it.
  5. Choose your source bucket - Entire bucket.
  6. Choose your destination bucket. If versioning is not already enabled on the destination bucket for your account, you are prompted to enable it.
  7. Choose an IAM role. For more information on setting up permissions for replication, see the Amazon Simple Storage Service Developer Guide.
  8. Enter a rule name, choose Enabled for the status, then choose Next.
  9. Choose Save

PCI requirement(s): 2.2

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3BucketCrossRegionReplicationEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > S3 > 4 S3 buckets should have server-side encryption enabled

This control checks that your Amazon S3 bucket either has Amazon S3 default encryption enabled or that the S3 bucket policy explicitly denies put-object requests without server-side encryption.

When you set default encryption on a bucket, all new objects stored in the bucket are encrypted when they are stored, including clear text PAN data.

Server-side encryption for all of the objects stored in a bucket can also be enforced using a bucket policy.

Remediation

  1. Open the Amazon S3 console.
  2. Choose the bucket from the list.
  3. Choose Properties.
  4. Choose Default encryption.
  5. For the encryption, choose either AES-256 or AWS-KMS.
    1. To use keys that are managed by Amazon S3 for default encryption, choose AES-256. For more information about using Amazon S3 server-side encryption to encrypt your data,
    2. To use keys that are managed by AWS KMS for default encryption, choose AWS-KMS. Then choose a master key from the list of the AWS KMS master keys that you have created. Type the Amazon Resource Name (ARN) of the AWS KMS key to use. You can find the ARN for your AWS KMS key in the IAM console, under Encryption keys. Or, you can choose a key name from the drop-down list.
  6. Choose Save.

PCI requirement(s): 3.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3BucketDefaultEncryptionEnabled
Parent
Category
Targets

AWS > PCI v3.2.1 > S3 > 5 S3 buckets should require requests to use Secure Socket Layer

This control checks whether Amazon S3 buckets have policies that require requests to use Secure Socket Layer (SSL).

S3 buckets should have policies that require all requests (Action: S3:*) to only accept transmission of data over HTTPS in the S3 resource policy, indicated by the condition key aws:SecureTransport.

This does not check the SSL or TLS version. You should not allow early versions of SSL or TLS (SSLv3, TLS1.0) per PCI DSS requirements.

Remediation

To remediate this issue, update the permissions policy of the S3 bucket.

To configure an S3 bucket to deny nonsecure transport

  1. Open the Amazon S3 console.
  2. Navigate to the noncompliant bucket, and then choose the bucket name.
  3. Choose Permissions, then choose Bucket Policy.
  4. Add a similar policy statement to that in the policy below. Replace awsexamplebucket with the name of the bucket you are modifying.
    {
      "Id": "ExamplePolicy",
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowSSLRequestsOnly",
          "Action": "s3:*",
          "Effect": "Deny",
          "Resource": [
            "arn:aws:s3:::awsexamplebucket",
            "arn:aws:s3:::awsexamplebucket/*"
          ],
          "Condition": {
            "Bool": {
              "aws:SecureTransport": "false"
            }
          },
          "Principal": "*"
        }
      ]
    }
  5. Choose Save.

PCI requirement(s): 4.1

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3BucketEnforcesSsl
Parent
Category
Targets

AWS > PCI v3.2.1 > S3 > 6 S3 Block Public Access setting should be enabled

This control checks whether the following public access block settings are configured at the account level.

ignorePublicAcls: true, blockPublicPolicy: true blockPublicAcls: true restrictPublicBuckets: true

The control passes if all of the public access block settings are set to true.

The control fails if any of the settings are set to false, or if any of the settings are not configured. When the settings do not have a value, the AWS Config rule cannot complete its evaluation.

As an AWS best practice, S3 buckets should block public access. Unless you explicitly require everyone on the internet to be able to access your S3 bucket, you should ensure that your S3 bucket is not publicly accessible.

Remediation

  1. Open the Amazon S3 console.
  2. In the navigation pane, choose Block public access (account settings).
  3. Choose Edit. Then select Block all public access.
  4. Choose Save changes

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/s3PublicAccessBlockBucketAccount
Parent
Category
Targets

AWS > PCI v3.2.1 > SSM

This section contains recommendations for configuring AWS SSM resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/ssm
Parent
Category

AWS > PCI v3.2.1 > SSM > 1 Amazon EC2 instances managed by Systems Manager should have a patch compliance status of COMPLIANT after a patch installation

This control checks whether the compliance status of the Amazon EC2 Systems Manager patch compliance is COMPLIANT or NON_COMPLIANT after the patch installation on the instance.

It only checks instances that are managed by AWS Systems Manager Patch Manager.

It does not check whether the patch was applied within the 30-day limit prescribed by PCI DSS requirement 6.2.

It also does not validate whether the patches applied were classified as security patches.

Remediation

This rule checks whether the compliance status of the Amazon EC2 Systems Manager patch compliance is COMPLIANT or NON_COMPLIANT. To find out more about patch compliance states, see the AWS Systems Manager User Guide.

  1. Open the AWS Systems Manager console
  2. In the navigation pane, under Instances & Nodes, choose Run Command.
  3. Choose Run command.
  4. Choose the radio button next to AWS-RunPatchBaseline and then change the Operation to Install.
  5. Choose Choose instances manually and then choose the noncompliant instance(s).
  6. Scroll to the bottom and then choose Run.
  7. After the command has completed, to monitor the new compliance status of your patched instances, in the navigation pane, choose Compliance.

PCI requirement(s): 6.2

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/ssmManagedInstanceCompliancePatchCompliant
Parent
Category
Targets

AWS > PCI v3.2.1 > SSM > 2 Instances managed by Systems Manager should have an association compliance status of COMPLIANT

This control checks whether the status of the AWS Systems Manager association compliance is COMPLIANT or NON_COMPLIANT after the association is run on an instance. The control passes if the association compliance status is COMPLIANT.

A State Manager association is a configuration that is assigned to your managed instances. The configuration defines the state that you want to maintain on your instances. For example, an association can specify that antivirus software must be installed and running on your instances, or that certain ports must be closed.

After you create one or more State Manager associations, compliance status information is immediately available to you in the console or in response to AWS CLI commands or corresponding Systems Manager API operations. For associations, Configuration Compliance shows statuses of Compliant or Non-compliant and the severity level assigned to the association, such as Critical or Medium. To learn more about State Manager association compliance, see About State Manager association compliance in the AWS Systems Manager User Guide.

You must configure your in-scope EC2 instances for Systems Manager association. You must also configure the patch baseline for the security rating of the vendor of patches, and set the autoapproval date to meet PCI DSS 3.2.1 requirement 6.2. For additional guidance on how to create an association, see Create an association in the AWS Systems Manager User Guide. For additional information on working with patching in Systems Manager, see AWS Systems Manager Patch Manager in the AWS Systems Manager User Guide.

Remediation

A failed association can be related to different things, including targets and SSM document names. To remediate this issue, you must first identify and investigate the association. You can then update the association to correct the specific issue.

You can edit an association to specify a new name, schedule, severity level, or targets. After you edit an association, Systems Manager creates a new version. To investigate and update a failed association

  1. Open the AWS Systems Manager console.
  2. In the navigation pane, under Instances & Nodes, choose Managed Instances.
  3. Choose the instance ID that has an Association status of Failed.
  4. Choose View details.
  5. Choose Associations.
  6. Note the name of the association that has an Association status of Failed. This is the association that you need to investigate. You need to use the association name in the next step.
  7. In the navigation pane, choose State Manager. Search for the association name, then select the association.
  8. After you determine the issue, edit the failed association to correct the problem. For information on how to edit an association, see Edit an association.

PCI requirement(s): 2.4

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/ssmManagedInstanceComplianceAssociationCompliant
Parent
Category
Targets

AWS > PCI v3.2.1 > SSM > 3 EC2 instances should be managed by AWS Systems Manager

This control checks whether the EC2 instances in your account are managed by Systems Manager.

AWS Systems Manager is an AWS service that you can use to view and control your AWS infrastructure. To help you to maintain security and compliance, Systems Manager scans your managed instances. A managed instance is a machine that is configured for use with Systems Manager. Systems Manager then reports or takes corrective action on any policy violations that it detects. Systems Manager also helps you to configure and maintain your managed instances. Additional configuration is needed in Systems Manager for patch deployment to managed EC2 instances.

Remediation

You can use the Systems Manager quick setup to set up Systems Manager to manage your EC2 instances.

To determine whether your instances can support Systems Manager associations, see Systems Manager prerequisites in the AWS Systems Manager User Guide.

  1. Open the AWS Systems Manager console.
  2. In the navigation pane, choose Quick setup.
  3. On the configuration screen, keep the default options.
  4. Choose Set up Systems Manager.

PCI requirement(s): 2.4, 6.2

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/ec2InstanceSsmManaged
Parent
Category
Targets

AWS > PCI v3.2.1 > SageMaker

This section contains recommendations for configuring AWS SageMaker resources and options.

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/sageMaker
Parent
Category

AWS > PCI v3.2.1 > SageMaker > 1 Amazon SageMaker notebook instances should not have direct internet access

This control checks whether direct internet access is disabled for an SageMaker notebook instance. To do this, it checks whether the DirectInternetAccess field is disabled for the notebook instance.

If you configure your SageMaker instance without a VPC, then by default direct internet access is enabled on your instance. You should configure your instance with a VPC and change the default setting to Disable — Access the internet through a VPC.

To train or host models from a notebook, you need internet access. To enable internet access, make sure that your VPC has a NAT gateway and your security group allows outbound connections. To learn more about how to connect a notebook instance to resources in a VPC, see Connect a notebook instance to resources in a VPC in the Amazon SageMaker Developer Guide.

You should also ensure that access to your SageMaker configuration is limited to only authorized users. Restrict users' IAM permissions to modify SageMaker settings and resources.

Remediation

Note that you cannot change the internet access setting after a notebook instance is created. It must be stopped, deleted, and recreated.

To configure an SageMaker notebook instance to deny direct internet access

  1. Open the SageMaker console
  2. Navigate to Notebook instances.
  3. Delete the instance that has direct internet access enabled. Choose the instance, choose Actions, then choose stop.
  4. After the instance is stopped, choose Actions, then choose delete.
  5. Choose Create notebook instance. Provide the configuration details.
  6. Expand the Network section. Then choose a VPC, subnet, and security group. Under Direct internet access, choose Disable — Access the internet through a VPC.
  7. Choose Create notebook instance.

PCI requirement(s): 1.2.1, 1.3.1, 1.3.2, 1.3.4, 1.3.6

URI
tmod:@turbot/aws-pciv3-2-1#/control/types/sageMakerNotebookInstanceDirectInternetAccessDisabled
Parent
Category
Targets