PCI DSS Requirement 2: Explained

PCI DSS Requirement 2: Apply secure configurations to all system components

PCI DSS Requirement 2 mandates the implementation of secure configuration settings for systems and applications that process, transmit, or store cardholder data. It requires organizations to establish and maintain secure configurations, including regular updates and patches, to minimize vulnerabilities and protect sensitive payment information.

Additionally, Requirement 2 emphasizes the importance of conducting regular vulnerability assessments to identify and address potential security gaps proactively. By adhering to Requirement 2, businesses can enhance their overall security posture and ensure compliance with PCI DSS standards.

PCI DSS Requirement 2.1: Processes and mechanisms for applying secure configurations to all system components are defined and understood

PCI DSS Requirement 2.1 is further split into 2.1.1 and 2.1.2. Let's explore these in detail.

PCI DSS Requirement 2.1.1: Manage security policies and operational procedures

Definitions

• Security policy: A high-level document that defines the organization's overall security objectives and principles regarding protecting cardholder data.
• Operational procedure: A detailed document that outlines specific steps and controls on how to perform activities related to cardholder data security. It defines the methods and processes to be followed to achieve the desired security outcome in a consistent and compliant manner.

This requirement focuses on the effective management of all security policies and operational procedures identified in Requirement 2 of the PCI DSS. It emphasizes the importance of the following four key aspects:

• Documentation: All security policies and operational procedures must be clearly documented. This documentation should be comprehensive, easy to understand, and readily accessible to all relevant personnel.
• Currency: The documented policies and procedures must be kept up to date. This means regularly reviewing and updating them to reflect changes in technologies, business practices, and security threats.
• Active use: The documented policies and procedures must be actively used by personnel within your organization. This ensures everyone is aware of their security responsibilities and how to perform tasks securely.
• Communication: All affected parties (including employees, contractors, and third-party vendors) must be aware of the documented security policies and procedures. This can be achieved through training programs, readily available documentation repositories, and awareness campaigns.

Business implications

• Effectively managing security policies and procedures helps ensure everyone understands their security responsibilities and how to handle cardholder data securely. This reduces the risk of human error and unintentional security gaps that could lead to data breaches.
• Implementing this requirement demonstrates your commitment to PCI DSS compliance and helps avoid potential fines associated with non-compliance.
• Well-documented and communicated security policies foster a culture of security awareness within the organization.

Best practices to meet this requirement

• Develop comprehensive documentation: Create clear and concise documentation for all security policies and operational procedures related to Requirement 2.
• Regular reviews and updates: Establish a process for regularly reviewing and updating your security policies and procedures. This should occur whenever there are changes to technologies, business practices, or security threats.
• Implement training programs: Provide training programs for all affected parties to ensure they understand the documented security policies and procedures.
• Maintain accessible documentation: Make the documented security policies and procedures readily accessible to all relevant personnel. This could involve storing them on a central server, a shared drive, or a dedicated knowledge base.
• Communicate updates: Clearly communicate any updates or changes made to the security policies and procedures to all affected parties.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.1.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.1.2: Document, assign, and communicate roles and responsibilities

This requirement emphasizes the importance of clearly defining, assigning, and communicating roles and responsibilities related to the activities outlined in PCI DSS Requirement 2. This ensures everyone within your organization understands who is accountable for specific security tasks related to protecting cardholder data.

• Roles: Broad categories of security functions within the organization (e.g., security officer, system administrator).
• Responsibilities: Specific tasks and activities assigned to individuals within a particular role (e.g., a system administrator is responsible for patching operating systems).

Business implications

• Clearly defined and communicated roles and responsibilities help avoid confusion and ensure critical security tasks are not overlooked or performed incorrectly. This reduces the risk of human error that could lead to security vulnerabilities.
• By assigning clear responsibilities, individuals are held accountable for performing security tasks effectively. This fosters a culture of ownership and accountability for data security.
• A well-defined security team structure with clear roles and responsibilities promotes efficient task management and incident response.

Best practices to meet this requirement

• Develop roles and a responsibility matrix: Create a documented matrix (e.g., RACI matrix) that outlines the roles responsible, accountable, consulted, and informed for each activity within Requirement 2.
• Link to security policies: Integrate the roles and responsibility matrix with your security policies or create a separate document for clarity.
• Assign responsibilities to individuals: Assign specific responsibilities to individuals within each relevant role.
• Communicate roles and responsibilities: Clearly communicate the documented roles and responsibilities to all personnel. This can be achieved through training programs, knowledge base articles, or internal communication channels.
• Obtain acknowledgement: Consider having personnel acknowledge their understanding and acceptance of their assigned roles and responsibilities.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.1.2 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2: System components are configured and managed securely

This requirement is subdivided into 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, and 2.2.7. Let's explore these in detail.

PCI DSS Requirement 2.2.1: Implement and enforce system configuration standards

This requirement focuses on the importance of establishing and enforcing secure system configuration standards for all system components within your environment that process, store, or transmit cardholder data. These standards aim to address known vulnerabilities and mitigate potential security risks.

• Develop configuration standards: You must develop documented system configuration standards that define secure configuration practices for various system components (e.g., operating systems, databases, network devices, applications). These standards should address:
  • Disabling unnecessary services and features.
  • Applying security patches promptly.
  • Using strong passwords and access controls.
  • Securely configuring user accounts and permissions.
  • Implementing other security controls relevant to specific system components.
• Align with industry standards: Consider referencing and adapting established industry hardening guidelines from organizations like the Center for Internet Security (CIS), the National Institute of Standards and Technology (NIST), or vendor recommendations.
• Regular updates: These configuration standards must be regularly reviewed and updated to reflect new threats and vulnerabilities identified through ongoing vulnerability scanning and threat intelligence (as required by PCI DSS Requirement 6.3.1).
• Consistent enforcement: Ensure your configuration standards are consistently applied:
  • When configuring new systems.
  • During system maintenance activities.
  • When verifying configurations before connecting new system components to the production environment.

Business implications

• Enforcing consistent configuration standards across your systems strengthens your overall security posture and makes it more difficult for attackers to exploit vulnerabilities.
• The process may require additional resources from IT personnel to identify vulnerabilities, define standards, and ensure consistent implementation.
• Developing, implementing, and maintaining secure system configuration standards can involve initial costs.

Best practices to meet this requirement

• Develop documented standards: Create clear and concise documentation outlining your system configuration standards for different components.
• Reference industry guidelines: Align your standards with established industry hardening guides like CIS Benchmarks or vendor recommendations.
• Regular reviews and updates: Schedule regular reviews of your configuration standards to incorporate new findings from vulnerability scanning and threat intelligence.
• Automated configuration management: Consider implementing automated configuration management tools to ensure consistent and efficient application of security standards across your systems.
• Training and awareness: Provide training to personnel responsible for system configuration and maintenance to ensure they understand the importance of adhering to the documented standards.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2.2: Manage vendor default accounts securely

Definitions

• Vendor default account: A preconfigured account provided by a software or hardware vendor with a generic username and password. These accounts are intended to be changed during initial setup but are sometimes left unchanged, creating a security vulnerability.

  This requirement addresses the security risk associated with using vendor-default account credentials (usernames and passwords) that come preconfigured with certain software or hardware. It emphasizes the importance of managing these default accounts securely to prevent unauthorized access to your systems.

• Two options: You have two options for handling vendor default accounts:
  • Change the password: If you intend to use a vendor default account, you must immediately change the default password to a unique and complex password following the requirements outlined in PCI DSS Requirement 8.3.6 (strong passwords).
  • Remove or disable: If you don't plan to use a vendor default account, you must remove the account entirely or disable it to prevent unauthorized access attempts.

Business implications

• Conduct periodic reviews and audits to verify that all vendor default accounts are managed according to the defined process. This helps identify any missed accounts or deviations from the established procedures.
• If a default account is not necessary, the organization should disable it to eliminate the potential security risk altogether. This is the preferred approach whenever possible.
• Identifying all vendor-supplied default accounts associated with CHD systems requires a comprehensive inventory. This can be time-consuming, especially in complex IT environments.

Best practices to meet this requirement

• Identify vendor default accounts: Maintain an inventory of all vendor-supplied software and hardware within your environment. Review the vendor documentation to identify any preconfigured default accounts associated with these products.
• Document the management approach: Develop a documented procedure outlining how you will handle vendor default accounts (change the password or remove/disable the account).
• Implement your chosen approach: Consistently implement your chosen approach (change the password or remove/disable the account) for all identified vendor default accounts.
• Use strong passwords: If you choose to use a vendor default account, ensure you change the password to a strong and unique combination meeting PCI DSS 8.3.6 requirements.
• Verification during system setup: Establish a process to verify that default credentials have been changed or removed during the installation and configuration of new systems.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.2 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2.3: Manage systems with different security needs

This requirement focuses on securing systems that may host multiple functionalities with varying security requirements. It emphasizes the importance of isolating or securing these functionalities to prevent lower security needs from compromising the security of more critical functions.

Definitions

• Primary function: The main purpose or service provided by a system component (e.g., web server, database server, application server).
• Security level: The level of protection applied to a system component based on its criticality and the sensitivity of the data it processes.
• System component: A hardware or software element within your IT infrastructure (e.g., physical server, virtual machine, container).

Business implications

Implementing secure separation of functions can be complex, especially in environments with limited resources or legacy systems. Organizations may need to:

• Identify all system components that house a combination of functions with varying security needs.
• Analyze the security classification of each function.
• Decide on an appropriate isolation or segregation approach based on the PCI DSS guidelines (e.g., separate systems, virtual machines, network segmentation).
• Implement strong isolation mechanisms. In some cases, this might introduce limitations on system performance or functionality. Organizations need to carefully balance security needs with operational requirements.

Best practices to meet this requirement

• Identify system functions: Inventory and understand the primary functions performed by each system component within your environment.
• Assess security needs: Analyze the security requirements for each identified function, considering the sensitivity of the data it processes and its role in your PCI environment.
• Implement segregation: Ideally, you should deploy each primary function on a separate system component. This ensures complete isolation and avoids the need for additional controls.
• Isolation techniques: If deploying separate systems is not feasible, consider isolation techniques for functions with different security needs on the same system:
  • Virtualization: Utilize virtualization technologies to create isolated virtual environments for each function.
  • Logical separation: Implement logical separation techniques like dedicated user accounts, network segmentation, and firewalls to restrict access and communication between functions.
• Securing lower security functions: If functions with lower security needs coexist with critical functions, implement additional security controls to ensure they cannot compromise the higher security functions. This may involve restricting access, hardening configurations, or implementing additional monitoring.
• Security for virtualized environments: If you use virtualization, ensure you manage the security level of each virtual component based on its function.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.3 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2.4: Disable unnecessary services, protocols, daemons, and functionality

This requirement emphasizes the importance of minimizing the attack surface of your systems by disabling or removing any unnecessary services, protocols, daemons, and functionalities. By focusing on securing only the essential functionality, you reduce the potential for attackers to exploit vulnerabilities in unused components.

Definitions

• Service: A program that runs in the background on a system and provides specific functionalities (e.g., web server, database service).
• Protocol: A set of rules that governs communication between devices on a network.
• Daemon: A program that runs in the background on a system and performs a specific task (e.g., mail transfer agent).
• Functionality: A specific capability or feature provided by a system component.

Business implications

• Disabling unused features can potentially improve system performance and resource utilization.
• Effectively determining which functionalities are truly unnecessary can be challenging. It requires a thorough understanding of the system and its components. Organizations may need to involve system administrators and security professionals in this process.
• In some cases, disabling certain functionalities might inadvertently impact legitimate business processes. Organizations need to carefully assess the impact of disabling functionalities before taking action.

Best practices to meet this requirement

• Identify system functionality: Inventory all services, protocols, daemons, and functionalities running on each system component within your environment.
• Document essential functionality: Clearly define the essential functionalities required for each system component to perform its intended role in your environment. Document this in your system configuration standards.
• Disable or remove unnecessary elements: Disable or remove any services, protocols, daemons, and functionalities that are not deemed essential for system operation.
• Regular reviews: Schedule regular reviews of system configurations to identify and disable any newly installed or unnecessary functionalities.
• Vendor guidance: Refer to vendor documentation for recommendations on disabling unnecessary features or services for their specific software or hardware products.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.4 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2.5 : Manage insecure services, protocols, or daemons

This requirement acknowledges that certain services, protocols, or daemons may be inherently insecure due to known vulnerabilities or weak security practices. It focuses on ensuring these insecure elements are either eliminated or adequately secured with additional controls to mitigate the associated risks.

Definitions

• Insecure service: A program running in the background on a system that provides a specific functionality but possesses known security vulnerabilities or weak security practices (e.g., Telnet).
• Insecure protocol: A set of rules governing communication between devices on a network that has known security weaknesses (e.g., FTP).
• Insecure daemon: A program running in the background on a system performing a specific task but with known security vulnerabilities (e.g., TFTP).

Business implications

• Removing insecure functionalities might require finding and implementing secure alternatives, potentially involving additional technical expertise and resources.

Best practices to meet this requirement

• Identify insecure elements: Maintain an inventory of all services, protocols, and daemons running on your systems. Consult industry security resources (e.g., NIST, ENISA, OWASP) to identify elements classified as insecure.
• Prioritize elimination: Whenever possible, prioritize eliminating insecure services, protocols, or daemons from your environment.
• Implement additional security (if elimination is not feasible): If eliminating an insecure element is not practical, document a clear business justification for its continued use. Additionally, implement compensating security controls to mitigate the risks. These controls may include:
  • Restricting access to the insecure element.
  • Implementing network segmentation to isolate the element.
  • Regularly patching and updating the insecure element (if applicable).
  • Implementing additional security features offered by the vendor.
• Document the management approach: Develop a documented procedure outlining how you will handle identified insecure elements (eliminate or implement additional security).
• Security during deployment: Implement a process to ensure new system components are deployed with secure configurations and avoid introducing insecure elements.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.5 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2.6: Configure system security parameters securely

This requirement emphasizes the importance of configuring various security settings and parameters within your system components to prevent misuse and potential compromise by attackers. These parameters influence the overall security posture of your systems.

Definitions

• System security parameters: Settings within a system component that control various security functionalities (e.g., account lockout thresholds, password complexity requirements, and firewall rules).

Business implications

• Developing, implementing, and maintaining secure system configuration standards can involve initial costs for resources and expertise.
• Keeping system configurations secure requires ongoing efforts to address new vulnerabilities and adapt to changes within the system or its environment.

Best practices to meet this requirement

• Develop system configuration standards: Establish documented system configuration standards that specifically address security settings and parameters for each type of system component in your environment.
• Focus on known vulnerabilities: Prioritize configuring parameters that address known security weaknesses or vulnerabilities within your specific system types.
• Security parameter knowledge: Ensure personnel responsible for system configuration and administration possess a strong understanding of the security parameters and settings applicable to the systems they manage. This includes secure settings for accessing cloud portals.
• Vendor documentation: Refer to vendor documentation for your specific system components to identify the relevant security parameters and their recommended configurations.
• Industry guidance: Consult industry security resources (e.g., PCI Security Standards Council and NIST) for additional guidance on securing system parameters.
• Regular reviews: Schedule periodic reviews of system configurations to ensure security parameters remain properly configured.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.6 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.2.7: Encrypt non-console administrative access

This requirement focuses on protecting the confidentiality of administrative credentials during remote access sessions. It mandates that all non-console administrative access (access other than physically sitting at the console) must be encrypted using strong cryptography to prevent unauthorized individuals from intercepting login details.

Definitions

• Non-console administrative access: Any method of accessing a system for administrative purposes that doesn't involve physically being present at the console (e.g., remote access via SSH and web-based management interfaces).
• Strong cryptography: Encryption algorithms and protocols that are considered secure and resistant to cracking by attackers.
• Administrative credentials: Usernames, passwords, or other authentication factors used to gain administrative access to a system.

Business implications

• In some cases, encryption can introduce slight slowdowns in remote access performance. Organizations need to balance security needs with performance requirements.
• Managing encryption keys and certificates for secure remote access can add some complexity to IT administration.

Best practices to meet this requirement

• Secure protocols: Implement secure protocols like SSH (Secure Shell) or HTTPS (Hypertext Transfer Protocol Secure) for all non-console administrative access. These protocols encrypt communication between the client and the server, protecting login credentials.
• Strong encryption: Ensure the chosen protocols are configured to use strong encryption algorithms and ciphers that are resistant to modern attacks.
• Disable insecure protocols: Disable insecure protocols like Telnet or FTP for administrative access, as they transmit data in cleartext.
• Vendor guidance: Refer to vendor documentation for your specific system components to understand the available secure protocols and their recommended configurations.
• Industry standards: Consult industry security resources (e.g., NIST SP 800-52, SP 800-57) for additional guidance on securing non-console administrative access.
• Regular reviews: Periodically review system configurations to ensure secure protocols remain enabled and strong encryption is used.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.2.7 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.3: Wireless environments are configured and managed securely

This requirement is further divided into 2.3.1 and 2.3.2. Let's explore these in detail.

PCI DSS Requirement 2.3.1: Change wireless vendor defaults (CDE and account data)

This requirement focuses on securing wireless networks connected to the Cardholder Data Environment (CDE) or transmitting account data. It mandates that all default security settings configured by the wireless equipment vendor must be changed during installation. This mitigates the risk of attackers exploiting these well-known defaults to gain unauthorized access to your network and potentially steal sensitive cardholder data.

Definitions

• Wireless environment: A network that uses radio waves to connect devices without the need for physical cables.
• CDE: The environment that houses cardholder data or systems that process or store cardholder data.
• Wireless vendor defaults: The preconfigured security settings applied by the manufacturer on a wireless device during its initial setup. These defaults are typically weak and easily exploitable by attackers.
• Default wireless encryption keys: Preconfigured encryption keys used to secure communication on a wireless network. Using vendor defaults is highly discouraged.
• Wireless access point (WAP): A device that creates a wireless network and allows other devices to connect.
• Simple Network ManagementProtocol (SNMP): A protocol used to manage network devices remotely. Vendor defaults for SNMP communities (used for authentication) are often weak and should be changed.

Business implications

• Implementing and maintaining secure wireless configurations requires additional effort from IT personnel to manage vendor defaults, update firmware, and ensure ongoing security.
• In some cases, depending on the existing security measures, organizations might need to invest in upgrades to WAPs or implement new security protocols to comply with this

Best practices to meet this requirement

• Develop a policy: Establish a documented policy or procedure outlining the process for handling wireless vendor defaults. This policy should mandate changing all defaults during installation or confirming their security.
• Change defaults at installation: When installing WAPs or other wireless equipment, prioritize changing all default security settings like passwords, encryption keys, and SNMP communities.
• Secure configuration management: Implement a secure method for managing and storing WAP configurations to prevent unauthorized access and potential compromise of default credentials.
• Strong passwords andencryption: Configure wireless networks with strong passwords/phrases and robust encryption algorithms (e.g., WPA2 with AES). Avoid using weak encryption protocols like WEP.
• Regular reviews: Periodically review wireless network configurations to ensure vendor defaults haven't been inadvertently re-enabled and strong security settings are maintained.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.3.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 2.3.2: Rotate wireless encryption keys (CDE and account data)

This requirement focuses on maintaining the confidentiality of wireless encryption keys used to secure communication within wireless networks connected to the CDE or transmitting account data. It mandates that these encryption keys be rotated under specific circumstances:

• Personnel changes: Whenever personnel with knowledge of the key leave the company or move to a role where such knowledge is no longer necessary.
• Compromised keys: Whenever a key is suspected of being compromised due to a security incident or other reasons.

Definitions

• Wireless encryption key: A secret value used to encrypt and decrypt data transmitted over a wireless network. Strong encryption keys are crucial for protecting the confidentiality of sensitive data.
• CDE: The environment that houses cardholder data or systems that process or store cardholder data.
• Key rotation: The process of periodically changing encryption keys to mitigate the risk of unauthorized access if a key is compromised.

Business implications

• Organizations need to have a documented process for managing wireless encryption key changes. This includes tracking key assignments, scheduling updates, and ensuring proper handover procedures when personnel leave the company. This can add some workload for IT personnel.
• If not managed carefully, there's a risk of disrupting wireless access during key change procedures. Organizations need to plan and implement key updates during scheduled maintenance windows to minimize disruptions.

Best practices to meet this requirement

• Develop a key rotation policy: Establish a documented policy outlining the process for rotating wireless encryption keys. This policy should define the frequency of rotation (e.g., quarterly or biannually) and the circumstances triggering key changes (e.g., personnel changes or suspected compromise).
• Joiners, movers, leavers (JML) process: Integrate wireless key rotation into your JML process to ensure keys are changed whenever personnel with access knowledge leave the company or move to roles where such knowledge is no longer required.
• Incident response plan: Ensure your incident response plan (as mandated by PCI DSS Requirement 12.10.1) addresses the steps to be taken if a wireless encryption key is suspected or confirmed to be compromised. This may involve immediate key rotation and investigation to identify the root cause of the compromise.
• Avoid static keys: Refrain from using static pre-shared keys (PSK) for extended periods. Consider using more secure mechanisms like Dynamic PSK (derived from user credentials) or 802.1X authentication.
• Secure key management: Implement secure procedures for managing and storing wireless encryption keys. This includes restricting access to keys, using strong key generation practices, and securely storing keys to prevent unauthorized disclosure.

How to meet this PCI DSS compliance requirement

Here's a table outlining how compliance with Requirement 2.3.2 will be verified during a PCI DSS assessment: