7

I have several systems that require PCI compliance, all of them are running CentOS 6.4 with all security updates applied daily. However, PCI compliance scanning will often reject detected versions of external services (Apache, PHP, MySQL) that it deems to be insecure. The measurement of security is simply the version number of the software package--if that information is reported to the scanner vs. having all version information turned off to the outside world by defining a less verbose configuration.

I have a brand new CentOS 6.4 box that I am securing and it has failed it's initial PCI scan (no surprise there). But the first issue reported says: "PHP 5.3 < 5.3.7 Multiple Vulnerabilities." The server currently has PHP 5.3.3, as supplied by CentOS. There are other failing packages as well, but I'll focus on PHP for this question.

Some points to consider

  • It's generally understood (I think) that Linux vendors claiming stability as a feature do not rush out every new version of a package released upstream, with an exception sometimes for web browsers/plugins.
  • Vendors do release security updates, but not for every source release. (Example: PHP 5.3.26 is the newest in the 5.3 releases, and it claims to fix CVE-2013-2110.)
  • Vendor packages sometimes leave the major.minor version number the same, but bump the release number with a security patch backported into their package for compatibility reasons. Therefore, it's possible a security issue has been fixed even if the version number doesn't suggest that. (PCI: This requires time consuming manual documentation to get a compliance override.)
  • I have seen arguments in the past that vendor packages can be more secure, on the basis that they can include non-standard patches to the source. That is rarely documented in a way that can be easily reviewed, though.
  • We roll our own packages to get newer releases of external services, such as PHP, updated quickly. It provides obscure bug fixes, too, which vendors are probably less concerned about.

To achieve PCI compliance, my experience shows that rolling custom packages is the only way to pass. We have used Security Metrics, Trust Wave, and Control Scan with various results. Does that mean vendor-supplied packages, including their security updates, are not enough because they lag too far behind the upstream releases?

Note: I am asking this question because I have seen plenty of "security advice" over time that recommends "Run yum upgrade daily to get your security updates," but a PCI scanner generally disagrees that enough effort has been made regarding the security of the installed versions.

3
  • 4
    A PCI scanner is dumb (or your QSA is lazy). See this Q/A at Server Fault: serverfault.com/questions/489008/… Commented Jun 22, 2013 at 19:16
  • 7
    Don't confuse "PCI DSS compliance" with "security". Commented Jun 22, 2013 at 21:13
  • 2
    Did you try and remove/hide your version numbers from any online scanner. "ServerTokens Prod" ? Remember you are looking for the all clear from the scanning vendor to obtain compliance, information they don't have and can not obtain can't be used to hit you with. See above comment re "security", this tip is not security. Commented Sep 5, 2013 at 22:48

1 Answer 1

1

PCI DSS requires that "the latest vendor-supplied security patches installed". (PCI 6.1 pg. 38). This means that if PHP releases a security patch, then you need to apply it, even if your distro doesn't have it in their repo yet.

Your rule-of-thumb is to look to the product version number and what the vendor (PHP, Apache, etc) has released, security-wise. Scanners and distro repos can help, but are not what needs to be checked or audited. Know what you have installed, and check for security updates regularly. Double-check your scanner results on a regular basis to account for false negatives, and confirm the findings to account for false positives.

4
  • 2
    Does PCI DSS have a peculiar definition for vendor? If you run a Linux distribution, the vendor under the usual meaning of the term is the distribution. Thus the requirement means that you must have the distribution's latest security updates, not the latest security updates from an upstream project that you have no direct relationship with. For example, if you run the PHP from CentOS then you'd only need to run yum update, and not check if PHP has published an update that would require either an upgrade or a backport. Commented Nov 28, 2014 at 17:37
  • I understand your point, but the OP stated they they knew that the versions installed were behind on versions. Once you know, you have the responsibility to patch yourself.
    – schroeder
    Commented Nov 28, 2014 at 17:42
  • I don't get where the OP has stated that they were behind on versions. They aren't running the latest upstream PHP, but why would this matter? CentOS is the vendor for PHP, so why isn't it enough that the OP runs the latest CentOS PHP package? Commented Nov 28, 2014 at 17:45
  • I'm not sure that you can state that CentOS is the 'vendor' of PHP, but rather the supplier of install packages. From a practical point of view, if a distro fails to update its own repo and there are known security patches that need to be applied, you can't blame the distro repo for your lack of patching. That's why there are PCI patch scanners (that the OP used).
    – schroeder
    Commented Nov 28, 2014 at 17:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .