PCI 3.0 Compliance: How to Dispute Your PCI Vulnerability Scan Results

December 03, 2014

In this Whiteboard Wednesday, Trey Ford, Global Security Strategist at Rapid7, will discuss PCI compliance and how you can dispute your PCI vulnerability scan results. There are times when an asset on your network contains a vulnerability that you cannot or will not fix due to business impact. If this vulnerability has a CVSS score greater than or equal to 4, it will hinder your ability to become PCI compliant. What happens next? Watch this Whiteboard Wednesday to learn how to dispute your PCI vulnerability scan findings.

Video Transcript

Hi. I'm Trey Ford, Global Security Strategist with Rapid7. This week's Whiteboard Wednesday we're going to talk a little bit about how to dispute a ASV Scan. Why would you want to dispute a scan coming from your ASV vendor? Generally speaking this whole conversation starts around a failing scan or a failing vulnerability being identified from that scan. A vulnerability scored with a CVSS base score of 4.0 or above is a failing vulnerability according to PCI. There's a few exceptions to this, but for a variety of reasons we're going to encounter circumstances where we need to operate with a certain configuration that will meet that vulnerability. Now what we want to talk about is how we're going to resolve this.

Show more Show less

The discussion's fairly straightforward. First the question is, can you fix it? Can you patch it? Could you remove it from scope? Oftentimes that can't be done. Can you add a compensating control? Is there something you can do to deal with that vulnerability, mitigate that vulnerability, or manage the risk of that vulnerability? There's a flow for that. Can you remove this particular device or service from scope? Now, theoretically a PCI discussion or any complaints or security discussion for that matter you want to look for ways to remove anything you can that could represent a threat to credit card data or any data of value to you.

Now, there are a lot of circumstances where you're going to run into a vulnerable service or configuration that you're going to need for some reason. There's going to be an impact to the business. A common occurrence that we're running into right now is the degradation of SSL version 3. Anything with the RC4 cipher should have been shut down a long time ago. Now we're running into this with the SSL version 3 CBC. That set right now client side, there's a lot of systems that need that cipher in order to work or we're going to have to replace a lot of clients. That's a major business impact, a lot of companies are going through that so this discussion's coming up not just at Rapid7 but across the PCI community.

The question comes to what do we do about that? Generally this is handled through the client producing a compensating control worksheet, but the selection is that you're going to accept risk as a compensating control. That's not something that ASV can do for you. An approved scanning vendor is following a fairly structured, rigorous process that is designed as a measuring stick, a ruler, to determine what your vulnerability score is for internet-facing systems and so it's a fairly rigorous, fairly structure process. When you have a vulnerability that you want to dispute, you're going to approach them and provide supporting evidence. You're going to give them information, not just, "Hey, I'm a security professional and I know what I'm talking about. Trust me, it's fine." We need screenshots. We need dumps from configurations or comp files to help us review and say, "You know what, this is, you know, not all scan signatures are perfect, so we're going to review this and say, 'Yeah, that's probably not correct.'"

There are circumstances specifically with the SSL and other encryption ciphers where yeah, this is a failing vulnerability. Yes, this is now classified as the 4.0 or above, and we're not going to be able to pass that scan. We can't edit that scan. We can't allow you to edit that scan so what's going to happen is at some point this is going to be handed to either your QSA or get passed on to the payment brand or your acquiring bank. Now why is that possible? Why is that [inaudible 00:03:15]? That's not documented clearly in the program guidelines for the ASV program. You're fairly correct there. There's only two possible outcomes for a failing scan vulnerability in that worksheet. When you follow the flow, when you have a failing scan, you go through a compensating control, you send the documentation back to your ASV, and they rescan. You're still going to fail that vulnerability. It's not been fixed. At some point the passing scan, and you're not going to get to a passing scan if you're keeping that vulnerability there, you're going to send that on to the acquiring bank, so why is that necessary?

The bottom line is the acquiring bank owns the liability for doing business with your organization. They receive your transactions. If there is a breach, they send the forensic team out to do the assessment, figure out what happened, determine fault, play the blame game, but the fine doesn't come to the merchant. The fine doesn't come to the service provider. The fine comes to the acquiring bank that's managing those transactions. That, along with fees, gets passed down to the merchant so at the end of the day this decision, the decision to accept this risk and allow this vulnerability to persist in your environment, has to come from the bank.

My name's Trey Ford, Global Security Strategist for Rapid7. We'll talk to you soon. 

PCI Compliance Toolkit

Download the Rapid7 PCI compliance toolkit to help with your PCI needs.