PCI and revocation checking for public trusted certificates.

[DLPelletier]

Hello,

  I have a question (healthy debate with audit) about the use of digital certificates in a PCI environment.  We have a system in a PCI environment that makes a TLS call to a server also in the PCI environment.  As part of the normal TLS handshake, certificate revocation checking is performed. Here is the issue.  Port 80 outbound from PCI to the certificate authorities revocation site is blocked on port 80.  This is a normal part of how PKI works and is required to support download of CRL or OCSP revocation status.  Our PCI team is claiming that if they open up port 80 from the PCI network to our public certificate authority revocation site, we will fail PCI audit. My stance is this is how PKI the world over is built and port 80 is required for http access to the revocation sites.

Have any of you run into this question before?  

[csjohnng]

@DLPelletier 

Good that I did not run into this question but I will say similar question will be raised by other people, audit or compliance in my every day life.

Simple answer is what is the "harm" / "risk" of fetching this information from an "unencrypted" port say 80 in the process or reading the CRL or via OCSP? (and is there any "safer" way to implement?)

or I will trick them and ask: Say if it's possible to run in "https" instead of "http", does this "satisfy" your PCI Team?

(if they say yes, then I will be keep drilling, how to "verify" the certificate on the "target" CRL or OCSP server upon when performing HTTPS/TLS to that target CRL / OCSP server?)

or is this "safer" to have "all" TLS with all self-sign certificates (you end up putting every self-sign certificate into the trust store), because it's self-sign (or the root certificate) there is no way to revoke and no CRL and no OCSP is required, (or even it's a public cert, let's don't check the CRL and OCSP), then no more outbound http, happy days! Does this make them happier?

At the end of the day, I will just ask myself, does this make the environment more secure or less secure?

[zzptest]

Ask them which specific requirements of PCI DSS they believe will be broken by allowing this traffic. The two most obvious ones are:

1.2.1 - Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

1.3.4 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

As long as there is a legitimate reason for this traffic (which there is), and it is limited to the specific systems and external addresses that required (which it should be) then there is no issue with it.

[jimscard]

I've run into this issue in the past, both when I was on the other side of the table before I became a QSA, and many times since at customers when conducting PCI assessments in their environments. 

The correct answer has already been posted -- the primary requirements in question are 1.2.1, which requires that inbound and outbound traffic to/from a CDE be restricted to that which is necessary, along with 4.1, which requires that only trusted certificates be accepted.

Since you need to connect to the CRL/OCSP servers to ensure that you're accepting only trusted (not revoked) certificates, and CRL/OCSP checking is done over port 80, outbound, in order to comply with req. 4.1, it is necessary to open port 80, outbound, to the specific servers hosting the CRL/OCSP services for the certificates you need, including all certificates in the chain up to the root CAs.

A secondary requirement that would be involved is 1.3.4 (any outbound traffic must be explicitly authorized).

That being said, some of the lessons that I learned from experience are that firewall rules are IP address based, but the CRL/OCSP URIs in certificates use FQDNs. And, sometimes, the IP addresses that those FQDNs resolve to change. Sometimes unpredictably, overnight. Learned that one the hard way when all of our stores went down because a CA company had gotten compromised, so our payment processor's certs were replaced with certs from a different CA and we didn't have that CA's CRL/OCSP servers in our outbound whitelist.

So, my advice is to first, make sure your Incident Response Plan includes this scenario -- how to recognize that it's happening, and how to resolve it. E.g, connections start failing, check certs for changes, check the CRL and OCSP specs in the certs, test connectivity to them etc.

Second, as much as possible, take variables out of the picture. Contract with whomever owns the certs in question for you to be informed when a cert change is going to happen; put an SLA with appropriate timeframes, escalations etc., so if they make an emergency change, they're notifying you so you can make an emergency change too., etc. Go up as far as you can in the cert chain.

If you can't get a contractual notification process in place, then you'll need to do it via monitoring. Set up a monitoring rule that checks the IP addresses that all of the CRL / OCSP servers that are relevant and alerts whenever they change. Use internal DNS records to control the addresses that the FQDNs can resolve to so the firewall rules are manageable; or maybe get a proxy server set up for the CDE to use that allows outbound connections to the FQDNs needed (only).