Are PCI Scanning Companies Becoming Lazy Fat Cats?
Payment Card Industry (PCI) Compliance is a big thing for ecommerce merchants. Becoming and staying compliant when handling credit cards through your website is mandatory now. It’s such a big deal that overnight, a whole new industry was born to “help” merchants become compliant by providing scans and questionnaires – Approved PCI Scanning Vendors (ASVs).
PCI Scanning companies are rolling in it
Many of these ASVs partnered with merchant account providers and banks to become the official partner for providing PCI related services to ecommerce merchants. Some of the larger ones grew from a few hundred customers to tens of thousands of customers in a short period of time.
And with each customer paying $100 – $500 a year in PCI fees, millions of dollars were at play. A whole industry was born, one in which large amounts of money could be made in return for some automated scans and a questionnaire.
A bad trend is emerging
As these companies grow larger, we’ve noted that a trend has become apparent – One in which these companies seem to do less, do things slower, and make life more difficult. Pretty much the opposite of what they were initially designed to do. And oh yeah, help merchants become more secure.
In many cases, it feels as if we (the hosting company) are often left doing their job, and merchants are left to fend for themselves.
Recent examples experienced first hand
“We don’t believe you, you’re a liar, do our job”
I was taken aback by this one… A simple false positive came up on a PCI scan. So, we emailed back listing the patch level of the software (think of this like the VIN number on your car) that should show the issue is already patched and not a vulnerability. We run Red Hat Enterprise Linux servers (one of the most popular operating systems on the internet), so the patch level should suffice for the PCI company to look up the applicable patches in their database and resolve.
Wrong! The response was for us to dig through the changelog from Red Hat for the past FOUR years and show them where each issue was addressed by Red Hat. Huh ?!?!? That’s like applying for auto insurance, giving them the VIN of your car, and the insurance company saying please look through the documentation on your car and provide us with all the specs in the engine and body.
After giving in and providing this, we were then told this is not proof enough. We also had to have a screenshot showing this patch applies to the server and website in question. What ?!?!? Now they think we’re lying and want the picture to prove it? Using the auto quote example, that would be like the agent asking you to take pictures of your car and send them in so they can see there are actually 4 doors on the vehicle.
Simply ridiculous for a standard false positive from their automated scan that could’ve been cleared up in 1 minute.
Simple Contact Form – “Let’s abuse it”
Client has a simple web based contact form asking for name, email, phone, and message. One scanning company says it has to be SSL secured. Seems a bit excessive and not really a PCI issue.
Another scanning company submits 100+ requests via the form “testing” it. Client is annoyed. We exclude this form from being scanned in the PCI control panel. Now the scanning company says they fail PCI because a URL is excluded.
So the client is forced to make it fully secure, add annoying image Captcha to stop the abuse, or block the scanning system from hitting the page at all. None of it ideal.
What’s good for one PCI company is not for another
One vendor says IMAP without SSL is fine (checking email normally). Another vendor says this same setup fails PCI. One vendor says FTP is ok. Another says it’s not. Who to believe? And is any of this causing small merchants to get hacked by credit card thieves? (hint, the answer is 2 letters long and starts with an “N”).
“We’ll take our time to address issues, but fail you instantly”
If a PCI scan fails, it says “FAIL” in bright red right away. Essentially, the merchant is deemed to not be PCI compliant. Even if it’s a simple false positive, the scanning company may take up to 2 weeks to get it resolved! We’ve found that the time to get questions answered and false hits cleared up has been getting longer and longer.
“We’ll hide the URL that caused the failure”
One of my favorites. Some scanning companies don’t list the actual URL that caused the vulnerability to appear. It requires the merchant or us to contact them, ask, and wait around for a day or so before they respond. In some cases they list the wrong URL, or don’t understand the issue, making the whole procedure unbearable.
The little guys and gals pay the price
Even though the overwhelming majority of compromised cards come from large companies like Heartland and TJ Maxx (well known security break-ins that resulted in millions of card being compromised), it’s the small merchant that seems to pay the price. A small merchant may never see a credit card number (using a real-time payment gateway), but still bears the brunt of these burdensome rules and regulations.
If the target is the large companies, then why make doing business unbearable for the small merchant? It sure doesn’t seem to be helping with security. Quite the opposite of “help” in my opinion.
…
The PCI industry (including credit card companies) needs to be cleaned up. It needs to accept more of the burden for *actual* security, and not push it off on the merchants and hosts.
It almost appears as though the PCI scanning companies are creating more rules and red tape to help justify their existence. In my mind, it’s an existence we can currently do without. Agree, Disagree?
Looking for a web host that understands ecommerce and business hosting?
Check us out today!
I wholeheartedly agree with your position, and appreciate very much that you handle these issues with our PCI Compliance service related to my website.
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.
Thanks for the comment Marcea. it is crazy that banks are assessing fees whether or not you use their PCI partner or another. The system should be open and just require merchants to get PCI compliant from *ANY* approved vendor.
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.
Didn’t we go through this exact thing on my wordpress blog?? they wanted my login for the blog, which is totally unrelated to the shopsite software, to be under an SSL login.. Really??
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??
Yes, quite annoying Steve. The system is really broken, and needs a complete overhaul. In the interim, us hosts and merchants need to do what we can to avoid extra fees and show compliance to avoid any problems if an ecommerce database is hacked.
Unfortunately we bear the brunt of the pain in getting this done…
You’re dead on… Was unfortunately a customer of one of these scanning vendors, always was frustrating.
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.
Full disclosure, I work for a smaller ASV. What I say is not sanctioned by my unnamed employer. While I know we haven’t scanned any of your netblock, I sympathize because the PCI Council really created this beast, and its pretty difficult to navigate. I would like to clear a few things up from the ASV perspective. I’ll address each section. (please hold onto your tomatoes until the end of my comment)
“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…
Eric,
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.
Screen captures really are only required for systems that don’t have a useful CLI (windows). =)
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.