65 merchants across Europe?

So that's about 0.1% of all merchants** across europe.

What size were they? FTSE 100 or the local bakery?

Where were they? The Bigger economies, UK, France, Germany or the new Eastern nations.

It's too small a sample and It means nothing without mentioning it's sample demographics.

Meanwhile I've just done a survey in our office and I can confidently say that 100% of all Britons live in the southeast of the country.

** in PCI terms a mechant is any business which takes payment card info, i.e not just shops, but websites, call centers etc.

I have been implementing an ecommerce project and have come up against the issue of PCI-DSS compliance. As the article mentions the 12 points are simple things that anyone handling card data or any personal details should be doing anyway.

However, to my personal grumble.... I have also integerated the ecommerce site with the 3D Secure (Verified by Visa and Mastercard Secure) programme. This is designed to make online transactions more secure, but because of how it works it requires that you collect the payment details from your customer, then get the customers browser to submit the payment details details off to an authentication server which responds with a couple of codes. You then have to append these codes to the payment details you collected earlier (before the users browser was sent off to god knows where) and send them off to your bank for processing.

Because of this 2 stage process it necessitates that the users card details and thier personal details are STORED somewhere before being dispatched to your bank for processing! Until this stupid system came into force ecommerce sites could get away with not persisting payment details (except in memory for a brief period), alas that is no longer the case.

In my opinion forcing ecommerce sites to store payment details is going to be the cause of an awful lot more breaches. PCI-DSS should be welcomed as a means of encouraging best practice, however 3D Secure does precisely the opposite!

</rant>

It's a crap standard and does little to make things truly safer. It's a good money maker for the compliance people - but that's about it.

Anon in case the bosses see.

PCI compliance for websites is a joke.

For many poeple who are using shared hosting for their websites, they are unable to get "PCI compliance" based on the scans that the credit card processors do, and then get mad when we tell them that they need a VPS or Dedicated system.

The scans themselves are also jokes, just the other day, got a scan, that the scanner said having port 80 open was a potential vulnerability.

User wanted us to kill port 80 on the server (not gonna happen), and didnt seem to believe it when told that his website would fail to function.

Actually I disagree with your survey, and as such have commissioned a superior survey in my office, where the results were that 50% of Britons live in the north of London. Apparently the other 50% live in the south of london, so I wonder who could possibly live in the rest of England..

However it was a proper survey, with 2[cough] million[cough] people quizzed (if half of those were one person asked several times it's all the same) and therefore our results stand as such. Your survey has been proved faulty.

On a side note apparently 100% of britons work in Banking according to a sub-survey against the same group... I guess we must have outsourced all the other services. But it was a survey, so it must be true....

Hmmm

The Anonymous Coward is right. That he should post as an anonymous coward.

Here's how you can comply and not have the problems.

You get a second machine to handle your database and CC information/processing.

You shut down all unnecessary ports, including port 80 and you only allow communication in to your box and out of your box to handle the cc processing.

You also make sure your site doesn't allow SQL injections. Then you'll be closer to PCI compliance.

Its a joke to expect to have web sites be PCI compliant and contain the web/app server and your back end data processing.

Sorry, but you're a sorry excuse for an architect if you couldn't see that.

PCI compliance is a joke intended to foist responsibility for credit card data onto small merchants and off the backs of the usurious credit card industry. Visa/mastercard are making more profits from most transactions than the merchant who actually bought and sold the goods. Perhaps they should be responsible for designing a better payment system

I keep getting these threatening letters from MC/Visa on a regular basis about the awful things that are going to happen to me unless I am PCI complaint.

They seriously talk about $250,000 fines and up.

Except I use a keyed manual terminal, my credit card processing isn't even on a computer. Doesn't need to be - low volume.

When I tell the PCI gestapo this, they say, oh, don't worry about it.

Then I get another even more threatening form letter. I think I'm going to start to use Google-checkout - costs less than the terminal I'm using now, and Google can fight with the PCI gestapo.

That'll be me, watching the fireworks from the safety of a concrete bunker off to the side.

65 elements in a sample is not unreasonable . . . if (and that's a BIG if) they are chosen randomly.

You would have to take the entire population under study, assign each one an ID number (sequential integers just fine), and use a good nota bene!) random number generator to crank out 65 numbers in the range 1-N to select your sample.

What's missing in the report, and makes Rainforestguppy's cynicism more reasonable, is any discussion of how precisely the 88% figure is determined by the sample. This is elementary statistics, but its absence from the report makes me wonder if a statistical ignoramus did the study.

[Footnote: the precision is almost entirely dependent on the sample size. See any elementary statistics text for the formulas.]

I used to "do statistics" for a living some of the time, and the more I learned the more cautious I became; it's a very easy field to make mistakes in. So easy, in fact, that if you are running a survey and want useful results, you are best off springing the money to have a knowledgeable firm or consultant do the work. Otherwise, your results have a very good chance of being meaningless.

Whilst on the face of it the advice seems sound, it is a bit more complicated than that.

If you encrypt data, then to use it again you have to decrypt, so if a server got compromised at a low enough level, it is highly likely they would have the key to decrypt.

Best really for smaller outfits not to take credit card data, but move it to a third party. Or, if they do take it run it off the system via an encrypted line, to a local holding area, which stores one way off the line.

You don't want to store credit card data live as an ecommerce site, unless you are really large, it tends to paint a bulls eye on you if you store CC data.

Patches, well now, some patches can introduce security vulnerabilities, and whilst the majority of the time it does work, who is now responsible if a patch introduces a security problem.

Really credit card companies can help by lowering the charges they make, and coming up with a delayed payment for those who wish to reduce the chargeback problem. So, if you say don't transfer funds immediately instead hold for a week on the card, and if the person wishes to chargeback then the cost of that chargeback should be lower.

They should also allow for a quick way to report fraudulent use of cards, and that should be secure and hard to abuse.

The problem is advice for security changes, no one is an expert working from the knowledge of generations in this field, it literally is being made up all the time. So, these so called standards can actually be more of hindrance than a help.

Credit card companies need to work more with merchants, and put in place better systems to track fraud, they need to stop offloading the problem onto the merchant and instead pitch in and help a bit more.

Banks and CC companies should set up a few small ecommerce outfits, mainly as trials but still real ecommerce, they should not pull any strings they have in the parent company, just sell some knick knacks, and see how hard it would be for a company to secure the site and still maintain business. I think that would be a bit of an eye opener for them.

As a hosting company senior admin, we get many requests from hosting customers to ensure their site passes PCI compliance tests (hacker guardian, security metrics, etc) and the test results are very obviously based on a simply Nessus scan which anyone could run.

The biggest signs of the certification being junk are the types of failures that they will not certify the site for such as the following real examples from a recent scan:

1. SSLv2 support in services including HTTPS, and just this past month they started failing sites for POP3S and IMAPS SSLv2 support.

(this is absolutely pointless because SSLv2 while available in any browsers or email clients, it hasn't been used as default since SSLv3 and TLS support was added 7+ years ago)

2. TRACE/TRACK HTTP method support

(This concern was entirely founded by a single person who wrote a paper about a very obscure way that this could be used maliciously, even though most industry pro's see it as a complete non-concern)

3. A stealth mail server running on a non-standard port

(pointless because we, like many other hosts, offer SMTP service on an alternate port so that our customers have use of it, without their ISP's blocking their ability to use port 25)

Yet real issues they aren't concerned with like unvalidated data being passed into PHP shopping cart scripts which result in exploit and other abuse code being fetched from an external URL and executed as a part of the site scripts, which is preventable by setting "register_globals = Off" in php.ini which of course some scripts are not compatible with this security enhancement, such as OSCommerce which is likely the most commonly used PHP Shopping cart.

Couldn't agree more. I went through the process of taking a site to PCI and 3D-secure compliance with a previous company, and the whole thing was just a money-making box-ticking exercise that wasted the time of our client, our developers, our hosting provider and our company.

None of the controls that were put in place would genuinely prevent fraud, and all they did was to ensure that the process of refunds and returns was twice as painful because customers had to be repeatedly contacted to get c/card details in order to process their refunds.

It didn't help the fact that the major banks (and I'm talking HSBC & RBS here, not some corner-shop outfit or 2-man online payment provider) had no clue themselves what was required for 3D-secure to work or be compliant. They threatened to close down our clients' payment transaction processing unless they were PCI/3DS compliant, but then repeatedly moved the goalposts over an 18-month process, meaning that having been told we were compliant, a threatening letter would then arrive 3 weeks later with another 100-day deadline for a slightly altered level of compliance. We eventually had it out with them, getting one of HSBC's PCI/3DS compliance 'experts' on-site in order to thrash out what their actual requirements/expectations were, and after 2 hours of us grilling him technically he left with his tail between his legs admitting that he and HSBC eSecure Payments didn't know the answers either, and would have to go and do some research.

The worst thing was that our client ended up losing several times as much business/profit due to the 2-3 multi-day outages of HSBC's ePayments system last year than they lose through fraud in an entire 12-month period.

The whole thing was a total shambles, and a waste of everyone's time and money.

PCI isn't crap, it's the implementation and administration that's crap. It comes largely of ignorance of the regulations and what they are supposed to enforce. Saying that PCI is crap is like saying that School is boring. Yes, maybe if you sit and stare out of the window all day, but you get what you put in mate. It's not supposed to hold your hand and wipe your nose and dry your eyes after you fall over, it's supposed to guide you and (heaven forbid) teach you a little something about security.

"Nine in ten (88 per cent)"

Why not just write "88 per cent"? Or even "88%"?

Your readers understand how percentages work.

If they expect retailers to comply then shouldn't the lenders comply as well?

I know of one of the top card companies in the UK that less than 12 months ago decided not to go through compliancy as it was too much work for too little gain.

a case of do as I say not as I do

RainForestGuppy, John Macintyre, RW and the 'Anonymous Cowards - you make some very valid points, which are always welcome. Allow me to address some of your ‘questions’:

Our PCI survey was sent to 6,260 IT Managers / Security Managers based in the UK, Ireland, the Nordics & Benelux. These were collated from a number of original sources that formed our contact data, which did include our customer database. In retrospect we perhaps should have stated NE Europe, not European.

144 surveys were started and we used the 65 that were fully completed. As we did not hold company size or other demographic data on many of the records we did not apply random/demographic selection in our targeting. We did however request basic demographic information which we are happy to share:

What is the annual revenue of your organization?

< 10 million € 15.3% (22)

11 to 24 million € 6.3% (9)

25 to 99 million € 8.3% (12)

100 to 249 million € 15.3% (22)

250 to 499 million € 12.5% (18)

> 500 million € 42.4% (61)

144/144 answered question

How many employees do you have in your organization?

< 100 12.5% (18)

100 – 499 16.7% (24)

500 – 999 6.3% (9)

1000 – 4999 21.5% (31)

> 5000 43.1% (62)

144/144 answered question

Country?

United Kingdom 23

Sweden 4

Norway 3

BeNeLux 23

Denmark 6

59/144 answered question

In addition to our own presentation of the data, we are to a degree in the hands of the journalist/blogger/writer, but for our virtualization survey due to complete today we will look to include demographics etc.

For those interested in the NetIQ approach: http://www.netiq.com/solutions/regulatory/pcidss/default.asp