Requirement 2: Apply Secure Configurations to All System Components

PCI DSS 4.0.1 enhances Requirement 2 by emphasizing continuous configuration management rather than one-time hardening. Key changes include: 1) Explicit requirement for automated detection of default credentials in all systems, 2) Mandated inventory of all interactive accounts with documentation of access needs, 3) Expanded focus on cloud and containerized environments where vendors may manage underlying systems, and 4) Integration with vulnerability management processes (Req. 6). Organizations must now implement mechanisms to detect configuration drift and automatically enforce baseline configurations. The updated requirement also clarifies that 'vendor defaults' include not just passwords but also security parameters like encryption settings and service configurations.

For cloud systems using Platform-as-a-Service (PaaS) or Software-as-a-Service (SaaS) models where the vendor manages the underlying OS: 1) Obtain written confirmation from the provider that they change all default credentials before system deployment, 2) Verify through contractual agreements that security parameters meet PCI DSS requirements, 3) Implement compensating controls for any inherited risks (e.g., network segmentation), and 4) Maintain responsibility for application-layer configurations within your control. For Infrastructure-as-a-Service (IaaS), you retain full responsibility for OS-level configurations. Use cloud security posture management (CSPM) tools to continuously monitor configurations and detect deviations from your security baselines.

Organizations must maintain: 1) A formal hardening standard for each system type (e.g., Windows Server 2022 Baseline), 2) Automated enforcement mechanisms documentation (e.g., Ansible playbooks, GPOs), 3) Inventory of all approved services/ports/protocols with business justification, 4) Process for initial system hardening and ongoing configuration maintenance, 5) Evidence of default credential changes (automated scripts logs, change tickets), and 6) Quarterly review records of configuration standards. Documentation must cover both on-premises and cloud systems, including specific cloud service provider security parameters. PCI DSS 4.0.1 specifically requires that configuration standards address all security parameters identified in industry-hardening guidelines (e.g., CIS Benchmarks) relevant to each system component.

Configuration baselines must be: 1) Reviewed quarterly against emerging threats and vulnerability trends, 2) Updated immediately when new critical vulnerabilities are announced, 3) Validated annually against industry standards (e.g., CIS, NIST), and 4) Adjusted whenever significant infrastructure changes occur. Implement continuous configuration monitoring using tools that alert on deviations in real-time. For cloud environments, perform automatic checks after every infrastructure-as-code deployment. Maintain version control for all baselines with change logs showing what was modified and why. PCI DSS 4.0.1 emphasizes that reviews must consider both technical changes (e.g., new OS versions) and business process changes (e.g., new payment channels).

No system in the CDE is exempt from Requirement 2. For legacy systems: 1) Document risks in formal risk assessment, 2) Implement compensating controls (e.g., strict network segmentation, enhanced monitoring), 3) Obtain executive approval for temporary exceptions, and 4) Create migration plan to modernize/replace systems. Use protocol encryption wrappers for insecure legacy protocols. Implement host-based firewalls to restrict legacy system communications. For mainframes and industrial control systems, work with vendors to identify security parameters that can be modified without affecting functionality. All exceptions must be re-evaluated quarterly with documented risk acceptance renewals.

We maintain comprehensive evidence through multiple mechanisms: 1) Automated provisioning scripts that systematically change default credentials during system deployment (stored in Git with commit history), 2) Service accounts inventory with last password change dates from our privileged access management system, 3) Weekly scans using Rapid7 InsightIDR to detect any remaining default credentials, and 4) Change tickets linked to specific systems showing credential updates. For cloud environments, we utilize AWS Config rules that immediately flag resources with default credentials. Our evidence package includes screenshots from our configuration management database showing credential lifecycle dates, along with exception reports for any systems using vendor-maintained credentials (with supporting risk acceptance documents).

Our enforcement strategy includes: 1) Unified configuration management using Ansible Tower for on-prem systems and AWS Systems Manager for cloud resources, 2) Immutable infrastructure patterns where possible (Docker containers, AMI golden images), 3) Weekly compliance scans using Tenable.sc with custom audits for PCI hardening checks, 4) GitOps workflow for infrastructure-as-code templates with mandatory peer reviews. We maintain separate but aligned baselines for Windows (aligned to CIS Level 1) and Linux (STIG-compliant) systems. For containerized environments, we use Open Policy Agent to enforce security contexts. All configuration changes require service tickets linked to our change management system (ServiceNow), with rollback procedures tested quarterly. Our hybrid dashboard in Splunk provides real-time compliance status across all environments.

Our secure deployment pipeline includes: 1) Pre-provisioning checks in Terraform Enterprise that block deployment if default credentials are detected, 2) Mandatory security group configuration through centralized cloud governance tools, 3) Automated hardening via Packer templates that build pre-approved VM images, 4) Post-deployment validation scans using Qualys Cloud Agent. All systems must pass through a staging environment where they're tested against 156 specific security checks (aligned to PCI DSS 4.0.1 Req 2.2.6). Our CI/CD pipelines incorporate security gates that prevent promotion to production until all hardening requirements are met. For emergency deployments, we use just-in-time access with 4-hour expiration and mandatory post-remediation audits within 24 hours. All processes are documented in our Secure System Deployment Standard (version 3.4, reviewed Q2 2025).