OpenSSL version causes PCI Compliance failure

Question

We have a client on AMI Linux (Amazon), which is currently using OpenSSL 1.0.1k-15.99.

As far as I can tell Amazon is very good about backporting security patches as per this page: https://alas.aws.amazon.com/ And they have stated in more than one place that they in fact do and will continue to do so per this thread: https://forums.aws.amazon.com/thread.jspa?messageID=759633#759633

The PCI compliance scan failed my client, presumably becasue the version of OpenSSL reported is 1.0.1k. I assume this becasue they list a bunch of CVEs that I know have been patched in the version currently running.

Unfortunately, the scanner's methodology is very opaque, and I can't get a straight answer as the the specific cause of the fail, and neither the credit card processor nor the scanner's tech support are helpful.

If the distro provider backports all the relevent patches to the version they have baked in, is there an actual security risk?

PCI DSS section 6.2 states:

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.

Does my installation of Amazon's latest patches which include their patches to OpenSSL 1.0.1k (which I apply weekly) satisfy this requirement? Or does application of the AMI patches not "count" and they require OpenSSL from the actual "vendor", in this case https://www.openssl.org/ ?

I've asked all these questions of the scanner / credit card processor PCI compliance team and have not received any definitive answers (or really, any answers at all - they don't seem to know the difference between an expired SSL cert on the server and old versions of OpenSSL), and my client is getting antsy.

What is the standard procedure to ameliorate this? I really am not confident in my ability to compile OpenSSL from source, for example.

Answer 1

Until you can either get a clean scan or have your PCI-QSA sign off on proof that you are compliant the responsibility is on you to meet compliance requirements regardless of real-world security implications.

Compliance does not equal security and security does not equal compliance.

That said, typically an organization will document both vendor proof that a certain CVE found on a scan is addressed by a specific patch/application sub-version as well as proof that all systems in a PCI-Zone have that version of code applied (depends on what the remediation actually involves).

The QSA can then attest that the ASV scan finding is actually a false-positive.

Your question is also leading into another issue: What if there is a major known vulnerability and the vendor won't patch it? When this is the case you may have to come up with your own remediations to address the vulnerability. You also run into the case where someone could argue that yes your distro's latest version may only be X but the latest version of OpenSSL (or insert application here) is Y. In this scenario, you are responsible for the application level patches staying current in addition to the operating system patches. Therefore by not bringing the individual package up to date, you are out of compliance.

Per compiling OpenSSL I think you'll find it's not particularly hard but do test it on another system first (not production).

Ultimately you still need to consult your QSA (assuming you have one) as they can provide very specific guidance that may help you. A good QSA can save you time here too. The card processor may not want to advise you in the event there is a lawsuit later. Again, ask your QSA.

From a strict security standpoint ignoring all the compliance stuff: Always make sure your attack surface is tightly patched to the most current patch release and where possible add additional controls for defense in depth. Tools like Fail2Ban might be your friend here. Likewise, keep in mind that patching doesn't solve your security problems you really need additional controls to protect your data. Likewise, meeting any given compliance standard won't give you good security architecture. You really need to design security deep into your solution and not just try to meet a basic compliance guideline or vendor patching levels.

Keep in mind that whether you are the data custodian or the data owner you have direct responsibility to keep the system protecting this data (or access to it) as secure as reasonably possible. Just relying on patching isn't enough.

Security and compliance are sometimes competing goals. Sadly these two are not always aligned and it's not uncommon to see money spent by businesses taken away from things that would actually secure data and have it spent on things that make an organization "compliant" (sometimes this process even increases risk). Be careful not to confuse these two goals. You have a compliance problem AND a security problem these are not one in the same. If you keep these two goals separate you'll come up with good solutions for both easier than if you try to solve both with the same solution every time. It's great when one solution fixes them both but this won't always happen the way you want it to.

Finally, DO address this with your distro provider too. Adding pressure on them to keep up with security patches where possible will help prioritize security efforts.