‍PCI DSS v4 Top Changes & Best Practices

Compliance
/
September 16, 2024
/
6 min read

‍PCI DSS v4 Top Changes & Best Practices

The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 represents a significant update aimed at enhancing the security of payment card data. This new version introduces numerous changes and best practices that organizations must adopt to remain compliant. Below, we explore 5 key changes and recommended practices under PCI DSS 4.0.

1. Copying of PANs

Requirement 3.4.2:

Only personnel with a business need can copy PANs via remote technologies.

Purpose: 

Requirement avoids that PANs are copied by unauthorized persons to local storage devices. Formerly only policy required, now technical controls to prevent copying

of PANs are required together with a list of authorized personnel.

Good Practice / Implementation:

• Restrict access to (full) PANs

• Use clients without local storage devices (e. g. Thin Clients)

• Disable / block copy protocols (e. g. SCP, SFTP)

• Disable Clipboard

2. Keyed Cryptographic Hashes

Requirement 3.5.1.1:

Hashes used to render PANs unreadable are keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures.

Purpose: 

Requirement avoids that PAN hashes are broken by brute forcing attacks and rainbow tables.

Good Practice / Implementation:

Usage of keyed cryptographic hashing functions (e. g. HMAC, CMAC, GMAC).

3. Disk or Partition Level Encryption

Requirement 3.5.1.2:

Risk or partition level encryption for PANs is only allowed to be used on removable electronical media.

Purpose:

Requirement avoids that only one disk-level key is used to protect several PANs in running systems. An additional data-level encryption is required.

Good Practice / Implementation:

• File-level encryption (encrypts a complete file).

• Database encryption (Column-level encryption and field-level encryption).

4. Avoiding Web Skimming Attacks

Requirement 6.4.3:

All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:

• A method is implemented to confirm that each script is authorized.

• A method is implemented to assure the integrity of each script.

• An inventory of all scripts is maintained with written justification as to why each is necessary.

Purpose:

Requirement reduces the probability that web skimming scripts are included in the payment page to exfiltrate cardholder data (PANs) by attackers from the consumer browser.

Good Practice / Implementation:

• Script Inventory: Create inventory with necessary scripts needed for functionality - remove not needed scripts.

• Script Authorization: Include authorization process (manual or automated) into the development process.

• Script Integrity: Subresource Integrity (SRI), Content Security Policy (CSP).

Requirement 11.6.1:

A change- and tamper-detection mechanism is deployed to detect changes to the HTTP headers, and the contents of the payment page weekly or based on risk analysis.

Purpose:

Detection of changes or indicators of malicious activity in the consumer browser to prevent web skimming attacks

Good Practice / Implementation:

• Violations of CSP ⤑ report them using report-to or report-uri feature to the entity.

• Synthetic user monitoring ⤑ external monitoring system which analyses the received web pages.

• Tamper-resistant, tamper-detection script.

• Reverse proxies and Content Delivery Networks to detect changes in scripts.

5. Handling of Application and System Accounts

Requirement 8.6.1:

Interactive use of system and application accounts is prevented unless needed for exceptional circumstance:

• Limited to the time needed

• Business justification is obtained

• Usage is approved by management

• User identity is confirmed

• Every action is traceable to the user

Purpose:

System and application accounts have elevated privileges to perform tasks. They are lucrative accounts for being compromised by attackers.

Good Practice / Implementation:

Disallow / Disable interactive login to system and application accounts. Limit the machines and devices on which the account can be used.

Requirement 8.6.2:

Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration files or source code.

Purpose:

Not properly protected passwords/passphrases of application and system accounts, increase the risk of unauthorized use of those privileged accounts by attackers.

Good Practice / Implementation:

Use password vaults or system managed controls.

Requirement 8.6.3:

System and application account passwords are changed periodically and constructed with sufficient complexity based on risk analysis.

Purpose:

Not properly protected passwords/passphrases of application and system accounts, increase the risk of unauthorized use oft hose privileged accounts by attackers.

Good Practice / Implementation:

• Correlate change frequency with selected complexity.

• Infrequently changed (higher complexity): 36 alphanumeric characters with upper- and lower- case letters, and special characters.

• More frequently changed (lower complexity): At least once a year, 15 alphanumeric characters, with upper- and lower-case letters, and special characters.

Conclusion

PCI DSS version 4 represents a comprehensive update to the security standards that protect payment card data. By understanding the different levels and associated requirements, merchants and service providers can better prepare for compliance, ensuring the protection of sensitive data against evolving cyber threats. As the deadline for compliance approaches, businesses must assess their current security measures and make necessary adjustments to meet the new standards.

Want to learn more?

Fill out the form below and a member of our team will be in touch.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

This is some text inside of a div block.
  Copied to clipboard