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."

PCI standards and real life

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.

Re:

Exactly.

I haven't worked with PCI specifically (although it's looking like I will soon) but I've seen the same sort of BS when working with telecom companies. They plop down a gargantuan checklist which is clearly the umpteenth managerial iteration over something that may have once been written by someone who knew what they were doing. Following the checklist does not mean that you are secure, but it is possible to be secure and also manage to check all of the boxes they want.

Re:PCI standards and real life

That's because PCI-DSS covers weak passwords but doesn't really test for them.

PCI is more about documentation and network layout than anything else. When my company did my audit they demanded segregated backend/ front end networks, SNORT machines on both and then followed up with a "pennetration test" that checked for common web server exploits and misconfiguration and the security scan actually encouraged us to hide all of the version numbers.

The upshot of all of this is that some of the things I had to do made things more secure but most of them were things that would look good on paper. I can still do things like not change passwords when people leave or put them on a paper I keep on a bulletin board and still keep my cert.

Re:PCI standards and real life

PCI standart adresses only the environment where card numbers are stored and processed. You can reduce this perimeter with appripriate segmentation.

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.

I suppose AIX servers were in PCI environment (otherwise your comment is out of scope).
Then the situation you describe probabely violates the following requirements:

req. 2.1: "Don't use default passwords"
req. 8.5.4 "Immediately revoke access for any terminated users."
req. 8.5.5 "Remove/disable inactive user accounts at least every 90 days."
req. 8.5.6 "Enable accounts used by vendors for remote maintenance only during the time period needed."
req. 8.5.8 "Do not use group, shared, or generic accounts and passwords."
req. 8.5.9 "Change user passwords at least every 90 days."
req. 8.5.10 "Require a minimum password length of at least seven characters."

About the fact that you can connect to servers from outside: that means no segmentation which in its turn means that the whole internet is to be considered as part of the PCI environment of this company.

Now please tell me by WHOM are they considered compliant?
Being financial institution means that they are provider (and may be merchant too) they certainly have to be audited by a QSA (self assessment questionnaire would not be sufficient) which could mean one of tho things:
The QSA did not his job properly
The company concealed things form the QSA

Re:

Well, financial institutions didn't care much about the safety of funds they have invested in, and that's their core business, why should they care about IT security?

I guess they couldn't have screwed up worse than they did, even if they had "1234" for all root passwords on their data centers.

Re:

The problem with PCI is that it's a great deal of expense and trouble attempting to overcome a fundamental weakness in the system: That the card number is used as identification and authentication and by itself is sufficient to process a charge.

For the inevitable car analogy, it's like removing the door locks and replacing the ignition lock on a car with a simple toggle and pushbutton, then equipping the garage with a $10,000 state of the art security system and calling it good enough (completely ignoring t

But when will consumers see additional security?

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.

Re:But when will consumers see additional security

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*

Re:But when will consumers see additional security

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.

Re:

I'm not convinced RFID makes much sense really.

With chip'n'pin there is cryptographic processing going on on the card to verify it's not being lied to by the shop or the bank. With RFID.... a number gets returned. Not so useful.

If you're referring to wireless EMV (or similar) then that's different, but is usually still going to be in card form.

Re:But when will consumers see additional security

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.

Re:But when will consumers see additional security

"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.

Check writing still rampant

Now I appeaciate that the US only recently moved away from Checks...

Moved away from checks? Hardly. Go to any grocery store in the US the day all the old folks get their social security checks and you'll see what I mean. Most bills still are paid by check despite the cost, inconvenience and inefficiency. Checks remain very heavily used in the US anywhere you go. Hell, Visa even has an entire ad campaign for their debit cards to try to get people to use the cards instead of writing checks. Visa wouldn't be bothering if checks weren't an incredibly common method of paym

Any advancement?

Real advancement would be:

* very very very hard way to physically clone a CC/DC;

* very very very strong encryption in communication;

* user-changeable authentication and authorisation, so it won't be enough to have just a copy of the data printed on the CC sides to make a purchase on internet.
Anything else, will simply suck as far as "security".

Re:

*very very very hard way to physically clone a CC/DC;

Done. Chip and Pin (or EMV as it should be known) makes it pretty impossible without an electron microscope.

* very very very strong encryption in communication;

Done. EMV cards use RSA to encrypt comms between themselves and the bank. Nobody else gets to read it. Online purchases are down to your e-tailer and their setup. Check your browser security bar.

* user-changeable authentication and authorisation, so it won't be enough to have just a copy of the dat

Re:

very very very hard way to physically clone a CC/DC

Actually, at least in Europe, it's already pretty hard to clone a debit/ATM card well enough that a modern ATM will accept them.

Did you notice the catch? "a modern ATM". That's why criminals only need to clone the magnetic strip (trivial) and get your PIN (also trivial), and then they send the data to their buddies in Eastern Europe to withdraw money using the not-so-modern ATMs used in these countries.

Self assessment

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. :(

Re:

Actually it does make sense; at least as much sense as the rest of the spec.

The third-party handling they are refering to is front-to-back order processing. The merchant only gets the actual order; at no point do they handle the credit card data. Lots of companies outsource their mail-order phone sales.

I definitely agree the spec is filled with ambiguities and contradictions though. Reading the article though I didn't see anything that should have constituted news to anyone in the industry. WEP has been kno

Is it a stick or a carrot and for who?

PCI was set up as an attempt to get merchants that don't care about security to consider it with out it being too hard and forcing them away from card payments. They pretend to have no conflict of interest yet the only way to get certified is by proving you do have a conflict of interest. Many of the ideas for standards tends to be controlled by people who want to micromanage how things are done (which means you can use their product). Some of the ideas tend to get implemented poorly just in a way to be

Ugh... I can hardly wait for 1.2

PCI really seems like a good idea, gone wrong.

It's getting more and more expensive and convoluted to abide by if you have to do more than the self-assessment. All the while, quite a few companies skirt by dangerously by faking it or lying.

It seems like we might all be a little safer if they toned the requirements down a bit in a few areas, but beefed up the auditing requirements on the fundamentals.

a/v for linux

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

Antivirus requirement

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?

Re:

I nearly had a stroke when I read that but thankfully it's a bad summary, The requirement is for machines "commonly affected by malicious software"

So my back end Linux servers will still not have AV software.

I'm not even sure why such a stupid rule even applies to windows really. A well maintained windows server should be safe from viral infection as long as it's not used for web browsing, email or file sharing. In other words nothing you would use a back end credit card processing server for.

Re:

You can find a better summary here: http://pcianswers.com/2008/10/01/pci-dss-version-12-differences-and-updates/ [pcianswers.com]

PCI doesn't provide actual security

PCI is all about encrypting credit card numbers and expiry dates - and nothing else. Even a fully-PCI-compliant system is a rich source of unencrypted information for Identity Theft.

Although the PCI security standards recommend to companies that they do criminal history checks on suspect employees working with credit card data (and a company I worked for, claiming PCI compliance, had a compulsory criminal history check on the first day for *all* employees even though they were working nowhere near credit card data) it still doesn't address some of the weakest links: the human operators and the GUIs that they use.

I recently closed a Buyers Edge credit card, operated by GE Capital Finance in Australia. I couldn't supply the "account password" to the telephone operator on one call, but after supplying other identifying information the operator was able to READ MY ACCOUNT PASSWORD BACK TO ME. What's up with that: displaying the password for the account in clear text on the screen? Why aren't they encrypted? Why don't they have an input to type potential passwords in to that says "Yes it's right," or "No, it's wrong"? There's nothing stopping employees from snooping through customer records to gather saleable information for the Identity Theft market.

The only good thing I can say from my experience is, "I'm glad my credit card with them is closed."