I've previously covered two of the major new requirements coming in PCI DSS 4.0, and now it's time to take a look at another one! I've long spoken about Certificate Transparency and the major benefits it can bring to security on the Internet, and now it seems the PCI SSC have recognised that with a new requirement in PCI DSS 4.0 that mandates the use of Certificate Transparency!
PCI DSS v4.0
If you didn't see my previous blog post, and you're interested in looking at the other major new requirements, you can read my article PCI DSS 4.0; It's time to get serious on Magecart that covers them in detail. Magecart has been a considerable threat to e-commerce websites for quite a number of years now, and the new requirements in 6.4.3 and 11.6.1 are going to deal these criminal actors a major blow. This blog post is going to cover the new requirement in 4.2.1.1, though, which is going to cover the use of Certificate Transparency.
Certificate Transparency
I first wrote Certificate Transparency, an introduction all the way back in 2017, so CT is certainly not a new technology. I won't go into great detail here, but to give a brief overview, CT gives you a reliable mechanism that can be used to detect and inventory all publicly trusted certificates issued for your domains, even if someone tries to hide their existence from you. The technology behind the operation of CT is quite complicated, but fortunately for us, using CT is trivial! Over at Report URI, we added support for CT Monitoring all the way back in 2019, announced here, so we've been helping domain owners set up CT Monitoring with just a couple of clicks for almost 5 years.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
The current objectives outlined in Requirement 4 have existed for a long time, for good reason, and have undergone some changes and additions in the v4.0 release. The new requirement we're going to focus on is 4.2.1.1 which states:
4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.
In many ways, this makes complete sense once you think about it. Requirement 4 is focused on ensuring the proper encryption of CHD when it is being transmitted, but how can you ensure that if you don't have an inventory of your keys and certificates? This is the primary reason that CT was first introduced! If you can't be sure of all of the certificates that have been issued for your domain, how can you be sure that they aren't being abused to intercept and decrypt your encrypted data? CT was, of course, first introduced to help protect all encrypted Internet traffic as a whole, and CHD in transit falls directly into that category.
Does this really make CT Monitoring mandatory?
Yes, and let me explain why. Let's say I process payments right here on scotthelme.co.uk and, of course, I have certificates and thus keys to ensure that data is encrypted in transit using TLS. I can keep an inventory of the new certificates that I purchase, and I can keep an inventory of the certificates that I have in my possession already, but those aren't the only certificates that might exist. What if someone in my organisation obtains a certificate outside of the proper process? It'd be missed from the inventory. What if someone outside of my organisation tricks a Certificate Authority into issuing them a certificate for scotthelme.co.uk by mistake? It'd be missed from the inventory. What if I simply miss one of my existing certificates from my inventory due to an oversight or a mistake? It'd be missed from the inventory.
The fact is, there are a lot of different ways that certificates might exist and not be accounted for in my inventory. Certificate Transparency Monitoring does not allow for such events to occur. If a publicly trusted certificate exists for my domain, scotthelme.co.uk, then it will be found and it will be included in my inventory. To explain how this works at a technical level is a lengthy blog post in itself, but this was one of the core design requirements of CT, this is exactly how it works and what it enables. This is the "raison d'etre" of Certificate Transparency, you can ensure that no certificates are ever missing from your inventory. What's even better is that you can get started in just a few clicks. Literally.
Setting up CT Monitoring on Report URI
As I mentioned earlier, Report URI has offered CT Monitoring as a public feature for almost 5 years, and I've been involved with CT for much longer than that. All you need to do to enable CT Monitoring is tell us which domains you want to monitor for certificate issuance. In the example above, where I'm transmitting CHD to scotthelme.co.uk, then that is the domain I would need to enable monitoring for. If you have more domains than that, then you simply need to list them all. That's it... You just need to tell us the domains, and we'll do everything else. Here's a screenshot of my configuration in my own Report URI account.
On the Filters page, you provide the list of domains that you want us to monitor. I monitor quite a few domains, because I operate a few different websites, and you may have a single entry or many entries like I do, but all you need to do is provide the list. This is now the list of domains that we will monitor for certificate issuance against on an ongoing basis, and it includes certificates that contain subdomains of those domains too. A certificate containing account.scotthelme.co.uk, for example, would be observed and recorded as part of the scotthelme.co.uk domain entry.
Once that list is saved, we will begin monitoring for certificate issuance against those domains. Any certificate issued will then be recorded and, as you can see in the above screenshot, you can request to receive an email notification that a new certificate has been issued if you'd like. Here's what one of those emails looks like, I received this notification only a couple of hours ago.
As you can see, the email contains the basic information from the certificate which, in the majority of cases, is going to be all that you need to determine if you need to take any action. If you would like to investigate further, there is a link to take you to the full details of the certificate for deeper investigation. If you want to browse through all of your certificates that have been issued, you can also do that in your account.
This is a snippet of the list of certificates issued in April that Report URI has detected for my domains, and, you can see the certificate that corresponds to the email alert above is in the list too. You can filter and search on this data by any criteria you see in the UI, based on when it was issued, what sub/domain is in the certificate, and who issued it. You can download a copy of the certificate if you want a copy to work with and you can even view a full parsing of the certificate without having to use any tools yourself.
If you would like to view that detailed parsing, here is the link, but before I wrap up here, let's look at the specific text of the requirement again:
4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.
With CT Monitoring provided by Report URI, we're fully achieving this requirement because:
- CT logs contain all publicly trusted certificates for your domain/s, and;
- Your certificate contains your public key, so we can inventory those too.
All of this is live and available on Report URI right now and you can get started in minutes. Over the coming months we'll also be releasing a few UI tweaks and feature improvements to make our CT Monitoring even more powerful for your PCI DSS compliance needs, but for now, why not try it out and see how fast you can get it set up?