2

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.

Community
  • 1
  • 1
    Perhaps you should just put this on the web, except include the name of the company. Then tell the company you saw it, and they're going to be hit by a cyber attack and lose all of their customers if they don't upgrade their security. I guarantee this is effective, although not exactly honest. – KnightOfNi Feb 18 '15 at 02:24
  • I found your idea hilarious, but also insightful. I have softly mentioned PCI-DSS to deaf ears so far. However, I agree that everything would change if cyber attacks suddenly became real. –  Feb 20 '15 at 14:25

3 Answers3

5

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

Community
  • 1
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Gowefawr is correct on each point. In terms of addressing the solution, you could add a statement to all email signatures that customers should never send cardholder data then educate staff to sanitise emails received containing card data. Encrypt existing repositories containing card data if you cannot delete it. Disk or volume encryption is a good start. Use a Property Management System that will secure card data. Pre-authorise cards for payment so you're not storing sensitive data. Good luck! – AndyMac Feb 18 '15 at 01:51
  • Interesting perspective. Thanks a lot both of you for your insight. I can see this is somewhat complicated and I will continue to assess the situation as it develops. But it's good to know that at least my assessment of their practices isn't way off. –  Feb 18 '15 at 08:27
0

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

Damian Nikodem
  • 769
  • 4
  • 8
  • This is a good point. I have seen a couple of businesses over the years using manual entry this way. I wonder whether people don't realise or don't care (or both). –  Feb 19 '15 at 01:33
  • Some dont know any better, some might have its not right but think that they are 'trustworthy' (therefore they dont care) some have this 'grandfathered' in from ancient practices ( e.g. pre electronic credit card transactions, where you could take a credit card number over the phone for a 'deposit' then physically take a form to the bank to deposit the cash into your account. ) And the last (and worst category, I know of one rather successful buisiness a 'one man company' 500k per year, 300-400k online which operates in this way. ) is those who _DO_ know better but do it anyway to save money – Damian Nikodem Feb 19 '15 at 06:00
0

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.

hmallett
  • 193
  • 7
  • Yes I agree. I've been researching this frantically. My opinion at the moment is that PCI scope reduction (all the way to zero) is the best option for a level 4 merchant. I believe this boils down to legitimate card-present-transactions only; or if that's not possible, a tokenised solution (e.g. using Stripe tokens via a web app for card-not-present transactions). I'm not currently equipped to make a merchant PCI-DSS compliant. However, I am researching this constantly and working with a colleague to build a compliance solution that I can offer to smaller merchants. –  Feb 20 '15 at 13:56
  • PCI DSS requires a considerable investment. Avoidance of storing/transferring PANs is by far the easiest solution. – hmallett Feb 20 '15 at 13:59