2

Can some one help me to confirm that unpatched software complies with PCI DSS 3.1 or not?

The software developer has already released the security patches to fix the vulnerabilities but the organisation which is using it has not applied the patches.

Also what do the PCI guidelines say about software for which any kind of support is not available because the product is in EOL (end of life cycle)?

6

For critical bugs, the PCI DSS 3.1 Quick Reference Guide covers this in no uncertain terms:

6.2: Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

This is mirrored in the official documentation for PCI DSS 3.2 (I couldn't find a v3.1 PDF) which says exactly the same thing:

6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

To save you a long read, the TL;DR of requirement 6.1 is that criticality should be measured based on industry provided CVSS scores amplified by business factors.

In more general terms, the question of whether or not they are in violation of PCI DSS when they are running outdated and vulnerable software depends on the decision of their QSA. If the bug is minor, such as a static content injection issue or minor information disclosure, then the QSA may consider it appropriate that the organisation identified the issue and placed it on their risk register for future resolution. If the bug is more severe but not considered critical (e.g. reflective XSS requiring user interaction), the QSA may still consider this a violation of PCI DSS at their discretion.

With regards to EOL software, PCI DSS does not mention it specifically, but simply states that

All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

This indicates that using EOL software becomes the responsibility of the organisation handling cardholder data. Should a vulnerability be found in the application, it is up to the organisation to mitigate this. This may require them to manually patch the application (difficult, expensive), provide secondary controls (e.g. placing the application in an isolated container environment such as XenApp), or replace the software entirely.

For more information, I suggest you give the PCI DSS documentation a read for yourself. It's quite a long document, but you can skip to sections applicable to your concerns, and the language is quite clear and readable. Also keep in mind that PCI DSS is a standard designed only to encourage sensible security practices around the handling of payment card data - it is not a recipe for strong security on its own, so "PCI compliant" doesn't necessarily mean "secure".

  • It means "less insecure". "secure" is too high up in the abstract idea layer to be really feasible anyway. – Mindwin Oct 26 '16 at 13:46
  • @Mindwin I'd hesitate to even call it that, since there's a subset of orgs who will take a false sense of security out of PCI DSS and not apply an appropriate security model to their infrastructure as a whole, thus actually being less secure in general because they focused their resources so heavily on compliance approaches. – Polynomial Oct 26 '16 at 14:22
1

It depends

While PCI DSS does require to e.g. install critical security patches for in-scope systems within one month, the general question of unpatched or EOL software highly depends on circumstances. You obviously should not do so, but it's possible in certain circumstances if the organization really wants it and takes appropriate steps to do so.

First, the organization can use unpatched/EOL software on any systems that are out of scope for PCI DSS compliance, which in any sane configuration will be most of their systems.

For the systems that are in scope for PCI DSS requirements (which should be few and isolated), the actual PCI DSS requirement is to have policies that ensure that your systems are secure according to your own business priorities. E.g. it states "Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months."

So in general, it's somewhat possible that the organization has (a) knowledge and evaluation of the particular risks of these vulnerabilities; (b) evaluated them (according to their own risk policies!) as not critical, and (c) chosen to not apply these patches yet. This could be compliant, or not - the details matter a lot.

PCI DSS does require to monitor vulnerabilities in relevant software and act to mitigate their impact, but it's generally possible to choose how you do that, and patching, version upgrades and abandoning EOL software is not the only way to do that. There generally are other alternatives to mitigate vulnerabilities even without patching or version upgrade - for example, if a particular vulnerability relies on certain services being enabled or certain remote access being possible, then you might mitigate it by preventing those conditions instead of version upgrade, if the version upgrade is undesirable for some other reasons.

  • 1
    Extreme example: the Windows XP PC driving the touchscreen on your coffee vending machine may have hundreds of unpatched ciritical security bugs, but that has no bearing on your compliance. – Jörg W Mittag Oct 26 '16 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.