Take the lead in data protection best practices with our unified SIEM solution!
Disclaimer: This guide has been created with reference to official documents on the PCI DSS published by relevant government authorities. It is intended to provide a clear and comprehensive explanation of PCI DSS Requirement 2. The contents are for informational purposes only and should not be considered as legal advice. Organizations should consult with a qualified PCI DSS consultant to ensure compliance.
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:
Requirement | Actions required | How the assessment is done |
2.1.1 | Examine documentation and interview personnel. | The assessor will: *Review the documented security policies and operational procedures to ensure they address all elements of Requirement 2. *Interview personnel from various departments to verify they are aware of the documented security policies and procedures and understand how to apply them in their daily tasks. |
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:
Requirement | Actions required | How the assessment is done |
2.1.2.a | Examine documentation. | The assessor will review your documented roles and responsibility matrix (or equivalent document) to verify that it clearly defines roles and assigns responsibilities for all activities within Requirement 2. |
2.1.2.b | Interview personnel. | The assessor will interview personnel with security responsibilities to verify: *Their assigned roles and responsibilities are aligned with the documented matrix. *They understand the specific tasks and activities they are accountable for. |
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:
Requirement | Actions required | How the assessment is done |
2.2.1.a | Examine system configuration standards. | The assessor will review your documented system configuration standards to verify they address all elements specified in the requirement, including disabling unnecessary services, applying security patches, and implementing strong access controls. |
2.2.1.b | Examine policies and interview personnel. | The assessor will: *Review your security policies and procedures to verify they outline a process for updating configuration standards based on new vulnerabilities (as required by PCI DSS Requirement 6.3.1). *Interview personnel responsible for system configuration to ensure they understand the process for updating standards. |
2.2.1.c | Examine configuration settings and interview personnel. | The assessor will: *Review system configuration settings on sample systems to verify they adhere to your documented standards. *Interview personnel responsible for system configuration to understand how they apply the standards when configuring new systems and during maintenance activities. |
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:
Requirement | Actions required | How the assessment is done |
2.2.2.a | Examine system configuration standards. | The assessor will review your documented system configuration standards to verify they address managing vendor default accounts according to this requirement (change the password or remove/disable the account). |
2.2.2.b (for used accounts): | Examine vendor documentation and observe logins. | The assessor will: *Review vendor documentation to understand default account credentials for relevant software/hardware. *Observe a system administrator logging in using the default account (if intended for use) to verify the password has been changed. |
2.2.2.c (for unused accounts): | Examine configuration files and interview personnel. | The assessor will: *Review configuration files on sample systems to verify unused vendor default accounts are removed or disabled. *Interview personnel responsible for system configuration to confirm their process for handling unused vendor default accounts. |
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:
Requirement | Actions required | How the assessment is done |
2.2.3.a | Examine system configuration standards. | The assessor will review your documented system configuration standards to verify they address managing primary functions with different security levels according to the three options outlined in the requirement (separate systems, isolation, or the highest security level for all). |
2.2.3.b | Examine system configurations. | The assessor will examine the configuration of sample systems to verify that functions with different security needs are managed according to one of the approved methods outlined in the requirement. |
2.2.3.c (if applicable) | Examine configurations for virtual environments. | For environments utilizing virtualization, the assessor will: *Review configurations to verify functions with different security needs are either segregated on separate virtual components or isolated within the same virtual environment. *Assess the security controls implemented to ensure the higher security needs of certain functions are not compromised by the presence of lower security functions within the same virtual environment. |
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:
Requirement | Actions required | How the assessment is done |
2.2.4.a | Examine system configuration standards. | The assessor will review your documented system configuration standards to verify they identify and document the essential services, protocols, and daemons required for each system component. |
2.2.4.b | Examine system configurations. | The assessor will examine the configurations of sample systems to verify: *All unnecessary functionalities are disabled or removed. *Only the functionalities documented as essential in your configuration standards are enabled. |
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:
Requirement | Actions required | How the assessment is done |
2.2.5.a (if applicable) | Examine standards and interview personnel. | The assessor will: *Review your documented system configuration standards to verify they address managing insecure services, protocols, or daemons. *Interview personnel responsible for system configuration to understand how they handle situations where insecure elements are identified. |
2.2.5.b (if applicable) | Examine configuration settings. | The assessor will examine the configuration settings of systems where insecure services, protocols, or daemons are present to verify: *There is documented business justification for their continued use. *Additional security features are implemented to mitigate the associated risks. |
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:
Requirement | Actions required | How the assessment is done |
2.2.6.a | Examine system configuration standards. | The assessor will review your documented system configuration standards to verify they address configuring system security parameters to prevent misuse. |
2.2.6.b | Interview system administrators and security managers. | The assessor will interview personnel responsible for system configuration and administration to assess their knowledge of common security parameter settings for relevant system components. |
2.2.6.c | Examine system configurations. | The assessor will examine the configurations of sample systems to verify that common security parameters are set appropriately and in accordance with your documented system configuration standards. |
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:
Requirement | Actions required | How the assessment is done |
2.2.7.a | Examine system configuration standards. | The assessor will review your documented system configuration standards to verify they mandate encrypting all non-console administrative access using strong cryptography. |
2.2.7.b (for some systems) | Observe logins and examine configurations. | The assessor will: *Observe an administrator logging on to a system using a non-console method. *Examine configurations related to the observed access method to verify it uses a secure protocol with strong encryption. |
2.2.7.c | Examine settings for insecure services. | The assessor will examine the configurations of system components and authentication services to verify that insecure remote login services (e.g., Telnet) are disabled for non-console administrative access. |
2.2.7.d | Interview personnel and examine documentation. | The assessor will: *Interview personnel responsible for system configuration to understand their implementation of strong cryptography for non-console access. *Review vendor documentation to verify the chosen technology and its configuration align with industry best practices or vendor recommendations for strong cryptography. |
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:
Requirement | Actions required | How the assessment is done |
2.3.1.a | Examine policies and interview personnel. | The assessor will: *Review your documented policies and procedures to verify they address changing or confirming the security of wireless vendor defaults. *Interview personnel responsible for wireless network management to understand their practices regarding vendor defaults. |
2.3.1.b (for some devices) | Examine documentation and observe login. | The assessor will: *Review vendor documentation for the observed wireless devices to identify their default security settings. *Observe a system administrator logging into a wireless device to verify: *SNMP defaults are not being used. *Default passwords on the access point are not being used. |
2.3.1.c | Examine documentation and configurations. | The assessor will: *Review vendor documentation for the wireless equipment to identify other security-related defaults. *Examine wireless network configurations to verify these defaults have been changed if applicable. |
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:
Requirement | Actions required | How the assessment is done |
2.3.2 | Interview personnel and examine documentation. | The assessor will: *Interview personnel responsible for managing wireless networks to understand their key rotation practices. *Review your documented key management procedures and key rotation policy to verify they address the elements of this requirement. |