PCI DSS 4.0: It’s Time for A Change

Goal:

Apply Secure Configurations to All System Components

What PCI Compliance Requirement 2 Wants From You:

Vendor supplied passwords and settings are well-known and easily determined from public platforms by malicious users who could exist either externally as well as internally within your network. Hence requirement 2 requires that all vendor supplied defaults should either be removed or disabled.

Summary of Changes:

This requirement that earlier focused on vendor supplied defaults has been updated to require all system components to be configured and managed securely.

Diving Deeper:

The key takeaway here is that the emphasis of requirement 2 is now on secure configurations as a whole and not just on vendor supplied defaults. A new requirement has also been added for roles and responsibilities regarding secure configurations. This new requirement (2.1.2) is effective immediately for all PCI 4.0 assessments.

Changes At A Glance:

Goal:

Protect Stored Account Data

What PCI Compliance Requirement 3 Wants from You:

Do not store cardholder data unless absolutely necessary. If it is stored, then protection mechanisms such as encryption, truncation, masking, and hashing should be implemented to protect such critical components in the network so that data is unreadable and unusable if an intruder circumvents all security controls in place and gains access.

Summary of Changes:

The focus of the main requirement changes from protecting cardholder data to protecting stored account data. A few requirements have been newly added to address security practices for Sensitive Authentication Data (SAD) and for Primary Account Number (PAN) where keyed cryptographic hashes and disk-level or partition-level encryption are required to be used to render PAN unreadable.

Diving Deeper:

Several new requirements have been introduced here. Requirement 3.1.2 has been added for roles and responsibilities regarding account data security. This requirement is effective immediately for all v4.0 assessments.

There are also new requirements pertaining to Sensitive Authentication Data (SAD). Requirement 3.2.1 addresses SAD retained before completion of authorization through the implementation of data retention and destruction policies, procedures, and processes. Requirement 3.3.2 requires encryption of SAD that is stored electronically prior to completion of authorization. In the same vein, requirement 3.3.3 (which applies only to Issuers and companies that support issuing services) requires SAD that is stored by issuers to be encrypted using strong cryptography.

A new requirement, number 3.4.2, has been added related to technical controls to prevent coping and/or relocating PAN when using remote access technologies, unless there is explicit authorization for the same. This has been expanded from former requirement number 12.3.10.

Keyed cryptographic hashes must now be used to hash the entire PAN and be accompanied by adequate key management processes and procedures. Additionally, disk-level or partition-level encryption needs to be used only to render the PAN unreadable on removable electronic media, or if used on non-removable electronic media, the PAN should also be rendered unreadable via a mechanism that satisfies Requirement 3.5.1. These two new requirements can be seen as numbers 3.5.1.1 and 3.5.1.2 respectively.

And to wrap up requirement number 3, there is a new requirement that applies only to service providers – requirement number 3.6.1.1 – where service providers need to include a detailed documented description of the cryptographic architecture to prevent the usage of the same cryptographic keys in production and test environments.

Other than requirement 3.1.2, the remaining new requirements that we’ve discussed, under requirement 3, are not effectively immediately. Rather, they’re a best practice until March 31, 2025.

Changes At A Glance:

Goal:

Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

What PCI Compliance Requirement 4 Wants from You:

Sensitive information must be encrypted when transmitting over open or public networks so that it is not easily accessed by malicious users.

Summary of Changes:

The principal requirement has been changed from using encryption to using strong cryptography to protect transmissions of cardholder data. There is a new requirement related to roles and responsibilities and a new requirement that requires confirmation that certificates in use have not expired or have not been revoked. Lastly, an inventory of trusted certificates and keys needs to be maintained.

Diving Deeper:

The changes in requirement 4 are quite straightforward and shouldn’t pose a significant problem for compliance.

Requirement 4.1.2 requires documented roles and responsibilities regarding the transmission of cardholder data. This requirement is effective immediately for all v4.0 assessments.

You must now ensure that certificates used for PAN transmissions over open, public networks are valid and not expired or revoked and you must maintain an inventory of trusted keys and certificates. These have been added as requirements 4.2.1 and 4.2.1.1, however, it’s quite likely that you may have already been doing these things. Both of these requirements are best practices until March 31, 2025.

Changes At A Glance:

Goal:

Protect All Systems and Networks from Malicious Software
What Requirement 5 Wants from You: Antivirus software must be used on all systems commonly affected by malicious software to protect systems from current and evolving malicious software threats.

Summary of Changes:

The principal requirement changes from protecting all systems against malware to protecting all systems and networks from malicious software to include a broader range of technologies. New requirements have been added pertaining to roles and responsibilities, the entity’s risk analysis, the frequency of periodic evaluations of system components that are identified as not at risk for malware, and also the frequency of periodic malware scans. There are new requirements for having malware solutions for removable electronic media and to detect and protect personnel from phishing attacks.

Diving Deeper:

Generally speaking, for requirement 5, the PCI Council has moved toward the phrase “anti-malware” versus “anti-virus.” The intent is to support a broader range of technologies used to meet the security objectives traditionally met by antivirus software.

There are also new requirements that have been introduced. Requirement 5.1.2, for instance, requires documented roles and responsibilities regarding anti-malware technologies in use. This requirement is effective immediately for all v4.0 assessments.

You now need to perform a targeted risk analysis to identify which system components are not at risk for malware (requirement 5.2.3.1) and, as a result of this risk analysis, you need to determine and define the frequency of periodic malware scans (requirement 5.3.2.1). Furthermore, anti-malware scans need to be performed when removable electronic media is in use (requirement 5.3.3). And lastly, you need to instate mechanisms to detect and protect employees from phishing attacks (requirement 5.4.1). These new requirements are best practices until March 31, 2025.

Changes At A Glance:

Goal:

Develop and Maintain Secure Systems and Software

What PCI Compliance Requirement 6 Wants From You:

Security vulnerabilities in systems and software are often used as an entry point to gain privileged access into systems. So, systems and applications should be developed using standard system development processes and secure coding techniques and maintained by applying appropriate security patches to protect against the exploitation and compromise of cardholder data.

Summary of Changes:

The main requirement has been updated from developing and maintaining secure systems and applications to developing and maintaining secure systems and software. New requirements have been added for roles and responsibilities and for maintaining inventories of bespoke and custom software. A new requirement has been added to deploy an automated technical solution that continuously detects and prevents web-based attacks against public facing web applications. Another new requirement has been added to implement processes for managing all payment page scripts that are loaded and executed in consumers’ browser. Other updates relate to structural or format changes or clarification or guidance on earlier requirements.

Diving Deeper:

Requirement 6.1.2, which is effective immediately for all v4.0 assessments, has been added and requires documented roles and responsibilities related to software development.

The remaining new requirements under requirement 6 are best practices until March 31, 2025. These include requirement 6.3.2 that needs you to maintain an inventory of bespoke and custom software to facilitate vulnerability and patch management. Then there’s requirement 6.4.2 which asks you to deploy an automated technical solution for public web applications that continuously detects and prevents web-based attacks. Note that this new requirement removes the option in Requirement 6.4.1 to inspect web applications through manual or automated application vulnerability assessment tools or methods. And lastly, requirement 6.4.3, addresses the management of all checkout (payment) page scripts loaded and executed in the user’s browser.

Changes At A Glance:

Goal:

Restrict Access to System Components and Cardholder Data by Business Need to Know

What PCI Compliance Requirement 7 Wants from You:

Access restrictions based on a need-to-know basis and job roles need to be in place to ensure that critical data can only be accessed by authorized personnel.

Summary of Changes:

The main requirement has been updated from restricting access to “cardholder data” to restricting access to “system components and cardholder data.” New requirements have been added for roles and responsibilities and for review of all system accounts and related access privileges. Requirements related to assignment, management, and review of all application and system accounts and related access privileges have been added as well.

Diving Deeper:

Requirement 7 hasn’t seen too many new additions. The one requirement that is effective immediately for all v4.0 assessments is number 7.1.2 that requires you to document roles and responsibilities regarding managing and reviewing accounts.

If you haven’t already been doing so as part of your ongoing cybersecurity due diligence processes, you need to ensure that you review all user accounts and associated access privileges, as part of the new requirement 7.2.4. Additionally, you need to assign and manage all application and system accounts and related access privileges as part of requirement 7.2.5. You must also ensure that you review all accesses by application and system accounts and related access privileges under requirement 7.2.5.1. These requirements are best practices until March 31, 2025.

Changes At A Glance:

Goal:

Identify Users and Authenticate Access to System Components

What PCI Compliance Requirement 8 Wants from You:

A unique ID needs to be assigned to each person accessing system components to ensure that each individual is accountable for their actions. With accountability in place, a trail of actions performed is created and can be traced to known and authorized users and processes.

Summary of Changes:

A new requirement related to roles and responsibilities is added. Use of shared credentials is allowed but only on an exceptional basis. The number of invalid attempts allowed before locking user account changes from, the earlier, 6 attempts to, the new, 10 attempts. Password strength increases from a minimum length of 7 characters to 12 characters (or 8 characters if the system doesn’t allow 12). An additional option is added for managing passwords/passphrases. They must either be changed at least once every 90 days or have their security posture analyzed dynamically (this applies to service providers as well.) There are new requirements to implement, multi-factor authentication for all access to CDE, secure implementation of multi-factor authentication systems, manage system or application accounts that can be used for interactive login, restrict hard coding of passwords/passphrases into files or scripts that can be used for interactive login, and protection of passwords/passphrases against misuse.

Diving Deeper:

Requirement 8 is going to require significant activity. First, like we’ve seen with many of the other requirement areas, roles and responsibilities must be documented (requirement 8.1.2), effective immediately for all v4.0 assessments.

The Council has introduced a changed focus in requirement 8.2.2 to allow the use of shared authentication credentials, but only on an exception basis. The number of invalid authentication attempts before locking a user ID has been increased from, the previous, six to ten (requirement 8.3.4). A new requirement (8.3.6) has been added to increase password length from, the previous, seven characters to at least twelve characters (or at least eight characters if the system does not support twelve characters). Note that this requirement is not intended to apply to user accounts in point-of-sale terminals that only have access to one card number at a time to facilitate a single transaction.

There is an added option now to automatically determine access to resources by dynamically analyzing the security status of accounts instead of changing passwords at least every 90 days (requirement 8.3.10). Also, a new requirement (8.3.10.1) that only applies to service providers – If passwords are the only authentication factor for customer user access, passwords must be changed at least every 90 days or access must be determined automatically by dynamically analyzing the security status of accounts.

Multi-factor authentication (MFA) finds its way into requirement 8.4.2 and requires MFA to be implemented for all access to the cardholder data environment (CDE). Clarifications were added as well to explain that MFA is required for both types of access specified in requirements 8.4.2 and 8.4.3 and that applying MFA to one access type should not replace the need to use another instance of MFA to the other access type. Requirement 8.5.1 addresses the appropriate implementation of MFA systems.

Lastly, new requirements have been added in relation to interactive logins. Requirement 8.6.1 addresses the management of interactive login accounts used by systems or applications. Requirement 8.6.2 needs you to ensure that passwords are not hardcoded into files or scripts for any application and system account that can be used for interactive login. And requirement 8.6.3 requires the protection of passwords of application and system accounts from misuse.

Apart from 8.1.2, these additional requirements discussed above under requirement 8 are best practices until March 31, 2025.

Changes At A Glance:

Goal:

Restrict Physical Access to Cardholder Data

What PCI Compliance Requirement 9 Wants from You:

Physical access to cardholder data or systems should be appropriately restricted to prevent individuals from accessing these sensitive areas and removing systems or hardcopies of sensitive data.

Summary of Changes:

New requirements are added related to roles and responsibilities. Also, the frequency of periodic POI device inspections must be addressed in the entity’s targeted risk analysis.

Diving Deeper:

Requirement 9 sees only two reasonably simple changes. Requirement 9.1.2 requires documented roles and responsibilities while requirement 9.5.1.2.1 helps define the frequency of periodic POI device inspections based on a targeted risk analysis. The former is effective immediately for all v4.0 assessments while the latter is a best practice until March 31, 2025.

Changes At A Glance:

Goal:

Log and Monitor All Access to System Components and Cardholder Data

What PCI Compliance Requirement 10 Wants from You:

Logging of all network resources and cardholder data environment allows you to track all actions taken in the environment and helps to prevent, detect or minimize the impact of a data compromise. Hence, appropriate logging mechanisms should be implemented and maintained.

Summary of Changes:

New requirements are added related to roles and responsibilities and the use of automated mechanisms to perform audit log reviews. Also, a new requirement requires the frequency of log reviews for all system components to be defined in the entity’s risk analysis. Finally, a new requirement needs processes to be defined and implemented to respond promptly to failures of critical security control systems.

Diving Deeper:

Again, there is a requirement for documented roles and responsibilities, effective immediately for all v4.0 assessments.

A new requirement, number 10.4.1.1, has been added for the use of automated mechanisms to perform audit log reviews. The use of a targeted risk analysis to define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) has been added as part of requirement 10.4.2.1. With a view toward better handling of failures of critical security controls, requirement 10.7.2 requires you to detect, alert, and promptly address critical security control systems failures while requirement 10.7.3 requires you to instantly respond to failures of any critical security control systems. These new requirements have been defined as best practices until March 31, 2025.

Changes At A Glance:

Goal:

Test Security of Systems and Networks Regularly

What PCI Compliance Requirement 11 Wants from You:

System components, processes, and custom software should be tested regularly to ensure security controls continue to reflect a changing environment as vulnerabilities are being discovered continually by malicious individuals and researchers.

Summary of Changes:

Entities are now required to manage all vulnerabilities (not just those ranked as high risk or critical) found during internal vulnerability scans. Also, they must perform internal vulnerability scans via authenticated scanning. Multi-tenant service providers must support their customers for external penetration testing. Also, service providers must now use intrusion-detection and/or intrusion prevention techniques to detect, alert on/prevent, and address covert malware communication. Finally, entities must deploy a change and tamper detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages.

Diving Deeper:

Requirement 11.1.2, effective immediately for all v4.0 assessments, reinforces the documentation of roles and responsibilities.

There is a new requirement (11.3.1.1) to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans while requirement 11.3.1.2 requires you to perform authenticated scanning when performing internal vulnerability scans.

A couple of new requirements that only apply to service providers include requirement 11.4.7 directed at multi-tenant service providers to support their customers for external penetration testing. There is also requirement 11.5.1.1 to use intrusion detection and/or intrusion prevention techniques to detect, warn/prevent and address covert malware communication channels.

Wrapping up requirement 11, there is a new requirement (11.6.1) for the deployment of a change and tamper detection mechanism to warn of unauthorized changes to HTTP headers and the contents of payment pages as received by the user browser.

The new requirements have been defined as best practices until March 31, 2025.

Changes At A Glance:

Goal:

Support Information Security with Organizational Policies and Programs

What PCI Compliance Requirement 12 Wants from You:

Maintain a strong security policy that sets the tone for the whole entity and informs personnel of what is expected from them.

Summary of Changes:

Requirement 12 is the one that experiences the most significant number of changes. Organization-wide risk assessment is replaced with specific targeted risk analysis, which means you’ll have more flexibility in how you scope the assessment, how often you perform it, and the approach you use based on the specific technical and operational infrastructure that you have at your organization. Most of the other new requirements specify periodic reviews and documentation of various security controls and processes, as set out in detail below.

Diving Deeper:

The requirement for a formal organization-wide risk assessment has been removed and instead replaced with specific targeted risk analyses (requirements 12.3.1 and 12.3.2). Additionally, formal acknowledgment by personnel of their responsibilities has been added in as part of requirement 12.1.3. The targeted risk analysis for any PCI DSS requirement (as part of 12.3.1) will provide flexibility in execution frequency while 12.3.2 will ensure that the targeted risk analysis for each PCI DSS requirement is met with a customized approach.

There is a new requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months as part of requirement 12.3.3. Hardware and software technologies should also be reviewed at least once every 12 months (requirement 12.3.4). One other annual checklist item for you to add is to document and certify PCI DSS scope at least once every 12 months and anytime the in-scope environment changes significantly (requirement 12.5.2).

Service providers have an added new requirement to document and certify PCI DSS scope at least every six months and whenever there is a significant change in the in-scope environment (12.5.2.1). In addition, there is requirement 12.5.3 for a documented review of the impact of PCI DSS scope and applicability of controls whenever there is a significant change in organizational structure. There’s also requirement 12.9.2 which only applies to service providers wherein they need to support their customer’s information requests to meet requirements 12.8.4 and 12.8.5.

Your security awareness programs now need to be reviewed at least every 12 months and updated, if necessary, as part of requirement 12.6.2. Furthermore, requirement 12.6.3.1, also related to security awareness training, includes awareness of threats and vulnerabilities that may affect the security of the CDE. Under the added requirement number 12.6.3.2, security awareness training now also needs to include awareness of acceptable use of end-user technologies by requirement 12.2.1.

• You need to now perform a targeted risk analysis to define the frequency of periodic training for incident response personnel as part of requirement 12.10.4.1. Requirement 12.10.5 brings in a few changes – as part of your incident response plan and across PCI DSS requirements, you now need to track and monitor the following security monitoring systems:
  Detection of unauthorized wireless access points (previously 11.1.2).
  Change detection mechanism for critical files (previously 11.5.1).
  New requirement clause for using a change and tamper detection mechanism for checkout pages (new requirement relates to 11.6.1).
  Lastly, the Council has added in requirement 12.10.7 to implement and initiate incident response procedures upon detecting PAN hiding in an unexpected location.

Requirements 12.3.2, 12.5.2, and 12.9.2 are effective immediately for all v4.0 assessments while the rest are best practices until March 31, 2025.

Changes At A Glance: