System Hardening and Secure Configuration
System hardening and secure configuration establish the foundational security posture of all system components within the cardholder data environment. PCI DSS Requirement 2 mandates applying secure configurations to all system components, ensuring that vendor defaults are changed, unnecessary services are disabled, and security parameters are configured to prevent misuse. In cloud environments, infrastructure-as-code, automated configuration management, and continuous compliance monitoring provide opportunities to implement and maintain secure configurations with greater consistency, auditability, and scalability than traditional manual configuration approaches.
System Hardening and Secure Configuration within the AWS SRA
The AWS SRA provides foundational guidance for system hardening that directly supports key elements of PCI DSS:
Using AWS Systems Manager State Manager and AWS Config together enables automated enforcement and validation of configuration standards across all system components. State Manager can apply and maintain desired configurations, while Config Rules continuously verify compliance with defined standards, satisfying Requirements 2.2.1 and 2.2.6 for configuration standards that are consistent with industry-accepted hardening guidelines and system security parameters configured to prevent misuse.
AWS Config Conformance Packs enable deployment of pre-built collections of Config Rules aligned with industry frameworks such as CIS Benchmarks, NIST guidelines, and PCI DSS requirements, providing automated validation that system components are configured according to industry-accepted hardening standards (Requirement 2.2.1).
Using AWS Systems Manager Session Manager for administrative access eliminates the need for bastion hosts, SSH keys, or open inbound ports, while enforcing encrypted connections (HTTPS) for all administrative functions, directly supporting Requirement 2.2.7 for encrypted non-console administrative access.
AWS Security Hub security standards automatically assess resources against CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, and the PCI DSS security standard, providing continuous validation that configurations align with industry-accepted hardening standards and identifying configuration drift from secure baselines (Requirement 2.2.1).
Hardened AMIs from AWS Marketplace provide pre-configured baseline images that have been hardened by security professionals according to CIS Benchmarks and vendor hardening recommendations, reducing the time and effort required to implement secure configurations and ensuring consistency across deployments (Requirement 2.2.1).
AWS CloudFormation and AWS CDK enable organizations to define hardened configurations as code, ensuring that every deployment follows approved configuration standards and eliminating manual configuration errors. Templates can be version-controlled, peer-reviewed, and validated before deployment, supporting consistent application of configuration standards across all system components (Requirement 2.2.1).
AWS Organizations SCPs enforce preventive guardrails across all accounts in the organization, ensuring that insecure configurations cannot be deployed regardless of individual account-level permissions. SCPs can restrict the use of unapproved services, enforce encryption requirements, and limit deployments to authorized regions, supporting consistent application of security parameters across the environment (Requirements 2.2.1 and 2.2.6). Service control policy examples
System Hardening and Secure Configuration beyond the AWS SRA
Some incremental enhancements may be needed to extend the AWS SRA for alignment with additional PCI DSS requirement elements.
Automate vendor default account remediation: Deploy AWS Systems Manager Automation documents and Run Command to systematically identify and remediate vendor default accounts on EC2 instances and other system components at launch. Combine with AWS Config to continuously detect instances running with known default credentials or default account configurations, triggering automated remediation workflows to change default passwords and disable unnecessary default accounts (Requirement 2.2.2).
Enforce function isolation through deployment architecture: PCI DSS Requirement 2.2.3 mandates that each system component performs only one primary function, or that functions with differing security levels are isolated from one another, with the intent of preventing a compromise of one function from providing unauthorized access to another. AWS SRA already prescribes AWS CloudFormation, AWS CDK, AWS Config, and security groups as foundational components across the multi account environment. Extending the AWS SRA for Requirement 2.2.3 involves applying these existing AWS SRA prescribed services in a pattern that enforces function isolation through three complementary controls.
Infrastructure as Code: The AWS SRA prescribes AWS CloudFormation and AWS CDK for consistent infrastructure deployment across accounts. Extend this by defining deployment templates that assign a single primary function to each system component. CloudFormation stacks and CDK constructs structurally separate each function into its own deployment unit with dedicated IAM roles, network configurations, and security groups so that the only permitted communication paths between functions are those explicitly defined in the template. Codifying these patterns ensures every deployment is consistent, repeatable, and auditable, preventing unauthorized addition of secondary functions to any component. Because templates are version controlled and peer reviewed, any deviation from the approved isolation architecture requires a deliberate, auditable change.
EC2 isolation: Different EC2 instances on the same physical host are isolated from each other as though they are on separate physical hosts. The hypervisor isolates CPU and memory, and the instances are provided with virtualized disks instead of accessing the raw disk devices. Additionally for Windows host you can use Windows Firewall settings with Group Policy Objects (GPO) to block specific applications from accessing the network, ensuring only permitted functionality is allowed on the host.
AWS Lambda isolation: Lambda functions provide tenant isolation mode to serve multiple end-users or tenants using a single Lambda function, while ensuring that the execution environments used to process invocations for individual tenants remain isolated from one another. You can also use AWS Lambda Micro VM serverless compute environments that provide VM-level isolation with full operating system capabilities (for e.g. installing system packages or mounting filesystems), snapshot-based rapid startup speeds, and fine-grained control over ingress networking (port access, support for HTTP/2, gRPC, WebSockets) and egress networking (public internet access and VPC access).
Container Based Function Isolation: The AWS SRA multi account structure provides dedicated accounts for workloads with distinct security requirements. Within those accounts, deploy each function (web server, application logic, database) as a separate container using Amazon ECS task definitions or Amazon EKS pod specifications. Each container operates independently
with its own runtime boundary, dedicated IAM task role scoped to least privilege, and isolated resource limits. This extends the AWS SRA account level isolation principle down to the workload layer, limiting the blast radius if any single component is compromised and preventing lateral movement between functions. Network Level Segmentation: The AWS SRA prescribes security groups and VPC architecture as core network controls. Extend these by applying security groups that enforce network level isolation between containers serving different primary functions. Each security group permits only the minimum required ports and protocols (e.g., the application container can reach the database container on port 5432, but the web container cannot), ensuring components cannot communicate beyond their defined trust boundaries. Deploy AWS Config, already prescribed by the AWS SRA for continuous compliance monitoring, to validate that deployed security groups maintain the intended isolation boundaries and detect any unauthorized changes to permitted communication paths (Requirement 2.2.3).
Automate removal of unnecessary services and functions: Use AWS Systems Manager State Manager associations to continuously enforce desired-state configurations that disable unnecessary services, protocols, daemons, and functions on EC2 instances. Deploy AWS Config to detect system components running unauthorized services or protocols, and trigger AWS Systems Manager Automation remediation to disable them. For any insecure services that must remain enabled, use AWS Config to validate that additional security controls such as encryption and enhanced logging are in place (Requirements 2.2.4 and 2.2.5).
Implement automated security parameter validation and remediation: Deploy AWS Config, including custom rules where needed, to validate that security parameters are properly configured across all system components, covering authentication, authorization, logging, encryption, and network access control settings. Pair Config Rules with AWS Systems Manager Automation documents to automatically remediate parameter drift, ensuring security parameters remain configured to prevent misuse. Deploy AWS Network Firewall to enforce stateful inspection and protocol level security parameters at the VPC perimeter, ensuring only approved protocols and traffic patterns are permitted into and out of the cardholder data environment. Use AWS Firewall Manager to centrally define and apply Network Firewall policies, security group rules, and WAF configurations across all accounts in the organization, ensuring consistent enforcement of network security parameters and automatically remediating resources that drift from approved baselines (Requirement 2.2.6).
Enforce and audit encrypted administrative access: Configure AWS Systems Manager Session Manager with session encryption and logging enabled, forwarding session logs to Amazon S3 and Amazon CloudWatch Logs for audit purposes. Deploy AWS Config to detect security groups that permit inbound SSH (port 22) or RDP (port 3389) access, and use AWS Systems Manager Automation to automatically revoke non-compliant rules. Enforce AWS IAM policies requiring MFA for all administrative actions (Requirement 2.2.7).
Implement continuous configuration change detection and response: Integrate AWS Config with Amazon EventBridge and AWS CloudTrail to detect and alert on configuration changes in real time. Deploy EventBridge rules that trigger AWS Lambda functions or AWS Systems Manager Automation documents to evaluate changes against approved baselines and automatically remediate unauthorized modifications, ensuring configuration standards are verified as in place before or immediately after system components connect to a production environment (Requirement 2.2.1).
