Your software vendor is asleep at the wheel and your devs still need that legacy daemon
It’s nearing the end of the quarter and you’ve just completed your ASV External scan of your cardholder data environment. Perusing the report and noting the typical false positives you’ve disputed a dozen times before, something new catches your eye. A new OpenSSL vulnerability has been flagged on your production webserver!
Not to worry—you’re running Red Hat and those false positive disputes you just submitted all had backported patches. All you need is to grab the CVE and check the vendor site. Your heart suddenly skips a beat: The big red “Will Not Fix” is emboldened by your webserver’s current Red Hat version on the security advisory page. This vulnerability is not a false positive, and it exists in your environment!
Compensating Controls and ASV Disputes
In Payments Card Industry (PCI) standards, sometimes an organization is unable to fulfill a particular PCI DSS requirement due to legitimate technical or documented business constraints. When you are unable to meet a specific requirement, your compensating controls must meet three criteria:
- Meet the intent and rigor of the original requirement
- Provide a similar level of defense, such that the compensating control sufficiently offsets the risk of what the original PCI DSS requirement was designed to defend against
- Be “above and beyond” other PCI DSS requirements
This framework sets the stage for disputing vulnerabilities found within your ASV scan reports.
Filing a Compensating Control Dispute
The first steps will always be to validate that a vulnerability does exist in your environment and identify the technical or business constraints preventing a resolution. After you’ve confirmed the vulnerability and constraints, your next step will be to understand and address the vulnerability in question. It’s important to fully understand the vulnerability and craft your compensating control to sufficiently offset the risk the vulnerability presents to your environment.
Is the vulnerability providing information disclosure? Your DLP or WAF solution may already be capable of detecting and mitigating against such an exploit. Does the vulnerability call an application to perform an unwanted action? It is possible that your Host Based Intrusion Detection System can prevent those binaries from executing. Does the vulnerability require access to a resource or service? An ACL that blocks or restricts access might be the perfect solution.
These are just some examples of addressing a vulnerability with compensating controls. Once you have identified and implemented your compensating control, it’s time to file your dispute. As a scan customer, you must provide:
- Supporting commentary for disputed findings
- Simply a statement to explain the associated evidence and dispute type
- Supporting evidence
- Screen captures
- Configuration files
- System/file versions
- List of installed patches
As ASVs, we must assess the relevance and applicability of the compensating control as well as ensure it offsets the risk presented by the vulnerability. While we can remotely validate for vulnerabilities and controls, it is always preferred to have accurate and comprehensive documentation submitted for evidence in the disputing process.
Like false positive disputes, ASVs can only accept a dispute for a particular vulnerability for 90 days, so make sure to file your notes and evidence away for future reference if you expect a vulnerability to remain in your environment.
- PCI DSS v3.2.1 Appendix B
- ASV Program Guide Sections 7.7 and 7.8