Securing Keys and Certificates: A PCI Auditor’s Perspective
Gary Glover and Brandon Benson on keys, Heartbleed, and security.
Businesses must ensure their key servers, certificate authorities, open SSL libraries, and server updates are secure. Christine Drake of Venafi interviews Gary Glover, Director of Security Assessments at SecurityMetrics, and Brandon Benson, Security Analyst at SecurityMetrics.
PCI Requirement 2.4
Listen to the full interviewChristine Drake: Let’s talk about the Payment Card Industry Data Security Standard version 3, and how it applies to visibility in keys and certificates. I’m with Venafi, and we deliver next generation trust protection, securing keys and certificates.
Gary Glover: I’ve been a Qualified Security Assessor (QSA) in this industry for about 10 years, before PCI DSS was even a standard. Over that period of time I’ve conducted many PCI DSS and PA DSS assessments, and a lot of consulting. Now I manage a group of QSAs and Penetration Test engineers at SecurityMetrics.
Brandon Benson: I’ve been a QSA at SecurityMetrics for approximately 4 years now. I work with point-to-point encryption format algorithm standards and have had quite a bit of experience with managing and dealing with keys. I help companies interpret the standards in their environment and see what controls are in place and what they need to fix on a regular basis.
Christine: I want to focus in on Requirement 2.4, which requires an inventory of all system components in scope of the PCI DSS. That includes keys and certificates. Gary and Brandon, do you think businesses know where their keys and certificates are that are in scope of PCI DSS?
Brandon: It is definitely more difficult for newer merchants or companies just starting to undergo the assessment process for the first time. Those are areas they haven’t really focused on in the past.
Gary: Most QSAs will go through a discovery process as they prepare someone for their first audit. During that process, we help businesses identify where those keys are.
Early on, when PCI assessors start asking questions about keys, IT staff members say, “I don’t know where those are.” or “The person who did that key process left the company. Let me figure that out and get back to you.” Scenarios like that happen a lot.
Christine: Sounds like it’s a manual back-and-forth process. As they hear more about what they need to discover, they go out and find it. Scope isn’t a one time process, but a back and forth until you’ve covered everything?
Gary: Yes. When we get people prepared for a full PCI DSS audit, we are constantly educating on data flows and how the digital keys are being used inside their network to protect an SSL stream. Part of the process we go through is identifying which employee knows where the keys are. We have to get them on the phone, talk them through it, and identify the flows. So yes, the discovery process is a bit of a manual thing. After a customer has gone through this process a few times, they’ll know which keys need to be changed, and which ones we’re going to ask them about.
The most difficult part of a PCI audit is determining the scope, ensuring it’s correct, and helping the customer understand how it might be modified to minimize scope.
It’s important for people to realize that the keys QSAs talk about are the ones used to secure static credit card data. Ensure you have good key management key procedures around those. Sometimes customers gloss over SSL key expiration dates, and they don’t care if they are self-signed.
Christine: Do you include SSL keys as part of the scope in PCI audits?
Brandon: Yes. PCI DSS Requirement 4 specifically talks about encryption of data over open public networks via transmission. That’s where we should focus more on the certificate type of keys and keys used to encrypt data on the fly.
SEE ALSO: The Problem with SHA-1: Updating Your Security Certificate
PCI Requirement 5
Listen to the full interviewChristine: Let’s talk now about Requirement 5 including a new provision that requires companies to evaluate uncommon systems to see if they are susceptible to malware.
We recently saw that to remediate the Heartbleed vulnerability, all keys and certificates had to be replaced. Very recently we saw a compromise in a health systems services company that compromised 4.5 million records because the keys and certificates were not updated. Gartner predicts that 50% of all network threats will use SSL by 2017. So I’d like to get your take on how Requirement 5 applies to keys and certificates.
Brandon: The primary target for malicious software is keys. If I have access to keys, I have access to your encrypted data. That’s why it’s so important to protect the keys.
But what we’re seeing is that malware attacks vulnerabilities in applications that use those keys. The malware for Heartbleed for example, didn’t attack the keys, it attacked the open SSL vulnerability so it could obtain the keys.
I think that’s what Requirement 5 in PCI 3.0 talks about. We need to make sure our key servers, certificate authorities, open SSL libraries, and update servers are secure, because that area has been neglected in the past.
Gary: I’d also like to add that when QSAs go through a system, they are supposed to look at all systems in scope and determine how those systems affect network security.
Technically, you can define something as inside a network zone, but it may be a server outside the network zone that’s critical to the security of the card network. It may be a shared key server. Even though it’s not technically inside the boundary of the cardholder data network, we’d want to make sure good controls were placed on that server. That might include anti-virus and anti-malware protection.
Christine: It really doesn’t matter if an organization sees keys or certificates as a common or uncommon system attacked by malicious software. Really, they’re supposed to be looking at their entire environment. Requirement 5 emphasizes that.
Brandon, you brought up the point that keys and certificates are a target, and compromising those assets helps in the delivery of malware. It sounds like protection would go beyond anti-virus.
Brandon: As you start looking at the security of an environment, the strength of the key is the key! No pun intended. We recommend all our customers to monitor their key locations. We don’t want keys to be swapped out or changed in any way.
If any keys are compromised, released, or disclosed, your environment becomes vulnerable to attack. Key misuse has a direct impact to the security of a cardholder environment.
I also wanted to mention that we’re seeing malware stream data from environments using SSL. So it's not like the bad guys don’t know the importance of encrypting data, because now they’re using it to encrypt data in these environments.
Christine: Sounds like it’s important to do anomaly detection and make sure these assets are being used as they are intended to be used. Do you think Heartbleed will put more focus on key and certificate security in audits going forward?
Brandon: The short answer to that question is yes. The long answer is, it’s not just keys we have to focus on. It’s also the systems and components supporting those keys. A key could be 100% secure. You can store a key in a hardware security module or a key management server that’s 100% isolated from the system. But the moment I need to use a key, for example in an open SSL library for receiving web traffic, I need to put protections around the key in all locations.
Heartbleed reemphasized the need for companies and assessors to understand where all keys are located and ensuring proper controls are in place to protect them.
Christine: Sounds like Heartbleed has a big ripple effect, but really what matters is remediation.
Brandon: Because Heartbleed attacked Open SSL to steal the secret keys, that’s what companies had to patch. Once they patched their open SSL libraries, then they had to issue new private keys for everyone. We saw some companies patch, but not replace their keys. Some companies replaced keys but didn’t patch. When you look at security, it’s really a multi-layer approach.
Christine: Whether it’s Heartbleed or another attack, you have to make sure remediation happens. I would assume you look at the latest attacks when you’re doing audits?
Brandon: Any QSA should consider that as part of their process. As we learn about new vulnerabilities, we communicate them to our customers. It’s not uncommon for me to email my customers and say, “I know you’re using Open SSL, have you seen this?” I know you’re using Oracle or My SQL, have you seen these vulnerabilities released today?”
Gary: The real point of Requirement 5 is, things change. Even if you think a system is out of scope for anti-virus or malware protection, you’ve got to be aware of what’s going on in industry and what’s going on with vulnerabilities. Earlier in the year, your system could be out of scope for anti-malware, but based on how things are happening, it is now.
Christine: Excellent point Gary. Businesses must continue look at their scope and security over time and not expect it’s finished after one review.
Want more? Watch this Infosecurity Magazine webinar: What’s new in PCI DSS v3 for cryptographic keys and digital certificates?
The new PCI DSS v3 mandates stronger security for the technology that creates trust between servers, devices, and cloud—cryptographic keys and digital certificates. With cybercriminals hungry to steal keys and remediation of Heartbleed still incomplete, there’s sure to be more attention to this in audits. Yet the PCI DSS v3 requirements demand more visibility and security over keys and certificates than most organizations can deliver.
