One of the things people often ask me about in regards to software security is “Are there any standards that these people should be following? Any governing bodies? Any recourse for screwing things up?” Ok, that’s three things but you get the idea and people are usually pretty surprised when they learn that for the most part, no. No standards, no governing bodies, no recourse. You can go and create a new website today storing everyone’s credentials in the clear, send them around willy nilly via email then get pwned big time and short of whatever reputational damage is done, there’s no recourse whatsoever.
Case in point: last year I wrote about how Tesco screwed up pretty much every conceivable web security pattern known to man. It was so bad that the Information Commissioner’s Office in the UK investigated them and… did nothing. In a way that’s understandable as to the best of my knowledge nobody actually incurred any sort of loss or harm as a result of dodgy coding. On the other hand, the premise that a multi-billion dollar organisation can so haphazardly stand up software that had a good likelihood of doing damage to customers (and you just know those customer passwords are going to unlock a whole heap of other accounts…), is a bit alarming. And that’s the real problem – no disincentive not to screw up.
Unless you’re talking about credit cards. Now the rules changes and it’s always good to demonstrate these things by example so let me start with this:
That’s right, as part of their ongoing commitment to protect your security you need to email all your personal details. It’s for your own good, y’know!
This was sent to me by fellow Aussie MVP David Burela who thought it all a bit odd. In fact for anyone even remotely conscious of online security it just doesn’t feel right. Here’s the important bits that they want you to send in email:
- Driver's licence (Australian or foreign)
- Recent Utility Bill (name and the billing address needs to be visible)
- Credit card statement (cardholder name, card billing address and card number needs to be visible.)
You know how sending anything sensitive via email is a big no-no? And there are even websites dedicated to naming and shaming the minor misdemeanour (relatively speaking compared to financial data) of emailing passwords? What you’ve got above is an identify thief’s wet dream of personal data and this information would be extremely useful for all sorts of nefarious activity. It’s also quite valuable in a direct monetary sense; it’s the sort of thing evildoers turn around and sell on the underground criminal forums. Let’s delve into the many shortcomings of email.
Email is not a secure storage facility!
So why is email so bad and what’s the obligation of websites such as BIG W? Well firstly there’s (almost always) no encryption in transit for email so as those packets are flying around the web the first assumption needs to be that at some point they’ll be intercepted. Once they’re intercepted and unlike using a protocol such as HTTPS in the browser, the data will be easily read as there’s no encryption. That’s nasty, but we’re only just getting started.
Next is the fact that “email” makes no assurances as to how it’s protected in storage. I say “email” because we tend to speak very generically about something that has many very, very specific implementations. I would be quite trusting of Google’s ability to protect unauthorised access to email within their environment (other than the fact that they read all your mail – oh, and so does the NSA) but as for the hundreds and thousands of other mailbox services set up across the globe – not so much. You simply cannot expect email to be stored securely anywhere and that includes in your sent items.
Here’s another one – got a smart phone? A tablet? A native email client such as Outlook on your desktop? There’s another three places probably holding copies of your email. Two of these are very mobile and are devices that are frequently left unlocked in cafes. Email is one of these services that we now tend to refer to as “cloud based” insofar as it’s frequently stored somewhere centrally and auto-synced across devices to create a seamless user experience. It’s great for convenience and really maximising your risk surface!
So email is an utterly useless secure storage facility, but what are the consequences? What happens when a company orchestrates the delivery of something like credit details over this most insecure of channels? This is where PCI comes into being.
PCI DSS
A bit of credit card 101 before I go on: You’ll be familiar with the likes of Visa, American Express and MasterCard (among others) and whilst for the most part they’re competitors, they do agree on a few things. One of those things was the formation of the Payment Card Industry (that’s the PCI bit) which in theory is an independent body designed to support the industry in a few different ways including by defining Data Security Standards (that’s the DSS bit).
PCI DSS lays out a bunch of standards for how card data should be handled and in theory, if you process cards, you must adhere to the standards. Some of it is a bit airy fairy but other parts are actually quite tangible and easily assessed, particularly in cases like we have above which I’ll get back to shortly. An easy way to get to grips with all this is to take a quick flick through the (actually quite easily understood) PCI DSS Quick Reference Guide. Here’s the important bit in the context of this post:
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Cyber criminals may be able to intercept transmissions of cardholder data over open, public networks so it is important to prevent their ability to view these data. Encryption is a technology used to render transmitted data unreadable by any unauthorized person.
4.1 Use strong cryptography and security protocols such as SSL/TLS, SSH or IPSec to safeguard sensitive cardholder data during transmission over open, public networks (e.g. Internet, wireless technologies, Global System for Mobile communications [GSM], General Packet Radio Service [GPRS]). Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment use industry best practices (e.g., IEEE 802.11i) to implement strong encryption for authentication and transmission. The use of WEP as a security control is prohibited.
4.2 Never send unprotected PANs by end user messaging technologies.
A PAN is a primary account number and an end user messaging technology could be a whole range of things that we – as end users – talk to one and other with. In other words, don’t email your damn credit cards around!
I couldn’t write about PCI without pointing out something that those in the industry regularly bemoan; PCI keeps auditors happy but it in no way means that an environment has achieved that mythical state of being “secure”. Many people view compliance as a very academic exercise and they may well be right about that. The real issue seems to be not that PCI DSS itself is bad, rather that it alone is insufficient – you can’t just be compliant and say “Ok, job done”.
Regardless, the handling of credit cards over insecure channels is a big no-no in anybody’s books (well at least anybody with a half a clue on the risks), question is though, what happens when you screw it up?
Recourse
Ok, so you’ve gotta protect financial data in transit, thank you Captain Obvious. But what happens when you don’t? I mean what teeth does PCI actually have in terms of causing pain for those who breach their guidelines?
A few years ago Visa decided to help itself to more than $10M from Genesco for breaches of PCI DSS. Ten-million-dollars. Crikey, that’s a lot for not encrypting your data! As you’ll read in that link, Genesco has since turned around and argued that sending unencrypted data was cool and that in return it would like about $13M back from Visa. Yeah, good luck with that guys…
Another good indication of potential fines is over on the Barclaycard site:
Fines will be levied in all cases where merchants are the subject of a security breach and upon investigation are found to be non-compliant. The average fines levied for a small merchant total around £15,000 which is payable on top of any forensic investigation and remediation costs.
Not quite $10M but then Genesco had revenue of a couple of billion so pro rata that’s the same sort of impact on a company bringing in somewhere in the order of $5M annually – and that’s for a small merchant.
Interestingly enough though, when I asked around it wasn’t particularly easy to find precedents of a payment card provider slapping fines on companies in breach. In fact the word from those in the know was that this was the sort of thing that’s normally kept very, very quiet and you can understand why. Short of any public notification responsibility (and I’m not aware of one within the PCI framework), the likes of Visa and MasterCard don’t particularly want to announce that one of their merchants is engaging in risky business because after all, they don’t want to jeopardise that business and more importantly the merchant fees they receive. No, it’s in PCI’s best interest and obviously in the best interests of the organisation handling the data to keep everything nice and quiet whilst they silently fix their shoddy security.
And what of BIG W? A moment of reflection on what it means to protect customer security would be a good start and if the penny doesn’t quite drop, they could always ask their payment providers what they think of the practice…