PCI Compliant Web Hosting and Managed Service Provider
Hosting Solutions since 1995

PCI Compliance Scans and Small Business Gripes

Author: ; Published: Jul 20, 2012; Category: Managed Hosting, PCI Compliance, Security, Small Business; Tags: , , ; 5 Comments

Just as more government regulations tend to strangle a small business to death (worse case) or slow its growth (best case), so goes for PCI Compliance standards which add little to no practical value to security.

Some house keeping first in terms of going over some terminology and a starting foundation.

A.  You have systems that are as up to date (patched) as practically possible; and you have systems up to date period (no exceptions).

Those whose systems that are as up to date as practically possible will be on the latest versions (including patches) as provided by the vendor(s) of system(s) they are using.

Most small businesses cannot afford to have everything custom written for them, so it is common to see a small business use a system provided by a vendor that is mass marketed.

What are some examples as it relates to PCI Compliance Scans and the web?  cpanel, Parallels H-Sphere, and Parallels Plesk where some of the components of the system are as only up to date as the vendor (cpanel and Parallels) provides.

While some vendors are faster than others at releasing updates and patches, and all of them to date are excellent at releasing critical security updates, customers do not have control over when the updates come out.

B.  Nothing is hacker proof; you can have degrees of being resistance to being hacked.  To state an electronic device / machine is hacker proof currently is an incorrect statement.

Now let’s lay the foundational perspective of the small business owner.

  1. The small business owner’s site uses a mass market system (cpanel, H-Sphere, Plesk, etc.) that is as up to date as practically possible (which is different than up to date period).
  2. The small business owner’s site is on a server that has the following security measures in place:
  1. Servers are secured, and the operating system core components are up to date period.
  2. Server security includes an adaptive IDS (intrusion detection system) that interacts with an adaptive firewall to block brute force and related attacks.
  3. Server security includes a WAF (web application firewall — eg. modsecurity) that blocks cross site scripting attacks, SQL injection attacks, and RFI (remote file inclusion) attacks.
  4. Server security includes consistent, frequent, alerts of what is being blocked along with trending.
  5. Server security includes 3rd party scans (not directly related to PCI compliance vendors) that show green (with any non green issues being handled in 72 hours or less).
  1. The applications used on the site are as up to date as practically possible (often times for site-based applications, it is easier to be up to date period than overall systems).

Now, the small business merchant sits back and sees they have a relatively high bar for being hacker resistant.  They have a disaster recovery plan in place for when they will be hacked; and they are obeying the spirit of the PCI compliance standards and rules.

Here starts the small business gripes – complaints.

The small business provider hires an authorized PCI Compliant scanning vendor to do a scan.

The scanning vendor starts a scan, and the security systems in place on the target server see attacks coming in (let’s be frank, a scan is seeing what a hacker may try to break in — what is and is not allowed; and intrusion detection systems, at present, cannot differentiate from a simulated attack and a real one; so good systems block), and the security does what it is supposed to do when someone is attacking the system… It blocks the attack.

Now, in practical terms, you would think you’ve just proved the system is resistant enough for PCI Compliance.  Right?  After all, an attack run started, and the system reacted timely and blocked the attacks from continuing to occur; and you’ve reviewed the logs to see there was no break — the PCI Compliance scan was stopped before they got into the yard.

Yet that’s not what happens.  The PCI Compliance scanning vendor cries foul play!  How dare you treat their scans as you would any hacker.  They need to be white listed.  They want you to treat their machines and IP block special (as if you would ever purposely do that for a hacker).

Ok, you agree that they need to do a full scan to really test the security above and beyond any automated blocking systems.  So you white list their IP addresses (typically it is a block).

The PCI Compliance scan kicks off again (time varies a lot but can be from two to ten hours depending on how aggressive is the scan), and the scan completes (they were not blocked).

As you review the results of the scan you see that various areas that PCI Compliance standards say should be blocked (this is different from blocking a scan) is blocked.

For example, on Apache mod_userdir needs to be disabled.  You have it disabled, and the authorized PCI Compliance scan ran two to a dozen specific tests against mod_userdir each one showing that it was not enabled.

But because each test they did showed a different error message (bottom line it didn’t work), they flunked your scan.  Even though hackers could not abuse it, and even though the PCI Compliance scanning vendor could not prove you have it enabled, because each test response varied (for the geeks — only responding with 403, 404, 500 inclusive), it’s a no go.

So now you work through those issues making sure that the error message is the same (remember mod_userdir was never enabled in the first place); and they re-scan.

This time you fail because a PCI DSS certified shopping cart using a valid, active (non expired), properly installed secure certificate allows the consumer to manually remove the “s” in “https” on the address bar and continue to shop with http (non SSL) vs. https (with SSL).

How many people do you know, who, while working to complete their shopping cart for a purchase will purposely go to the address bar to purposely remove the “s” in https (keeping in mind the entire process was using https to start and the only way to change it would be to remove the “s” that was there to start)?  Where’s the reality check in PCI Compliance scan results?

Now, the small business merchant is in a bind.  They are using a mass market shopping cart; and the developers might take three months to twenty-four months to come up with a programming change to handling this non realistic consumer issue.  In the mean time, the small business merchant is not PCI compliant.  Wow!

Now, your hosting provider comes to the rescue with an Apache mod_rewrite that basically puts the “s” back in “https” should it see a visitor in the shopping cart area with https off. 

You now, think you are ok.  You ask the PCI compliance vendor to do another scan.

Another two to ten hours pass, you fail again.

You review the results and you see everywhere where it really counts the PCI compliance scan could not find a fault or break in the actual, practical security.  Even though they were white listed, they could not brute force.   Even though they are white listed, the applications showed they were not vulnerable to XSS (cross site scripting), RFI (remote file injection), SQL (database) injections or other forms of attacks.

What in the world is going on?  Why is the scan failing now???

You read the very long report only to find out the authorized PCI Compliance scanning vendor is now complaining the versions of your mass market system (i.e. database server, email server, FTP server, web server, etc.) are hiding version information.

Now, wait just one second!  Best practices is to not disclose version information.

While almost all IDS (intrusion detection system) and firewalls have a means to white list on IP addresses, in 2012 there’s not an easy, practical means to disclose version information on an IP basis to some and not to others.  For example, you either have the version for Apache on or off.

If you turn on the version information for the scan, that means for two to ten hours, your versions are showing for hackers all around the world (there is so much automation with hacking there is no “safe time” to be unsafe!!!).

So you tell them the versions… now you get kicked to the curb!!!

Even though for all practical purposes you have proven your systems and applications are as resistant as possible, because your versions are not up to date period, your compliance scan is marked as failing.

This is where the rubber meets the road.  If you have systems in place so that being x version(s) behind still provide the same protection as if you were on the latest version, should the version matter?

Something has to change in favor of small businesses.

If the PCI Security Standards Council wants more and more small businesses to adopt PCI Compliance measures, then there needs to be people who are looking out for small business merchants.

Security matters, and must be a way of life for anyone connected electronically; however, living that life should not be so impractical or expensive to push small businesses away from the ecommerce dream.

If you manage, steward or otherwise own a small business, please consider contacting the PCI Security Standards Council Board of Advisors asking them review all authorized PCI Compliance Scanning firms to ensure small businesses are not being kicked to the curb due to regulations, rules, and enforcement which have either zero security implication or are otherwise unrealistic for small business to adopt.

Point them to this article and share your own experiences (especially so if you have them) with them.

Complaint summary:

  1. Authorized PCI Compliance Scanning vendors ask to have their systems treated differently than hackers — i.e. allow my simulated attacks.
  2. If you have something that should be off, off — and the scanning vendor shows it is off, get off the high horse about the error message for being off (off is off even if there’s a different error message).
  3. If the small business merchant is using a PCI DSS certified ecommerce shopping system with an active, valid, properly installed secure certificate and the system directs shoppers to https, get off the high horse of what if the consumer removes the “s” questions; deal with the practical.
  4. If the scan shows that zero (0) attacks succeeded (i.e. nothing got through — all vulnerabilities properly handled), then get off the high horse as it relates to versions.

I welcome your comments below.

Thank you.

Peter Abraham
Former CEO of Dynamic Net, Inc. Will be transitioning to a new career in the near future.
Peter Abraham


Peter Abraham

5 Responses to “PCI Compliance Scans and Small Business Gripes”

  1. Mark Vang says:

    Besides the many issues you pointed out, in a shared hosting environment it may be that the hosting provider doesn’t have the bleeding edge/latest version of certain programs installed because changes to Apache/PHP, etc. will effect everyone on that shared server.

    Also several recent high-profile hacks have shown that organizations that are supposed to offer “trusted” services (ex. certificates) can also be compromised. So if you whitelist a PCI Compliance Scanning vendor who’s to say they don’t get hacked and now the hacker can exploit the trusted status of the vendor to go after hundreds of sites.

  2. Brett Edgar says:

    Full disclosure: my company (truedigitalsecurity.com) is an ASV, I am certified by the PCI SSC to perform ASV scans, and a large part of my company’s business revolves around PCI and other compliance regimens (NERC CIP, HIPAA, FFIEC, etc.).

    1. Your scan vendor has their hands tied by the PCI SSC. Don’t blame them, they are doing exactly what the PCI SSC has required them to do.
    2. Your scan vendor should be able to report all vulnerabilities that you must fix to obtain PCI compliance in the very first report (assuming that your security systems didn’t block part of the scan). If they are coming back to you multiple times with different results, they are doing it wrong. Find a new ASV.
    3. You have to protect users from themselves as well as attackers. In your example above where a user can remove the ‘s’ from https and revert to plaintext HTTP, an attacker could just as easily redirect them to the non-secure site and sniff their credit card number.
    4. @Mark Vang: if you are a small business that is going to be offering a web app that will accept credit cards, you should be doing your homework upfront and choosing a hosting provider that can provide you a PCI-compliant site. They are out there, and they don’t cost much more than a fly-by-night hosting provider.

    Just like ignorance of the law is not an excuse for breaking it, ignorance of PCI security is not an excuse for being insecure.

    I concede that PCI compliance is hard for a small business to achieve if they don’t talk to an expert. But the experts are out there and, though expensive, a few hours of time from an expert can go a long way towards having a secure credit card web application. Believe me, the investment upfront in an expert to help you do it correctly is several orders of magnitude less than the fines a small business will incur when they get hacked and lose credit card information, especially since those fines will put many small businesses out of business.

  3. Good day, Brett:

    First off, thank you so much for responding; and I do appreciate your thoughtfulness on providing full disclosure.

    I concede #1 is a requirement that will never go away.

    Since nothing is hacker proof, the best you can do is be highly hacker resistant; and have a plan in place for when you will be hacked plus do what you can to minimize the damage of any hack.

    Can you provide any advice for small business stewards and managers as to how to find authorized scanning vendors who, while not wanting to give a free pass, will work with the merchant and actual provide waivers if the merchant can prove an issue is not a practical security threat OR the issue cannot be practically resolved where the resolution will not provide a significant increase in overall hacker resistance?

    Thank you.

  4. JohnC says:

    Peter – the ASV program guide is available on the council website and provides the detail that a merchant should be aware of. As for working with the merchants to resolve points of failure in the report, pg 26-27 of the program guide cover what you should expect an ASV to have in place for these discussions. Particularly, the ASV must have a written procedure in place for handling disputes and the scan customer must be clearly informed on how to report a dispute to the ASV; including how to appeal the findings of the dispute investigation with the ASV. The ASV must explicitly inform the scan customer that disputes in scan results are NOT to be submitted to the PCI SSC.

    One of the complaints listed, which can be a bit of an administrative headache for a small merchant, does have merit from a security standpoint. ASV scans must not be blocked by IDS/IPS systems or other “detection” tools. However, the merchant should only white list the ASV IP addresses for the duration of the scan as a best practice.

    It is interesting that you are seeing merchants receive a failing grade because the ASV scan cannot fingerprint the OS or supporting services running. This is not a requirement for the ASV scan from the ASV program guide, the only requirement is for the ASV scanner configuration which “..should, where possible, identify the operating system running on each live system. The ASV scanning solution should, where possible, determine the protocol and service/application version running on each open port. Since services may sometimes run on non-standard ports, the ASV scanning solution should, where possible, not rely solely on a well-known port number to determine which protocol is running on a given port.” (ASV program guide page 14).

    If you are not seeing support from the ASV and getting recommendations on how to resolve issues or how to dispute a finding, it may be time to find a new ASV.

    Granted, Brett’s advice is probably the best a small business merchant can get if they want to have a hosted website or other hosted services, find a service provider that has completed a PCI assessment and will provide a list of clearly defined requirements that are covered by the hosting provider and that are the responsibility of the merchant. A quality hosting provider may include a lot of these services, including ASV scans, that will remove the burden from the merchants.

  5. John, as you know PCI Compliance main benefit is for the payment card industry. Who is advocating for small business merchants when PCI Compliance remediation costs force the small business either away from ecommerce, out of business, or to come up with means to just pass scans without any real remediation?

    We’ve had several cases life to date where PCI Compliance Scanning vendors could not adequately explain the % of hacker resistance a particular scan item would add (or subtract if left) go or to discuss the actual % of risk. Each item to fix on a scan requires an investment.

    We are a quality hosting provider who is PCI Compliant (we pass our own 3rd party scans), and we do help our customers (most of whom are small businesses merchants) pass PCI Compliance.

    That does not change the fact PCI compliance is about saving the payment card industry money; the small business merchant needs an advocate for reasonable security increases.

    Since zero electronic devices are hacker resistant, you can never get to 100% hacker resistance. Therefore, each item on a scan should be measured for the actual % of risk (both to actually have the event take place, and the potential cost of the event to both the PCI as well as the merchant) as well as the cost to implement (it is not cookie cutter). And if the industry has no intelligence as to the actual % of risk, the actual cost to implement, etc. then the PCI council should wave such pieces for small business merchants. I.e. be practical or get out of the way.

Leave a Comment