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.

  • 1
    Note: I've once installed AMI just to find out that it was probably the worst-case choice available. If its an option, stick to distributions which have an actual community, not just a company, behind them. Ubuntu Server or some Debian are usually the best choice, else the RedHat Distris (CentOS, Fedora..).
    – Gewure
    Mar 9, 2017 at 11:46
  • 1
    I hear what you're saying. I actually really like AMI becasue they patch it almost continuously and it generally seems to be up to date. I'm getting irritated with the PCI people because Amazon states that they have backported those CVEs to their distro, and the PCI people seem to only want to look at the reported version AFAIK RHEL and CentOS do the same, so I suspect I'd have the same issue there - OpenSSL is 1.0.1e. I'm not quite ready to give up on AMI yet, but I may have to. Mar 9, 2017 at 17:14

1 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.

  • I should probably advise my client to contract with a QSA to advise them, but I suspect they won't want to pay for it. We do take steps to minimize the attack surface such as closing all non-essential ports, ssh only with key files from known IPs, etc. We routinely scan and patch our applications for XSS, SQL injection, etc. But as you can tell I'm not a security expert. fail2ban is a good suggestion here. I will spool up a standalone instance and attempt to compile openssl and see what I break. In this instance it may come down to enumerating all the patched CVEs vs the list provided. Mar 9, 2017 at 3:52
  • 1
    Another trick that is sometimes useful ( I do this when dealing with industrial equipment or mainframes & mini's that people don't want to patch ) is to insert a proxy in front of the server to offload the SSL/TLS sessions and use a system that is easy to secure & patch. If both are in the PCI Zone this can help. It can even reduce the CPU load on the back-end and allow you to insert an additional layer of protection (add IDS/IPS, Fail2Ban, Mod_Security) in front of a system where it's hard to add those. There are many ways to solve it but this pattern is repeatedly useful. Mar 9, 2017 at 4:21

You must log in to answer this question.

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