In the ever-evolving landscape of cybersecurity, organizations are constantly challenged to protect their sensitive data. The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 is the latest iteration of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment.

One of the approaches that can significantly help organizations in meeting these new requirements is the implementation of a continuous offensive security strategy. This approach involves year-round testing of technologies and systems to find and address gaps in technology sprawl, asset identification, and attack path validation.

Prioritize Security as a Continuous Process

Step eight of the PCI DSS v4.0 transition plan emphasizes the importance of treating security as a continuous process. It encourages organizations to view the protection of payment data as an ongoing effort rather than a one-time event. The flexibility offered by PCI DSS v4.0 allows entities to select security controls that best fit their business and security requirements, fostering a sustainable and adaptable security posture that can evolve with emerging threats and technological advancements. This step is crucial for supporting robust security measures that effectively safeguard sensitive payment information over time.

icon-info:

“Organizations focused on maintaining PCI DSS security controls year-round can more readily avoid recurring cycles of short-term compliance followed by security lapses and short-term remediation each time they have an assessment.” - Lindsay Goodspeed, “Eight Steps to Take Toward PCI DSS v4.0

Benefits of Continuous over Point-in-Time

A continuous model can help to minimize the security lapses referenced by Lindsay Goodspeed in the excerpt above. Other than the obvious fact that lapses in security compliance may also lead to gaps in the effectiveness of your security controls, this cycle of non-compliance, remediation, reassessment, and compliance, also consumes substantial amounts of time and resources across multiple teams. This doubling of effort could be avoided by maintaining security testing controls on a continuous basis.

Additionally, adopting a continuous model can directly help compliance with individual controls within the PCI DSS 4.0 framework.

External and Internal Penetration Testing

Even though traditional point-in-time pentesting is still sufficient for addressing PCI’s pentest requirement, a continuous model provides some added benefits, especially when you consider a few often-overlooked parts. Requirements 11.4.2 and 11.4.3 state “Internal/External penetration testing is performed at least once every 12 months AND after any significant infrastructure or application upgrade or change” or in the case of 11.4.5, “...AND after any changes to segmentation controls/methods”.

The management process associated with traditional penetration testing makes this type of on-demand testing significantly more challenging to coordinate. A continuous model is better suited for supporting year-round, always-up-to-date test results.

The last thing to address within the pentest requirement is 11.4.4, which addresses remediation and retesting. Many point-in-time vendors and even some PtaaS vendors limit the quantity and timing of retests. In our opinion at Sprocket, this type of limitation directly conflicts with the idea of a continuous model; that’s why we do not limit retesting to any time constraints, quantity of retests, or service tiers. All findings will be retested continuously, year-round until they are remediated.

External and Internal Vulnerability Prioritization and Remediation

While requirement 11.3 is primarily addressed through a traditional vulnerability management program and Approved Scanning Vendors (ASV), Continuous Penetration Testing can support these efforts in multiple ways.

First, vulnerability severities are not always an exact representation of risk given that vulnerability scanning alone can’t account for compensating controls and vulnerability chaining techniques used by real-world attackers. Through attack path validation, a continuous approach can reveal which vulnerabilities are either false positives or pose the greatest risk to your organization, allowing for proper prioritization of remediation efforts.

Second, while 11.3.1.1 will not be a requirement until March 31, 2025, it is currently considered a best practice. Evaluating these lower severity vulnerabilities are a perfect use-case for a continuous penetration testing model. Since attackers often use these lower-severity vulnerabilities as part of a broader attack path, understanding which vulnerabilities, and how they can be linked within an attack provides a far greater picture of risk, than an isolated view of a vulnerability's severity, alone.

Third Party Service Providers (TPSPs)

PCI DSS 4.0 also provides guidance and requirements specifically for service providers and multi-tenet services providers. Within the context of security testing, these requirements are 11.4.6, 11.4.7 and A1.1.4 that require network segmentation between the Cardholder Data Environment (CDE) and other networks to be tested once every six months through penetration testing.

Above, we have already discussed the technical value of continuous testing over point-in-time testing, and those benefits hold true here as well. The added value that a continuous strategy provides with biannual testing is cost savings. Often, our customers see a 25% to 40% savings when switching to a continuous offensive security model compared to the cost of two separate point-in-time tests.

Contrary to what many believe, a continuous offensive security strategy can provide enhanced coverage at a lower cost if you are already performing multiple tests per year.

Designated Entities Supplemental Validation (DESV)

The final set of requirements discussed here relates to Designated Entities. These are organizations required by acquirers or payment brands to undergo additional validation. These supplemental steps are intended to confirm that proper controls are maintained continuously through business-as-usual processes.

Requirement A3.2.4 closely mirrors the segmentation testing requirements for TPSPs. However, the Good Practice guidance states that “Although the requirement specifies that this scope validation is carried out at least once every six months and after a significant change, this exercise should be performed as frequently as possible to ensure it remains effective at isolating the CDE from other networks.”

Just as with TPSPs, we can see that a continuous offensive security strategy can offer technical benefits and cost efficiencies over traditional point-in-time testing on the core requirement alone. In this instance, however, we also see how a continuous model more closely aligns with the true intent behind the requirement, which is driving towards a more continuous, business-as-usual, security testing process.

Conclusion

PCI DSS 4.0 does not mandate a continuous offensive security strategy as an auditable requirement. It is clear, however, that the intent of the PCI Council is to move organizations towards a more continuous model for security testing by making continuous processes part of their best practice guidance. Making steps towards this goal now, before it becomes required, will allow organizations to take a more measured Plan, Do, Check, Act approach that will provide better internal alignment and improvements in the adoption of a continuous security culture. Additionally, adopting a continuous model ahead of a mandate can offer technical, business, and cost advantages, including:

  • Improved efficiencies in time and effort spent managing the pentest process, remediating findings, and complying with section 11.4.
  • More realistic risk reporting and prioritization of mitigation efforts associated with the lower severity vulnerabilities addressed in 11.3.1.1.
  • Reduced cost for TPSPs and DESV organizations required to perform more than one pentest per year to meet requirements 11.4.6, 11.4.7, A1.1.4 and A3.2.4.