I think the biggest problem from the ASV side of things, is that we’re required to show potential (unconfirmed) vulnerabilities. This makes the number of false positives sky rocket. This is likely the root cause of the pain you feel as you work through merchant compliance issues.

Unfortunately, the DSS is intentionally vague, and rigid. The good news, which I forgot to mention, is that ASV’s are required to start a training program soon (I dont’t have the date in front of me). We haven’t gone through it yet, but this should help solidify the messages you receive from various PCI service companies. This isn’t going to fix all of the issues outlined above, but its a step in the right direction.

There is a lot more the council could do to help the situation, though. We ASV’s want more clarity just as much as the merchants.

Thanks for the well thought out response. It’s nice to hear from the other side of the tracks.

Per the repository / patch level, I agree that what you ask for is not too much to ask. But we’ve had ASVs ask us for repository changelogs for certain items, screen captures, etc… it goes way beyond what I’d expect, and with multiple requests per day, causes us to waste hours trying to track it all down.

The big issue is all this fragmentation and differences between ASVs leaves the merchants and hosting providers scrambling trying to meet all the different requirements to pass scans. It’s a huge deal to the merchant, we care about our clients so it’s a big deal to us, but often ASVs come across as too busy / uninterested to care. Which just makes the whole process unbearable.

Hopefully as standards actually become standard, and ASVs can keep up with the volume of business, this will not be such a hassle in the future.

“We don’t believe you ….”

Unfortunately, simply stating the patch level isn’t enough. ASV’s are on the cusp of being audited by the council, and should the PCI elders review a scan with a false positive that was exempted and the proof provided was an email saying the “patchlevel is x.x.x”, the council would crawl all over them. Worse, the ASV could go into remediation, which is something nobody wants. I would never ask someone to dig through a code repository, but I do ask them to provide sufficient output to prove this is the box in question. In your case, i would want to see output from ifconfig, software -v, and date so I can store that in our false positive tracking system (since we have to carry these forward and exempt them on all future scans). I personally dont think that is too much to ask.

“Simple Contact form…”

Most ASV’s perform their preliminary scan with an out of the box vulnerability assessment tool. By default, these PCI scanning templates try to inject all kinds of bad things in a contact form. If they’re using a nicer web scanner designed for web scanning (which I hope they would for a webhost like yourself), they should have the ability to exempt a contact form. Unless this is known up front, those forms are going to get pounded into oblivion. This isn’t being done intentionally, is my point.

“What’s good for one PCI …”

This is largely the PCI councils fault. They leave a lot of the DSS up to interpretation. There are some ASV’s out there that do the bare minimum, so a cleartext protocol wouldn’t trigger any alarms. There are others who are trying to provide the best vulnerability assessment they can, and flag this as a vulnerability. A lot of this comes down to the vulnerability scanner and process being used. The only person with any weight behind their opinions is the QSA, and even they can be overruled by the council. The council needs to be more specific, or provide a better means of getting these questions answered. It took me weeks to get a response back over something simple, and it’s been well over a year and they haven’t answered my other questions.

“We’ll take our time to address issues…”

This is just a staffing issue. Either the engineers on the other side dont know, or they dont have enough people. This is pretty simple, unfortunate, but I doubt they’re being lazy.

“We’ll hide the URL that caused the failure”

This is up to the VA software being used again. A lot of companies are using stock reports out of a specific tool. These reports leave a lot to be desired. To make matters worse, PCI 2.0 just came out which forced everyone to change the reports again. This isn’t an easy process, but shouldn’t happen from the ASV perspective.

“The little guys and gals pay the price”

Sadly, this is the way PCI was designed. If the banks actually wanted to solve the problem they would seriously look at chip-and-pin or any other means, and take ownership of some of the problems. Their risk calculations told them they could save money by pushing responsibility downstream. This isn’t that big of a deal for larger companies, but for level 4’s, PCI is crazy expensive and time consuming.

In general, I’m not here to sell my, or my employers services. I’m here as an objective observer. I think the best ammo you can use when fighting these types of issues with an ASV is to be familiar with the DSS as well as the ASV Program Guide, these are available on the PCIsecuritystandards.org website.

Commence tomato barrage…

My favorite request was ‘turn off your firewall so we can perform a scan’. Our firewalls are always up, why would we take them down for a ‘test’?

Now that we started a new IT consultancy firm, some of our clients are asking us about PCI compliance… and we’re thinking of becoming an ASV and perform proper scans & audits.

Whole process is a complete mess.

Unfortunately we bear the brunt of the pain in getting this done…

the part that bugs me the most is that if they do say that the site is compliant, they won’t stand by that.. It’s like the lawyer we just paid to do a title search on some land we just bought.. His letter says he couldn’t find anything wrong at all, but he still wasn’t responsible for anything.. Uh, why am I paying you again??

All these fees add up to millions in the pockets of the banks and scanning companies, while the small merchant is left to fend for themselves when it comes to PCI.

Definitely not a fair and level playing field, and certainly not an industry where trust is to be found.

I have a merchant account with my bank. They recently informed me of a MANDATORY annual fee to cover PCI compliance. It was to get reimbursement for the BANK’s compliance costs with Visa/MC, but they included a “free” subscription for me with their selected PCI Compliance company. I explained vehemently that I already pay for this through another company, and why pay them a fee for a service I pay someone else? To no avail, I have to pay both.