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.
- 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).
- The small business owner’s site is on a server that has the following security measures in place:
- Servers are secured, and the operating system core components are up to date period.
- Server security includes an adaptive IDS (intrusion detection system) that interacts with an adaptive firewall to block brute force and related attacks.
- 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.
- Server security includes consistent, frequent, alerts of what is being blocked along with trending.
- 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).
- 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:
- Authorized PCI Compliance Scanning vendors ask to have their systems treated differently than hackers — i.e. allow my simulated attacks.
- 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).
- 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.
- 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.