In our last discussion, we explored the evolution of Requirement 1 in the transition from PCI DSS v3.2.1 to v4.0, with a particular emphasis on the move towards ‘network security controls’. As we continue our exploration of the updated PCI DSS v4.0, today’s focus will be on the transformations in Requirement 2.
As a reminder, the Payment Card Industry Data Security Standard (PCI DSS) is a comprehensive set of security requirements that all organizations handling cardholder data must adhere to. These requirements’ main objective is to safeguard sensitive cardholder information and mitigate data breaches.
With the impending retirement of PCI DSS v3.2.1 on March 31st, 2024, it becomes imperative for organizations to familiarize themselves with and adhere to the enhanced PCI DSS v4.0. So, without further ado, let’s delve into the modifications introduced in Requirement 2 from v3.2.1 to v4.0.So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”
Modification to Requirement 2 from PCI DSS v3.2.1 to PCI DSS v4.0:
Requirement 2 in PCI DSS v4.0 has undergone a notable revision in its core requirement title. The focus has now transitioned towards ‘secure configurations’, deviating from the earlier concentration on vendor-supplied defaults. This modification mirrors the dynamic nature of data security, where a universal solution is no longer viable. Instead, organizations are now urged to establish and implement secure configurations that are uniquely suited to their specific needs.
The updated Requirement 2 mandates that organizations: “Apply Secure Configurations to All System Components.” This wide-ranging directive covers all system components within an organization, underscoring the necessity for a holistic and customized approach to data security.
This transition towards secure configurations is in line with the changes we examined in Requirement 1, where the spotlight was shifted from traditional ‘firewalls’ and ‘routers’ to ‘network security controls.’ Collectively, these modifications highlight the PCI Security Standards Council’s dedication to staying abreast of emerging threats and technologies.
| PCI DSS v3.2.1 | PCI DSS v4.0 | |
|---|---|---|
| Requirement and Testing Procedures | Section 2.1: Changing Defaults and Removing Unnecessary Accounts Before installing a system on the network, it’s crucial to change all vendor-supplied defaults and disable or remove any unnecessary default accounts. This applies to all default passwords, including those used by operating systems, security software, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) community strings, among others. • 2.1.a: Select a sample of system components. With the assistance of a system administrator, try to log into the devices and applications using the default vendor-supplied accounts and passwords. The goal is to confirm that all default passwords have been changed. This includes passwords on operating systems, security software, application and system accounts, POS terminals, and SNMP community strings. Vendor manuals and online sources can be used to find vendor-supplied accounts and passwords. •2.1.b: For the chosen sample of system components, verify that all unnecessary default accounts have been removed or disabled. This includes accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, and so on. • 2.1.c: Conduct interviews with personnel and review supporting documentation to confirm the following: - All vendor defaults, including default passwords on operating systems, security software, application and system accounts, POS terminals, SNMP community strings, and so on, are changed before a system is installed on the network. - Unnecessary default accounts, including those used by operating systems, security software, applications, systems, POS terminals, SNMP, and so on, are removed or disabled before a system is installed on the network. | Section 2.2.2: Management of Vendor Default Accounts Vendor default accounts are managed in the following ways: - If the vendor default account(s) will be used, the default password is changed as per Requirement 8.3.6. - If the vendor default account(s) will not be used, the account is removed or disabled. • 2.2.2.a: Review the system configuration standards to ensure they include the management of vendor default accounts in accordance with all elements specified in this requirement. • 2.2.2.b: Examine the vendor documentation and observe a system administrator logging on using vendor default accounts. This is to verify that accounts are implemented in accordance with all elements specified in this requirement. • 2.2.2.c: Review the configuration files and conduct interviews with personnel to confirm that all vendor default accounts that will not be used are removed or disabled. |
| Requirement and Testing Procedures | 2.2.1 The principle here is to assign only a single primary function to each server. This is done to avoid the coexistence of functions that demand different security levels on the same server. For instance, web servers, database servers, and DNS should each be implemented on their own separate servers. • 2.2.1.a Choose a sample of system components. Then, examine the configurations of these systems to confirm that each server is dedicated to just one primary function. • 2.2.1.b In cases where virtualization technologies are employed, scrutinize the configurations of the system to ensure that each virtual system component or device is assigned only one primary function. This ensures that even in a virtualized environment, each function is isolated in its own virtual system component or device. | 2.2.3 The management of primary functions that require different security levels is handled in one of the following ways: - A system component contains only a single primary function, OR, - If primary functions with varying security levels exist on the same system component, they are isolated from each other, OR, - If primary functions with varying security levels exist on the same system component, they are all secured to the level required by the function with the highest security need. • 2.2.3.a Inspect the standards for system configuration to confirm that they include the management of primary functions that require different security levels, as specified in this requirement. • 2.2.3.b Examine the configurations of the system to verify that primary functions requiring different security levels are managed in one of the ways specified in this requirement. • 2.2.3.c If virtualization technologies are in use, review the configurations of the system to ensure that system functions requiring different security levels are managed in one of the following ways: o Functions with differing security needs do not coexist on the same system component. o Functions with differing security needs that exist on the same system component are isolated from each other. o Functions with differing security needs on the same system component are all secured to the level required by the function with the highest security need. |
| Requirement and Testing Procedures | 2.2.2 The guideline here is to activate only those services, protocols, daemons, etc., that are essential for the system’s function. • 2.2.2.a Choose a sample of system components. Inspect the enabled system services, daemons, and protocols on these components to ensure that only necessary services or protocols are activated. • 2.2.2.b Identify any insecure services, daemons, or protocols that are enabled. Interview relevant personnel to confirm that these are justified as per the documented configuration standards. 2.2.5 The directive is to eliminate all superfluous functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. • 2.2.5.a Select a sample of system components. Inspect their configurations to ensure that all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, etc., has been removed. • 2.2.5.b Review the documentation and security parameters to confirm that the enabled functions are documented and support a secure configuration. • 2.2.5.c Examine the documentation and security parameters to ensure that only the functionality documented is present on the sampled system components. This helps maintain a clean and secure system environment. | 2.2.4 Ensure only essential services, protocols, daemons, and functions are active, and disable or remove all non-essential ones. • 2.2.4.a Check system configuration standards to confirm that necessary services, protocols, and daemons are identified and recorded. • 2.2.4.b Review system configurations to ensure: - All non-essential functionality is disabled or removed. - Only the functionality required and documented in the configuration standards is active. |
| Requirement and Testing Procedures | 2.2.3 Enforce the application of extra security measures for any necessary services, protocols, or daemons that are deemed to be insecure. • Carry out an inspection of the configuration settings to ensure that security features have been properly documented and implemented for all services, daemons, or protocols that are identified as insecure. | 2.2.5 In the event of any insecure services, protocols, or daemons being present: - A business justification is documented. - Additional security measures are documented and put into effect that mitigate the risk of using insecure services, protocols, or daemons. • 2.2.5.a If any insecure services, protocols, or daemons are present, review the system configuration standards and conduct interviews with personnel to ensure they are managed and implemented in line with all the elements specified in this requirement. • 2.2.5.b If any insecure services, protocols, or daemons are present, inspect the configuration settings to confirm that additional security measures are in place to reduce the risk of using insecure services, daemons, and protocols. |
| Requirement and Testing Procedures | 2.1.1 For wireless environments that are connected to the cardholder data environment or that transmit cardholder data, ensure that ALL wireless vendor defaults are altered at the time of installation. This includes, but is not limited to, default wireless encryption keys, passwords, and SNMP community strings. • 2.1.1.a Conduct interviews with the responsible personnel and review the supporting documentation to confirm that: -> The encryption keys were altered from their default settings at the time of installation. -> The encryption keys are changed whenever anyone with knowledge of the keys leaves the company or changes their position. • 2.1.1.b Interview the personnel and review the policies and procedures to confirm that: -> The default SNMP community strings are required to be changed upon installation. -> The default passwords/passphrases on access points are required to be changed upon installation. • 2.1.1.c Review the vendor documentation and log into the wireless devices, with the assistance of the system administrator, to confirm that: -> The default SNMP community strings are not in use. -> The default passwords/passphrases on access points are not in use. • 2.1.1.d Review the vendor documentation and observe the wireless configuration settings to confirm that the firmware on wireless devices is updated to support strong encryption for: -> Authentication over wireless networks. -> Transmission over wireless networks. • 2.1.1.e Review the vendor documentation and observe the wireless configuration settings to confirm that other security-related wireless vendor defaults were changed, if applicable. | 2.3.1 For wireless environments that are connected to the CDE or that transmit account data, ensure that all wireless vendor defaults are either altered at the time of installation or confirmed to be secure. This includes, but is not limited to: -> Default wireless encryption keys. -> Passwords on wireless access points. -> SNMP defaults. -> Any other security-related wireless vendor defaults. • 2.3.1.a Review the policies and procedures and conduct interviews with responsible personnel to confirm that processes are in place to either change wireless vendor defaults upon installation or to confirm them to be secure, in accordance with all elements of this requirement. • 2.3.1.b Review the vendor documentation and observe a system administrator logging into wireless devices to confirm that: -> SNMP defaults are not in use. -> Default passwords/passphrases on wireless access points are not in use. • 2.3.1.c Review the vendor documentation and wireless configuration settings to confirm that other security-related wireless vendor defaults were changed, if applicable. 2.3.2 For wireless environments that are connected to the CDE or that transmit account data, ensure that wireless encryption keys are changed under the following circumstances: -> Whenever personnel with knowledge of the key leave the company or change roles. -> Whenever a key is suspected of or known to be compromised. • Conduct interviews with responsible personnel and review the key-management documentation to confirm that wireless encryption keys are changed in accordance with all elements specified in this requirement. |
| Requirement and Testing Procedures | 2.4 Ensure the maintenance of an inventory of system components that fall within the scope of PCI DSS. • 2.4.a Conduct a review of the system inventory to confirm that a list of hardware and software components is maintained and that it includes a description of the function or use for each component. • 2.4.b Carry out interviews with personnel to confirm that the documented inventory is regularly updated and kept current. | 12.5.1 Maintain an inventory of system components that are within the scope for PCI DSS, ensuring it includes a description of function or use and is regularly updated. • 12.5.1.a Review the inventory to confirm that it includes all system components within the scope of PCI DSS and a description of the function or use for each component. • 12.5.1.b Conduct interviews with personnel to confirm that the inventory is regularly updated and kept current. |
Also Read:- PCI DSS Requirement 1 – Changes from v3.2.1 to v4.0 Explained
New Requirement 2.1.2: A new requirement, 2.1.2, has been introduced, emphasizing the importance of clearly defining and understanding roles and responsibilities. The roles and responsibilities associated with Requirement 2 must be documented, assigned, and understood by all relevant personnel.
Testing Procedures:
2.1.2.a: Review the documentation to ensure that the roles and responsibilities for activities in Requirement 2 are properly documented and assigned.
2.1.2.b: Conduct interviews with personnel responsible for activities in Requirement 2 to confirm that roles and responsibilities are assigned as documented and are understood.
Purpose: The formal assignment of roles and responsibilities is crucial. Without it, personnel may not be aware of their daily responsibilities, and critical activities may not be carried out.
Good Practice: Roles and responsibilities can be documented within policies and procedures or maintained within separate documents. As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.
Examples: One method to document roles and responsibilities is a responsibility assignment matrix, also known as a RACI matrix, which includes who is responsible, accountable, consulted, and informed.
Note on Requirement 2.6: Please note that Requirement 2.6 has been removed from v3.2.1. This was a ‘null’ requirement, meaning all its content pointed to other requirements. Therefore, it was deemed redundant and has been eliminated for clarity and efficiency.
You can also watch the video on PCI DSS Requirement 2:
Also Read : PCI DSS Requirement 3
Conclusion:
We trust that you now have a detailed grasp of the modifications in the requirements. For any questions, we suggest referring to the official PCI DSS website for a more exhaustive comprehension. At VISTA InfoSec, our aim is to add value by undertaking meticulous research and smoothly integrating these alterations. More insights into these requirement changes can be found in the sections that follow. We also encourage you to check out our previous and upcoming blogs on the changes in requirements from v3.2.1 to v4.0 in PCI DSS. We appreciate your time spent reading this. Thank you.
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
