On March 31, 2022, the Payment Card Industry Security Standards Council (PCI SSC) released the fourth and latest version of the PCI DSS.
For those not already familiar with the PCI DSS standard, it was developed to encourage and enforce the security of cardholder data and broaden the adoption of data security measures at a global scale. PCI DSS provides a detailed baseline of technical and operational requirements designed to guide businesses in protecting account data. While PCI DSS is specifically designed to focus on environments with payment card account data, entities bound by PCI DSS compliance mandates benefit from upholding these standards by increasing the security posture of their entire payment ecosystem by default throughout the compliance process.
The global Payment Card Industry (PCI) standards define specific requirements for the different areas in processing card payments, which are set and agreed upon by stakeholders such as banks, merchants, and payment services providers. The most prominent stakeholders enforcing PCI DSS compliance are major credit card companies that you have undoubtedly heard of before – American Express, Mastercard, Visa, and Discover, which are also the same companies that founded the SSC back in 2006.
All merchants and service providers that store, transmit, or process payment card information are required to be PCI DSS compliant, meaning that any businesses that these descriptions apply to should be on high alert about the changes that will affect them once version 3.2.1 of PCI DSS is retired and replaced by version 4.0.
Organizations with broader payment ecosystems will need to be diligent in reviewing the major updates in PCI DSS 4.0 before it takes effect to allow time to transition and prepare for an audit. Security and risk governance leaders will notice a common theme between PCI DSS 3.2.1 and PCI DSS 4.0 – best practices included in the previous version are now becoming requirements instead, upping the ante for affected parties.
After the PCI SSC released version 4.0 of PCI DSS on March 31, 2022, they soon released their rollout timeline. The PCI SSC is giving merchants a generous transition period to familiarize themselves with the upcoming changes in PCI DSS 4.0. Organizations have plenty of time to review their reporting mechanisms and processes and formulate a plan to align their security practices with the new requirements that will be enforced.
The transition period began the PCI DSS version 4.0 was first released and will end exactly two years from that date on March 31, 2024. After March 31, 2024, PCI DSS 3.2.1 will be retired, and version 4.0 will become the new standard for organizations to follow. Organizations can continue certifying their PCI DSS compliance by adhering to the requirements in version 3.2.1 until it is retired in 2024, but still need to be focused heavily on the future of the standard. Organizations will need to adjust to PCI DSS 4.0 by March 31, 2025, which is the date that they will need to re-certify their compliance by – exactly one year after the new standard officially takes precedence over the retired version.
Penetration testing is one of the many requirements of PCI DSS, as stated in requirement 11.4 of the updated standard. More specifically, requirement 11.4 reads:
“External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.”
The requirements and procedures for running a pci dss penetration testing are outlined in the 4.0 update with guidance for audit readiness. You may be wondering exactly what that entails.
To begin, requirement 11.4 explicitly states that organizations must define, document, and implement a penetration testing methodology that includes:
PCI DSS 4.0 elaborates even further when defining pci pentest, providing guidance of when to perform PCI penetration testing, how often to perform penetration testing, and who must perform the penetration tests. The standard even provides guidance for remediation of PCI penetration testing findings.
Penetration testing for PCI DSS compliance must be performed by one of the following options:
Although it is permitted to have an internal resource perform penetration testing, it can be time consuming and requires a lot of attention – not to mention, it can introduce bias. For smaller businesses and startups especially, allocating an internal resource to penetration testing for PCI DSS compliance is not realistic. Cybersecurity talent is hard to find and working with an external penetration testing provider could save security leaders and their teams an exponential amount of time when preparing for a PCI DSS audit.
The PCI DSS 4.0 even offers guidance for choosing an external third-party to work with for pci pentest in the ‘Good Practices’ section of requirement 11. The PCI SSC recommends searching for a provider with specific penetration testing certifications, which can help validate the tester’s skill level and competence. Some high-value certifications to keep an eye out for when choosing a penetration testing provider are CREST, OSCP, OSCE, CISSP, CEH, and GSNA.
The council also recommends choosing a penetration testing provider with prior experience conducting penetration tests for PCI DSS compliance. When assessing potential vendors, you can make note of the number of years of experience they have, the type and scopes they have handled historically, etc. Confirming that your provider’s experience is appropriate for your needs is essential to meeting PCI DSS compliance seamlessly with the upcoming changes.
Penetration testing must be performed both internally and externally around the cardholder data environment (CDE), including the testing of both applications and networks. To dive a little deeper into exactly what needs to be tested, both inside and outside networks which can either be trusted or untrusted must be tested as well as external-facing and internal-facing web application components that impact the CDE.
Penetration testing must be conducted at least once every 12 months according to requirement 11.4, but also in the event of any significant upgrade or change at the infrastructure or application level. Not only is this a requirement but conducting a penetration testing exercise in the event of any major system changes, updates, or new releases is considered a best practice across the board for all businesses. Incorporating penetration testing into the Software Development Lifecycle (SDLC) can prevent a handful of issues from occurring down the road.
PCI DSS also requires penetration testing to re-test for vulnerabilities found in initial penetration tests to ensure that exploitable risks were remediated properly and are no longer a threat to the CDE.
Like every other requirement that’s a part of the PCI DSS, penetration testing is one of the many measures that organizations are required to implement to ensure that the security posture of their CDE is resilient enough to prevent the comptonization of cardholder data transacted or stored in their systems. Penetration testing gives organizations the opportunity to find and fix cyber breaches before they even happen to meet PCI DSS compliance and improve their overall security posture.
It’s important to note that the penetration testing requirement, aka requirement 11.4, is not synonymous with requirement 11.3, which requires organizations to perform both external and internal vulnerability scans. Requirement 11.3.2 requires entities to have PCI ASV scans performed by a PCI SSC Approved Scanning Vendor (ASV). One key requirement change you’ll notice between PCI DSS 3.2.1 and PCI DSS 4.0 is that version 4.0 requires organizations to conduct authenticated vulnerability scans, while the soon-to-be retired version, 3.2.1, only required unauthenticated scans. Authenticated vulnerability scans are commonly referred to by cybersecurity professionals as “Gray Box” scans while unauthenticated vulnerability scans are commonly referred to as “Black Box” scans. The key difference between authenticated and unauthenticated vulnerability scans is that organizations
must provide authenticated scanning vendors with credentials or a way into their systems, which is not required for unauthenticated/Black Box scans. Depending on the environment being tested, authentication could come in the form of user credentials, deployment of a virtual machine, etc.
There are several changes to consider in this update that will impact compliance requirements.
Organizations can now customize their approach to compliance rather than following specific requirements of the standard. For example, the standard mentions passwords, but an enterprise might want to implement a password-less system that leverages tokens, smart cards, biometrics, encryption keys, or certificates.
Many cyberattacks begin with phishing attempts, which is threatening to both people and technology. PCI DSS 4.0 requires companies to deploy automated email security software to detect and block phishing emails.
As mentioned earlier, internal and external pentesting of the entire CDE is now required. Hence, full-stack penetration testing, including network pentesting and application pentesting, will need scoped appropriately for PCI DSS 4.0 compliance readiness. Any digital environment connected to the CDE, including network, cloud, and hybrid environments, and applications, like APIs and web applications, will need to be included in a PCI DSS 4.0 pentesting engagement.
Security awareness training has shifted from only a best practice to a requirement in PCI DSS 4.0, requiring organizations to review and update security awareness programs at least once annually. PCI DSS is mandating threat awareness training for vulnerabilities that could impact the card data environment and training for acceptable use of end-user technologies.
Since chip technology has become more prevalent in credit cards since the last PCI DSS update, scammers are prevented from using skimmers to steal cardholder data from ATMs. Hackers have re-strategized by stealing credit card data during the transaction itself by injecting malicious code into e-commerce platforms. PCI DSS 4.0 requires companies to conduct weekly checks to confirm that third-party scripts aren’t infected with malicious code.
PCI DSS 4.0 implements increased security requirements for technology in many areas, one being Multi-Factor Authentication (MFA) for all access to credit card data. Previously, the MFA requirement only applied to remote access of credit card data. Version 4.0 also requires the encryption of stored authentication data, which was only a recommendation in 3.2.1. The latest version also requires limiting access limitation controls to the minimum number of personnel required for a specific business process.
Detection mechanisms are required to quickly identify unauthorized alterations to payment processing systems according to PCI DSS 4.0.
Security is increasingly being viewed as the continuous process that it truly is, and not just a one-time activity. This has been codified by 4.0, which calls for targeted risk analysis, vulnerability assessments, and the continuous monitoring of payment processing systems. Version 4.0 requires specific processes for high-risk vulnerability identification and patching and the improvement of incident response and remediation efforts. Detailed guidance on validation and testing procedures is available in PCI DSS 4.0.
Requirement 12.8 PCI DSS 4.0 identifies third-party service providers (TPSPs) as any third party acting as a service provider on behalf of an entity. PCI DSS 4.0 requires entities bound by PCI DSS compliance to do their due diligence in ensuring that their TPSPs that either store, process, transmit account data, or manage in-scope system components on the entity’s behalf at least once every 12 months. Since TPSPs can impact the security of a customer’s CDE, it’s important that they are adhering to PCI DSS third-party security requirements.
If a TPSP has already certified their PCI DSS Compliance or undergone a PCI DSS Attestation of Compliance (AOC), TPSPs are required to provide documentation upon request to demonstrate their compliance with PCI DSS 4.0. Third party service providers can alternatively opt for on-demand, targeted assessments with each of its customers’ assessors to confirm that requirements are met. These assessments are more commonly referred to as vendor assessments in which a customer establishes the terms of a vendor assessment per their organization’s requirements.
Many organizations require their third-party service providers to undergo annual penetration testing exercises as a part of their vendor assessment process to ensure that the vendors that they choose to work with take the security and confidentiality of their data seriously. Requiring vendors to undergo vendor assessments reduces the risk of a data breach being caused by TPSPs, especially when there are integrations connected or a part of the CDE.
BreachLock offers a suite of full stack penetration testing services for comprehensive environments that are ideal for organizations of all sizes that need to prepare to meet the PCI DSS 4.0 standard in 2024. Our team of PCI DSS experts will assist you in scoping the correct pentest engagement for PCI DSS 4.0 compliance, including the required scope for CDE pentesting that has changed from PCI DSS 3.2.1.
As a certified, compliant penetration testing provider and a globally renown leader in offering Pen Testing as a Service (PTaaS), our number one goal is to support strong compliance and security outcomes for our customers.
Ready to learn how BreachLock can help you prepare for this PCI DSS 4.0 update? Schedule a PCI DSS 4.0 discovery call today and prepare for compliance with BreachLock.
-->
