Businesses Handling Credit Cards via Email

Question

I have done some I.T. contracting for a medium-sized Australian hotel recently. I am concerned about their credit card handling practices.

• Customers often email their CC number and expiry date in plaintext to the company.
• Customers also send CC details via a web form over unsecured HTTP from the company website. An ambiguous statement on the contact form could be construed as solicitation of the CC details.
• CC details are stored on two mail servers, managed by the company's ISP.
• All emails containing CC details are also stored on two up-to-date Windows 7 machines on premises, via Outlook 2007's Cached Exchange Mode. So even when computers are formatted or replaced, the CC numbers will end up back on the computers. Emails are never deleted.
• Deposits and all subsequent charges are made by a human operator from an EFTPOS machine on premises.
• There is an internet lounge on premises and it shares an internet connection with computers storing the CC details in Outlook. The staff computers may be on a different subnet to the lounge (haven't checked yet).
• I have not searched the email archive. However, it seems plausible to me that some customers may have supplied CVVs over email.

I found all of this disturbing, but I didn't know exactly how to make my point to management. So I've been doing some research.

• Email is not a secure channel for CC details [P].
• Mere acceptance of CC details via email places the business under PCI-DSS requirements [Q] and meeting those requirement may be a substantial task [R].
• Accepting and storing plaintext emails containing CC numbers violates the PCI-DSS [S].
• The above practice is risky, but common among hotels and probably many low tech businesses [T].
• Consequences can be severe [K] but enforcement probably won't occur unless the business is penetrated and their information is used for CC fraud [O].

I would appreciate any help to check my inferences for bugs. I'm also still unsure about two things.

1. Who enforces the PCI-DSS, in particular the fines mentioned in [K]? E.g. banks, or do government agencies get involved?
2. Does this vary much internationally? Might some info in the posts above not apply to Australia?

I'm also trying to think of a solution that won't collide too much with the current workflow (i.e. that won't cost a fortune). However, fixing this seems like a big task any way I look at it. Any perspectives on how to improve this situation would be much appreciated.

Answer 1

1. PCI-DSS is not enforced by any government; compliance is a requirement for handling credit card transactions in any way. Fines and exclusion from processing are two enforcement actions that can be taken. I'm not sure exactly who can definitively do what but the card brands, the acquiring banks, and the processors are the entities usually involved in either determining to do so or leveraging the enforcement. (For example, I believe card brands levy fines, but acquiring banks are responsible for collecting them - or making up the shortfall. Likewise, processors are tasked with collection by acquirers - or making up the shortfall. It's a system that encourages each tier to police those lower down, and the card brands don't get left holding any bills.)

2. No, this shouldn't vary much internationally. All the details you mention, which are essentially unencrypted public transmission and storage of Primary Account Numbers and Sensitive Authentication Data, are violations of the core principles of the DSS and aren't subject to localization.

As far as improving it, you can work with the merchant or you can blow the whistle (publicly, or privately to their processor/acquirer). Unless they're unusually receptive, none of these options works well for you, a contractor in a business relationship with them who has almost certainly signed legal contracts with them.

It sucks, but as you linked to earlier... "the PCI DSS structure is designed to encourage security and punish responsible parties, not to enforce security."

Answer 2

In Australia at least ( yes I know it's 4 am right now ) I am assuming that the provider of the merchant account is either cba , anz, or Westpac ( I have had experience in dealing with these companies ) and I am assuming that this credit card data is then being manually entered into a eftpos terminal.

The contract with those banks at least is very very clear that this style of process is a massive no-no and can lead to having the merchant account revoked. All it would take is one rogue employee.

They do provide "secure" online payment gateways but they charge a higher fee to cover the risk of fraud increasing. ( because you don't have a real person in front of you with a physical card in their hand ) the "manual entry" option is only there in the event of a card having a damaged magnetic stripe. ( and a relic leftover from pre electronic days )

End of the day if your voice is not heard on this issue then you can simply let the bank know , and they will deal with it

Answer 3

I didn't know exactly how to make my point to management

I know this sounds like a non-answer, but:

• It has been said that Management (the business) understand two things: money and risk.
• There is a cost of complying with PCI DSS (change/implementation costs, plus ongoing costs)
• There are risks associated with non-compliance (risk of fines, cost of investigation in the event of a breach, loss of reputation in the event of a breach and so on). Compliance should be treated the same as any other risk.
• It's up to the business to accept the cost/risk balance
• There may be ways in which the business process can be changed to prevent any need to transmit/store cardholder data, thus removing any PCI compliance issues. (Such as having staff phone customers for their card details and them putting them in EFTPOS at the time, as long as the call isn't recorded)

If you make the business aware of their reasonable options, with the cost/risk of each, then as long as they're well informed it's their decision what they want to do.