Transition to a Safer Card Industry with PCI DSS v4.0 – A Summary Report by Payatu

On its journey to actively updating compliance standards to tackle modern-day cyber security threats to the Payment Card Industry, the PCI SSC (Payment Card Industry Security Standards Council) has updated to a new version of PCI DSS (Payment Card Industry Data Security Standards) PCI DSS v4.0 from PCI DSS v3.2.1.

The transition period from PCI DSS v3.2.1 to v4 is defined as 18 months from Q2 of 2022, whereas PCI DSS v3.2.1 will be retiring in Q1 of 2024. The implementation of future-dated new requirements updated in v4 is to be done between Q2-2022 and Q1-2025.

In this blog, we bring to you a simplified understanding of the major and minor changes in the standards that should be placed to defend against cyber-crime syndicates and skimming techniques used by them to steal personal data from websites. The complete details of Requirements and Testing Procedures are available at – https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0.pdf

Summary of updates in v4:

Changes to the Introductory Sections of the Standards Document

1. In the introductory overview of PCI DSS, it has been clarified that these standards do not supersede country, state, or local authorities. In addition to this, an expanded resource list is also shared to assist the organizations in assessing and validating their security postures.
2. Moving on to PCI DSS applicability information, it is clarified that some of the requirements of the PCI DSS are applicable not only to entities that store, process, or transmit account data, but also applicable to some entities that do not store or process such data. For example, third parties that process cardholder data should also follow PCI DSS. Differentiation of sensitive and non-sensitive account data and definitions of various standard terms are added.
3. PA DSS (Payment Application Data Security Standard) & SSF (Software Security Framework) that defines Secure Software standards and SSLC (Secure Software Lifecycle) and their relationship with PCI DSS is defined. Validated software and Validated software vendors, or software that are used to store, process, or transmit account data, by themselves do not make an entity PCI DSS compliant, its assessment includes verification that the software is properly configured and implemented securely. In addition to this, a special note is highlighted to inform users that PA-DSS will be retiring this October, i.e., October 2022.
4. Defining the scope of PCI DSS requirements, the council states that these requirements may apply to CDE (Cardholder Data Environment) inclusive of:
   • People, processes, technologies/system components that are used to store, process, or transmit account data.
   • System components that do not hold such data but have direct access or connectivity to systems that hold such data.

   System components include network devices, servers, computing devices, security devices such as SIEM (Security Information and Event Management), access control servers, physical security systems, and MFA (Multi-Factor Authentication). Virtual and cloud components are a new addition to system components.

5. Next section of the introductory section gives a detailed understanding of the best practices in BAU processes, including but not limited to creating a separate PCI DSS check team, reviewing logged data and implementing efficient BCP (Business Continuity Plan) to counter security control failures.
6. An important highlight for assessors of PCI DSS requirements shared states that in a largely populated environment where large quantities of similar items are to be tested, an assessor can pick data on sample basis and test it as part of its PCI DSS compliance review. However, the opposite is not permitted, i.e., an entity presenting only sample data of its environment to the assessor is not acceptable.
7. The contents 7 through 14 of the introductory section are defining timeframes, different approaches to implementing and validating PCI DSS and versions.
8. The next section of the introductory section contains detailed PCI DSS Requirements and Security Assessment Procedures.

Changes in Requirements of PCI DSS:

A major revamp is done in terms of Requirements and Testing Procedures, most of which are aimed at creating a clear picture about roles and responsibilities by documentation of all the roles. Almost every requirement (except requirement 1 & 12) has updated policies for role and responsibilities. Below shared details contain major updates that tackle security problems such as credit card skimming.

1. Under Requirement 3.2.1, data retention/storage policy for any Sensitive Authentication Data (SADs) stored prior to completion of authorization should be implemented and examined. Requirement 3.3.2 suggests that SAD, stored electronically should be encrypted prior to completion of authorization using strong cryptography.
2. Requirement 4, 4.2.1 & 4.2.2 suggest that strong encryption and protocols should be implemented to safeguard PAN (Permanent Account Number) during transmission of data over open, public networks, that the certificates used for such transmissions should be valid, not expired or revoked and an inventory of such trusted keys and certificates should be maintained to verify whether they are up to date or not.
3. Under Requirement 5, the focus is on security posture against incoming malware, their identification, and defensive policies. Requirement 5.2.3.1 discusses defining frequency of periodic evaluations of system components that are identified as “not at risk” for malware.

Requirement 5.3.2.1 states that scanning by malware solutions should be performed at a frequency such that its risk is addressed. Requirement 5.3.3 specifies that malware solutions should be implemented to detect any malicious activity that occurs on mounting of removable media. Last but a very important addition to Requirement 5.4.1 states that processes and mechanisms should be set up to detect and defend personnel against phishing attacks.

1. Requirement 6 defines the development and maintenance of Secure Systems and Software. Requirement 6.3.2 upholds the policy of maintaining an inventory of bespoke/custom software and third-party components that are used in the organization to facilitate vulnerability and patch management status. Solutions to detect and prevent attacks on public-facing web applications in real-time, should only be done via an automated technical solution and not via a manual process.

Straight out of the basic principles of information security, Requirement 6.4.3 states that all payment page scripts that are loaded and executed in the customers’ browser should have methods implemented to confirm that each script is authorized, and the integrity of each script is intact, also an inventory at the organizations’ end should be placed which has clear justification as to why it is necessary in order to address any issues towards the privacy of the customer due to the scripts. These scripts will prove especially useful as a defensive technique to safeguard customers from skimming techniques performed by attackers.

1. Updated policies regarding Access Control to Customer data and System components that hold such data are defined in Requirement 7, with 7.2.4 adding to the list a periodic review of all user accounts that have access to customer data or system components that hold such data, including third-party vendors accounts. Ideally, it should be reviewed every six months and any nonconformities/actions by user accounts are addressed and remediated.

Requirement 7.2.5 states that all user accounts should be assigned privileges based on minimal privilege requirements with which operability can be managed. Similarly, Requirements 7.2.4 & 7.2.5.1 also require periodic review of all system components and user accounts that handle customer data.

1. Requirement 8 is a complete guide to identification and authentication access of users to System components that store or process customer data and has major changes in the requirements. Apart from updating roles and responsibilities under Requirement 8.1.2, Requirement 8.3.6 requires environments to have strong passwords/passphrases to be used as authentication factors and the minimum level of complexity required is:
   • Password length of 12 characters, and if a system does not support 12 characters, 8 characters.
   • Should contain both numeric and alphabetic characters.

   Additional requirement from v3.2.1 to v4.0 that is specific to service providers in the environment is that, in an environment where only single factor authentication is implemented, guidance to change of password/passphrase periodically and specification of circumstances under which they should be changed must be given.

   Requirement 8.4.2 – requirement of Multi-Factor Authentication (MFA) at all access into Cardholder Data Environment (CDE).

   Requirement 8.5.1 – MFA should not be susceptible to replay attacks, should not be bypassed by any users unless specifically documented with prior approval from management for a limited time.

   Requirement 8.6.1 – Any Interactive login accounts for Systems and applications, ideally prevented to be used, should justify business requirements if created, with explicit approval and accounts should be identified with individual users who shall be responsible for every action taken, authorized for the account to take.

   Requirement 8.6.2 – Passwords and passphrases for such accounts are not to be hard-coded into any scripts, property files, and custom source code.

   Requirement 8.6.3 – Passwords/passphrases must be created with sufficient complexity levels to resist any brute-force and guessing attacks and must be changed periodically as per an entity’s targeted risk analysis.

2. Requirement 9 calls for Restricting Physical Access to cardholders’ data a new addition 9.5.1.2.1 focuses on POI devices (Point of Interaction; devices which capture payment card data via direct physical interaction with the payment card form factor) and their periodic inspections and these inspection types must be defined on the basis of Risk analysis performed for that entity.
3. Logging and Monitoring of access to a particular system helps us identify real time activities and retrace any malicious activity that might have occurred. Requirement 10 of PCI DSS discusses all about logging and monitoring of all access types to system components that hold or process Card data. A couple of new additions apart from updated roles and responsibilities are Requirements 10.7.2 & 10.7.3, which state that, in case of failure of system components require immediate detection, alerting and to be addressed for security controls placed in the environment such as network security controls, IDS/IPS, anti-malware solutions, audit logging and automated security testing tools among others and discuss actionable and responding to such failures and restoring security functions, identifying and documenting time specific details of such cases respectively.
4. Focusing on Red Teaming and Penetration Testing of Systems and Network (which is Payatu’s forte), Requirement 11 has some new additions.Requirement 11.3.1.1– Apart from high-risk and critical vulnerabilities which have been discussed in 11.3.1, all other vulnerabilities are to be ranked and addressed as per risk analysis of the entity and rescanning must be done if required.

   Requirement 11.3.1.2– Internal vulnerability scans that are performed via authenticated scanning should have documentation of all unsuccessful attempts; proper privileges must be provided to such tools that perform scanning.

   Requirement 11.4.7 – Applicable to multi-tenant service provider with other clients also, such providers must present evidence that penetration testing of their infrastructure has been performed and prompt access for their clients to perform testing.

   Requirement 11.5.1.1 – A new requirement for service providers only, to use security controls such as Intrusion Detection/Prevention techniques to detect, alert and prevent intrusion attempts and address covert malware communication channels from their infrastructure.

   Requirement 11.6.1 – Usage of a change and tamper detection mechanism that can identify any changes in the HTTP headers or content of payment pages, and that for evaluating received HTTP headers on a periodic basis or every 7 days.

5. Requirement 12 discusses supporting information security with organizational policies and programs. This requirement acts as a support for all other requirements, wherein periodic analysis of policies is required. Major changes are seen in this requirement, where many new additions are made.Requirement 12.3.1– New addition with a clarified understanding of what must all be included and documented in an Entity Targeted Analysis. Assets that are being protected, threats against which requirement is protecting an entity, and factors that contribute to the likelihood of a threat being realized, must be identified. The Resulting Analysis must include how frequently the requirement must be tested to minimize the risk of threats and suggest that a review of each targeted risk analysis should be done every 12 months.

   Requirement 12.3.2– reiterates details from 12.3.1, but applicable for entities using a customized approach. In addition, a documented approval of customized approach must be present as evidence for senior management.

   Requirement 12.3.3– All cryptographic suites and protocols must be documented in an inventory list and reviewed every 12 months clarifying use, including purpose and where it is used. Annual reviews must also monitor industry trends that are applicable and must be updated as needed. Any vulnerabilities identified in such cryptographic suites and protocols; responses strategized for such cases must also be documented to examine the status of all cryptographic suites and protocols.

   Requirement 12.3.4– Hardware and software technologies used must be reviewed every 12 months, analysis of security fixes from vendors, “end of life plans”, remediation of such end-of-life plans approved by senior management must be documented.

   Requirement 12.5.2– Document and confirm scope every 12 months or when there is a significant change to the in-scope environment. Also, a detailed list of validation scope is shared, that roughly includes identifying and confirming data flows, account data, system components, segmentation controls and connections, within Cardholder Defined Environment and third-party entities.

   Requirement 12.5.2.1– Reiterates details from 12.5.2 but is applicable for service providers only and is reviewed every 6 months.

   Requirement 12.5.3– any major changes in the organizational structure that impact PCI DSS scope and applicability of controls must be documented and results must be shared with executive management for service providers only.

   Requirement 12.6.2– Security awareness programs must be reviewed and updated periodically (at least every 12 months).

   Requirement 12.6.3.1– Personnel to receive information security awareness training every 12 months via multiple modes of communications, such as periodic awareness mails, social engineering activities, internal phishing campaigns due to increasing social engineering attacks on non-technical personnel to leverage their access for compromising infrastructures.

   Requirement 12.6.3.2– Security awareness training must include awareness about acceptable use of end-user technologies.

   Requirement 12.9.2– An additional requirement for Third Party Service Providers (TPSP), stating that TPSPs (Third Party Service Providers) must communicate PCI DSS compliance status for any service the TPSP performs on behalf of customers, and document responsibilities of TPSPs, customer and their shared responsibilities.

   Requirement 12.10.4.1– Incident Response personnel must receive periodic training which is defined as per entity’s targeted risk analysis.

   Requirement 12.10.7– Incident Response procedures to be in place upon detection of stored PAN anywhere it is not expected and remediating data leaks or process gaps that resulted in sensitive data to be where it was not expected.

6. Appendices defined after the requirements focus on additional requirements based on the type of entity. New Appendices E, F, G added which assist environments using customized approach and glossary of terms used in PCI DSS. Updates in Appendix A1, A2, A3 shared below:Appendix A1: for multi-tenant service providers
   • A.1.1.1 focuses on logical separation between providers environment and customer’s environment
   • Pentest all logical separations and their efficiency
   • Reporting mechanisms addressing suspected or confirmed security incidents and vulnerabilities.

   Appendix A2: for entities using SSL/early TLS for card present POS POI Terminal Connections

   • No major changes

   Appendix A3: Designated Entities Supplemental Validation

   • In case of failures of automated log review mechanisms and automated code review tools, detection, and reporting of such failures.

Conclusion:

As we conclude this report, it would be right to say that PCI SSC has updated the version keeping in mind the more recent threat vectors that we are observing against organizations and especially the financial sector. Supply-Chain attacks via third party service providers, social engineering and phishing attacks, browser-based attacks on customers by compromising integrity of scripts and web applications, all such vectors and defensive measures against them updated in PCI DSS v4.0 will hopefully protect cardholder data in such environments.

References:

https://blog.pcisecuritystandards.org/updated-pci-dss-v4.0-timeline

https://www.pcisecuritystandards.org/documents/PCI-DSS-Summary-of-Changes-v3_2_1-to-v4_0.pdf