Slashdot Mirror
Credit Card Security Standard Issued
alphadogg writes "The Payment Card Industry Security Standards Council, the organization that sets technical requirements for processing credit- and debit-cards, Wednesday issued revised security rules, while also indicating next year it will focus on new guidelines for end-to-end encryption, payment machines and virtualization. PCI adherence has been pushed big time in the industry to help avoid more big breaches such as the one involving TJX. Those familiar with the standard say it could be expensive to implement and that there are some things those using wireless LANs will need to pay especially close attention to."
I don't know how many reading this have been through the whole PCI thing. Personally, I think that it is pushed by folks that are selling 'scanners' and other remediation software.
I believe that security standards are a good thing. I appreciate that PCI has helped many environments be more secure. However...
I have worked in 3 unix shops that were devoted to E-Commerce. Currently, I'm really impressed with the company that I work for and how they do things. Unfortunately, I have seen things that most Unix admins/Security admins would have nightmares about in some other places that I have consulted. Yet, no matter what security flaws are there, they always passed.
I shudder when I think of one company that I worked with. They are a very high level financial institution. Guess what their AIX HMC passwords are? Can you get to them from the outside world? Yep. Could I down their production servers, a year after I worked there? Yep. Are they considered compliant to DSS/PCI standards? Yep.
Consumers in the US in particular are hugely behind the curve as far as end to end security goes. A lot of Credit and Debit cards are still being issues without Chip & Pin. Yet worse for some mind boggling reason Credit Card companies have started installing RFID into these cards.
In the EU, the UK in particular Chip & Pin is mandatory while RFID is nowhere to be found. Now I appeaciate that the US only recently moved away from Checks and still have a very questionable Direct Debit (bank to bank transfers) system in place but you would think one of the worlds leaders wouldn't be one of the worlds losers in terms of card security and fraud protection.
I think you answered your own post. The EU is more up to speed because security has been regulated (fraud is the merchant's problem in the US, not the bank or processing network). Card issues care less about security and more about transaction volume.
I can't explain why our banking system sucks though. I would've thought we'd be ahead of the curve when it comes to moving money electronically. *shurgs*
RFID is everywhere in Europe - just not on the credit cards. Yet. But the situation is changing.
The US is skipping on the chip-n-pin because it makes sense for them to jump directly to the RFID cards, which are physically more durable, and allow for different form factors (like mobile phones or keyfobs).
The RFID card security problems currently can be attributed to flawed security design, not to the technology itself. We trust TSL over WiFi, and WiFi is far more easier to skim than RFID comms.
You misunderstand the system.
Credit card companies and banks make money from fraud. You (as a customer) pay for insurance that they use to cover the fraud. They have no incentive to change. Changing will just cost them money and won't affect their bottom line.
At least, that's been the situation for decades. However the consequences of handing billions to criminals is starting to have an effect. The criminals have billions in assets, and can leverage those for bigger and bigger forms of fraud, and they are.
I don't really want to hear any more of this crap about how they're going to "segment" my secret pieces of information behind a firewall. The whole system is a house of cards, built on "secret pieces of information" and heuristics about the kinds of transactions fraudsters perform. Once someone has stolen all the relevant secret pieces of information, all bets are off and the system has failed. These "secret" pieces of information are not hard to obtain, and adding more secret pieces of information (i.e. CVV2) is absolutely not a solution. I want end-to-end encryption and transactions which don't need to be perpetually stored in a database alongside my secret pieces of information.
In short, I want electronic, encrypted cash. When my wallet is stolen and not worry that I will lose any more than the cash actually in the wallet. I don't want to have any more transactions denied because I traveled to a foreign country.
But most importantly, I want to take those billions out of the hands of criminals.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
As a small company who has recently been through the self assessment procedure, I can say that the guidelines are very poorly designed in many cases.
For example, on the instructions page (https://www.pcisecuritystandards.org/saq/instructions.shtml) there is a link to SAQ Validation Type 1 form (A) and describe the type of applicant thus:
"Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants."
But in form A part 2c it states:
"Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handles these functions;"
By answering yes to this question, a merchant is saying that they will not transmit the details on (i.e from, to or within) their premises. This would mean that e.g. a mail or telephone operator could not *transmit* the card details to a third party service provider. i.e. they cannot use the PAN in any way (they *can* store it on paper - so orders by mail are OK), but the requirement very specifically says "Merchant does not ... transmit any card holder data on merchant premises". If I cannot transmit this information on my premises I cannot send it out to our service provider for processing etc.
This does not make logical sense. In theory, I could process payments via a PDQ machine directly connected to the phone line system and as the phone company is a "third party service provider" this could be argued to be compliant, but if I send it via e.g. an HTTPS website to an application hosted by our hosting company, this is technically going through our internal network before going through the wider internet (albeit encrypted via SSL) to our third party service provider. This is clearly "transmission on merchant premises".
I'm probably interpreting things quite pedantically (but isn't that what you're supposed to do with this kind of security thing?), but the guidelines and forms are riddled with these ambiguities and contradictions. :(
"Credit card companies and banks make money from fraud."
Not in the UK they don't. Oh sure, they probably have it insured, but until recently the liability for loss (where they couldn't prove the merchant or customer was complicit and don't catch anyone) was all theirs. This is because they supply the tech, they mandate the schemes, they set the standards.
EMV goes some way to what you want, there is encrypted information sent between the card and the issuing bank that nobody else can read, but is dependant upon PIN. The biggest hole in the scheme is that you are still allowed to fall back to magnetic strip transactions in some places. They tend to be where the fraud is done now.
For instance, it clarifies that all operating systems associated with card processing have to run antivirus software, while many had thought this was only about Microsoft Windows.
great, now I have to run ClamAV on all my fully-patched and secured dedicated web servers that don't store CC data anyway. I thought about writing my own AV program:
#!/bin/sh
echo "scanning for viruses..."
sleep 10
echo "no viruses found."
exit 0
From TFA:
For instance, [the PCI revision] clarifies that all operating systems associated with card processing have to run antivirus software, while many had thought this was only about Microsoft Windows.
"That sounds like a sensible piece of advice," says Sushila Nair, product manger at BT, who says organizations often deploy antivirus on Windows but erroneously believe Unix and Macs and other operating systems are somehow more invulnerable. However, she notes accommodating the clarified PCI rule on antivirus in many places will be "expensive."
So what would constitute compliance with this rule? Is running periodic ClamAV scans on my Linux server sufficient? Will saying that I have ClamAV installed on the audit form be sufficient to comply with the new rule?
This change seems to have as much to do with protecting the Windows franchise from erosion by *nix systems (in the name of "levelling the playing field") as it does with security. Not only does it ignore the very real differences in security among the various platforms, but it makes selling a Windows solution to upper management much easier than selling Linux. Of course a system with a Windows server and Norton or McAfee will pass muster. Linux+ClamAV? Who knows?