As a continuation to our previous article discussing the impact of pCI 4.0 on Requirement 1, we here below cover Requirement 2.
Overview
Impact of the new PCI 4.0 on the former 3.2.1 requirement 2 are in the form of : Reformulation, Clarification, Amendement and removal.
New controls:
2.1.2 about the roles and responsibilities for this requirement
2.3.2 clarifying when the wireless encryption keys shall be changed.
Amendments:
2.3.1 wireless vendor defaults are changed at installation or are confirmed to be secure
2.2.1 Configuration standards are developed, implemented, and maintained, be updated as new vulnerability issues are identified, be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
Moved:
3.2.1 - 2.4 Maintain an inventory of system components that are in scope for PCI DSS -> 4.0 - 12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
Removed:
3.2.1 - 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
New controls:
2.1.2 about the roles and responsibilities for this requirement
2.3.2 clarifying when the wireless encryption keys shall be changed.
Amendments:
2.3.1 wireless vendor defaults are changed at installation or are confirmed to be secure
2.2.1 Configuration standards are developed, implemented, and maintained, be updated as new vulnerability issues are identified, be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
Moved:
3.2.1 - 2.4 Maintain an inventory of system components that are in scope for PCI DSS -> 4.0 - 12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
Removed:
3.2.1 - 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
Detailed Analysis
Titre
3.2.1 - Do not use vendor-supplied defaults for system passwords and other security parameters
4.0 - Apply Secure Configurations to all system components
3.2.1 - Do not use vendor-supplied defaults for system passwords and other security parameters
4.0 - Apply Secure Configurations to all system components
3.2.1 - 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
Change: Reformulation + Clarification
4.0 - 2.2.2 Vendor default accounts are managed as follows:
• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
• If the vendor default account(s) will not be used, the account is removed or disabled.
Change: Reformulation + Clarification
4.0 - 2.2.2 Vendor default accounts are managed as follows:
• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
• If the vendor default account(s) will not be used, the account is removed or disabled.
3.2.1 - 2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.
Change: Reformulation + Clarification + Amendement
4.0 - 2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:
• Default wireless encryption keys.
• Passwords on wireless access points.
• SNMP defaults.
• Any other security-related wireless vendor defaults.
Change: Reformulation + Clarification + Amendement
4.0 - 2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:
• Default wireless encryption keys.
• Passwords on wireless access points.
• SNMP defaults.
• Any other security-related wireless vendor defaults.
3.2.1 - NONE
Change : New + Clarification
4.0 - 2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows:
• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.
• Whenever a key is suspected of or known to be compromised.
Change : New + Clarification
4.0 - 2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows:
• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.
• Whenever a key is suspected of or known to be compromised.
3.2.1 - 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Change: Reformulation + Amendments
4.0 - 2.2.1 Configuration standards are developed, implemented, and maintained to:
• Cover all system components.
• Address all known security vulnerabilities.
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
• Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
Change: Reformulation + Amendments
4.0 - 2.2.1 Configuration standards are developed, implemented, and maintained to:
• Cover all system components.
• Address all known security vulnerabilities.
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
• Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
3.2.1 - 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Change: Reformulation + Clarification
4.0 - 2.2.3 Primary functions requiring different security levels are managed as follows:
• Only one primary function exists on a system component,
OR
• Primary functions with differing security levels that exist on the same system component are isolated from each other,
OR
• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
Change: Reformulation + Clarification
4.0 - 2.2.3 Primary functions requiring different security levels are managed as follows:
• Only one primary function exists on a system component,
OR
• Primary functions with differing security levels that exist on the same system component are isolated from each other,
OR
• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
3.2.1 - 2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
Change: Reformulation + Removal (due to redundancy)
4.0 - 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
Change: Reformulation + Removal (due to redundancy)
4.0 - 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
3.2.1 - 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Change: Reformulation + Amendement
4.0 - 2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
Change: Reformulation + Amendement
4.0 - 2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
3.2.1 - 2.2.4 Configure system security parameters to prevent misuse.
Change: Reformulation
4.0 - 2.2.6 System security parameters are configured to prevent misuse.
Change: Reformulation
4.0 - 2.2.6 System security parameters are configured to prevent misuse.
3.2.1 - 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
Change: Bundle
2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
Change: Bundle
2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
3.2.1 - 2.3 Encrypt all non-console administrative access using strong cryptography.
Change: Reformulation
4.0 - 2.2.7 All non-console administrative access is encrypted using strong cryptography.
Change: Reformulation
4.0 - 2.2.7 All non-console administrative access is encrypted using strong cryptography.
3.2.1 - 2.4 Maintain an inventory of system components that are in scope for PCI DSS.
Change: Moved to Section 12
12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
Change: Moved to Section 12
12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
3.2.1 - 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.
Change: Reformulation
4.0- 2.1.1 All security policies and operational procedures that are identified in Requirement 2 are:
• Documented.
• Kept up to date.
• In use.
• Known to all affected parties.
Change: Reformulation
4.0- 2.1.1 All security policies and operational procedures that are identified in Requirement 2 are:
• Documented.
• Kept up to date.
• In use.
• Known to all affected parties.
3.2.1 - 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
Change: Removed
Change: Removed
3.2.1 - NONE
Change: NEW
4.0 - 2.1.2 Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.
Change: NEW
4.0 - 2.1.2 Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.
Get your PCI 4.0 COMPLIANCE DASHBOARD TOOL . Fully aligned with PCI DSS V4.0. It includes the defined approach requirements, the customized approach, applicability notes, purpose, good practices & further information, definition, example and defined testing procedures and prioritization approach. It also provides templates to register your compensating controls, controls met with remediations but also to register your customized Controls, the outcome of the customized approach risk assessments and the risk assessments for the definition of frequency periods as well as to register execution of vulnerability scans and penetration tests.
RSS Feed
