PCI-DSS requirements regarding long exposure to critical vulnerability (RCE)

Question

Suppose we have an e-commerce website where payment is done via redirection to a payment provider, with no processing / storage of cardholder data at our site (I'll update if needed with exact PCI merchant category, but I understand that it's the lowest one, all cardholder data is handled by the payment provider).

Suppose that we discovered 2 months ago that several critical vulnerabilities affect this website (CVSS score > 8, including RCE and SQLi).

Suppose that nothing has been done since then (patching, mitigation), and that we have no internal capabilities for forensics investigation, log review or any other detection activity.

My questions are:

• Is there a requirement for conducting investigation to identify whether these vulnerabilities have been exploited?
• Is there a mandatory disclosure to anyone?
• An obligation in terms of delay for remediation?

Answer 1

Note : Not a QSA, but some PCI experience.

The section relevant here is section 6, especially 6.1 "Is there a process to identify security vulnerabilities" and especially 6.2.b "Are critical security patches installed within one month of release?" (though the whole section is relevant to the discussion)

To comply with PCI DSS, you must have a formal process for identifying security vulnerabilities, both in third party software and in software you write, through checking the National Vulnerability Database or other sources, through secure code reviews, through vulnerability testing. You must also have a process for ranking those vulnerabilities - most places use the Common Vulnerability Scoring System but it isn't a requirement. And once those are scored, you must have a process that determines when each must be fixed by - and that process must include fixing critical vulnerabilities within a month.

And once you have all these processes, you must actually follow them.

I am not aware of any requirements for disclosure within the PCI DSS standard, though industry best practice is to have policies defined for when to disclose to who and there may be local laws (California has some, for instance) that require disclosure in certain circumstances. I am a personal believer in defaulting to disclose when exploits happen.

Answer 2

IANAQSA, and a lot of this has more to do with contractual merchant-processor-card brand obligations than the DSS per se, so there's more "I think" than "I know" than usual here:

Suppose we have an e-commerce website where payment is done via redirection to a payment provider, with no processing / storage of cardholder data at our site (I'll update if needed with exact PCI merchant category, but I understand that it's the lowest one, all cardholder data is handled by the payment provider).

It sounds like you're a merchant subject to SAQ A. This limits the extent of the PCI DSS that you're required to adhere to. Particularly relevant to your questions, you're not subject to the patching requirements found in DSS 6 or log analysis of DSS 10.

One of the problems of SAQ A (IMHO!) is that all the protections it relies upon are trivially subverted by an attacker who is able to poison your site, but SAQ A doesn't subject you to the particular requirements (like 6 and 10) that would help secure your site against that vector. Be carefully aware that when you're not being held accountable to the protections, you will still be left holding the responsibility later.

(For example, simply requiring File Integrity Monitoring (FIM) as per DSS 11.5 on SAQ A merchant pages that direct customers to the iframe or javascript of the processor would be a huge increase in security. There are hundreds of Magento users who have learned this in the last month or two.)

• Is there a requirement for conducting investigation to identify whether these vulnerabilities have been exploited?

No, but if you have any reason to believe they have been exploited, then you have obligations as a merchant to investigate the potential card breach (e.g., think in card/transaction terms, not computer forensics terms). As you state that you "have no internal capabilities for forensics investigation, log review or any other detection activity" then if you determine there was a breach any ensuing technical investigation would involve hiring an outside firm (you have contractually agreed to do so already, if you're acceping card payments).

When I say "any reason to believe they have been exploited," I mean "any indication of increased fraud related to cards your customers have entrusted to your processor on your behalf." Again, think in card terms.

• Is there a mandatory disclosure to anyone?

You are not required to disclose the fact that you've determined you have vulnerabilities. You are required to disclose any believed breach of customer data, even if you don't hold that customer data - for example, if your support line starts getting a drastically increased volume of complaints from customers who say "I bought something at your site, and the next day fraudulent charges began to appear on my card!"

Bear in mind that your processor and the card brands also do statistical analysis, and are just as likely to notify you that you've had a problem as you are to notify them. Which leads to:

• An obligation in terms of delay for remediation?

If you're breached, and in the ensuing investigation it becomes clear that your failure to detect and remediate your security issues in a timely manner was a contributing factor, then whatever fines or sanctions you face may be worsened. So it's absolutely in your best interest to deal diligently with these issues, and to maintain a clear timeframe.

Think of it as a legal issue of due diligence; again, as a SAQ A merchant you aren't subject to portions of the DSS that might draw lines around this, but you're sure left holding the bag if there's a breach.