Sophos Cloud Optix
A UK travel company has been fined £150,000 by the Information Commissioner’s Office (ICO) for leaking more than 1,000,000 credit card records.
Here’s what seems to have happened.
Imagine you’re a web developer.
You’ve been told to knock together a quick database system, for internal use only.
The software needs to keep track of a car parking business that your employer operates, but it won’t store customer data or be customer-facing.
You might take a path something like this:
- It’s internal only, and won’t have any personally identifiable information (PII), so you might as well code now, secure it later.
- It’s internal only, and pretty basic, so it’s not going to get budget for its own server, so you might as well dump it in a corner of the main database server.
- It’s simple enough that it works, so everyone uses it.
That’s when the trouble starts, thanks to the last part of Item 1, “secure it later.”
Because of Item 3, you get lumped with Item 4:
- It’s internal only, but people need to use it from home.
So you knock up a quick authentication page and open it to the outside word via a “secret” URL.
You reason that the crooks first have to work out where to connect and then to crack a password, and even if they do, they’ll not get much more information than how much your parking spaces cost, which they could probably find out by phoning for a quote anyway.
Back in real life, of course, a crook does eventually work out where to connect (a bit of Wi-Fi sniffing might do it), has a poke around, and quickly realises he doesn’t need to login at all.
He finds can use SQL injection, where he sends a query with a database command hidden in it, and tricks the server so it doesn’t use the command as a search term (which would be harmless), but actually runs it as a command (which is not harmless at all).
From there, the crook can give himself access to the database administration console, and since your cark park application is on the same server as your main e-commerce site, he can help himself to all the data in it.
To wit: 1,163,996 credit card numbers dating all the way back to 2006, of which 733,397 have already expired, but 430,599 are current.
I’ve made up the details (except for the numbers – there really were more than 1,000,000 credit card records spilled), but that’s probably roughly what happened at Think W3 and its subsidiary, Essential Travel Ltd.
We know this because the ICO explained the reasons for its £150,000 fine, concluding that the company violated what is the UK’s Seventh Privacy Principle.
There are eight Privacy Principles altogether, requiring that personal information is:
- Fairly and lawfully processed.
- Processed for limited purposes.
- Adequate, relevant and not excessive.
- Accurate and up to date.
- Not kept for longer than is necessary.
- Processed in line with your rights.
- Secure.
- Not transferred to other countries without adequate protection.
Interestingly, the company wasn’t taken to task under Principle Five, which deals with the timely deletion of redundant data, such as as long-expired credit card numbers.
Presumably the ICO felt that Principle Seven was the more important one, and wanted to make a very blunt point.
Here it is: “Secure it later” isn’t soon enough.
The more fundamental issue is that the web developer should have set procedures in that even if is needed quickly, ‘secure it now’ should be a priority. And that goes back to the management of the firm, not the web developer himself. Always assume everything will be external at one point.
Agreed – I didn’t mean to imply that the web developer should carry the can for this one.
The ICO agrees, too, by the way. If you look in the PDF of the actual penalty notice (the link in the article where I wrote that the ICO “explained its reasons”), you’ll see that’s how the regulations work. The company that owned the company that ran the insecure authentication page is deemed to be the “data controller” and the buck stops there.
And I also agree that “secure it now” should be a given. As fellow Naked Security writer Chester Wisniewski likes to say, “The first rule of firewalls is that there is no ‘inside’.”
A fine amounting to 35p per active credit card…seems a little lenient to me!
Seems to be about the going rate for a breach of this sort. I suspect that the ICO is trying to avoid making it into a “cost per card,” on the grounds that the company would have been just as sloppy if there were 500,000 cards of which only 100,000 were still valid, or 10,000 out of 50,000. (It wasn’t just cards, it was customer PII like address, phone number, name, too.)
I think the idea is to issue a fine that hurts, but does not maim, so the company can afford the fine, keep on trading, and have something left over to spend on doing security better. It’s not meant to take them down.
Also, IIRC, the company did voluntarily disclose the breach, for which IMO it deserves some slack, just like crooks who plead guilty to criminal charges generally get some time off because they faced facts.
So apparently, your credit card is barely worth 0.15 pounds to the company holding the data? Good to know.
Well, that’s not the purpose of the fine, and it’s not how it was calculated…
i won’t!!!
This is not fare.