SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

gdpr - panic part 3

In part three of this short series

Part one is: https://the.agilesql.club/blogs/Ed-Elliott/2018-02-01/GDPR-Panic-Part-1
Part two is: https://the.agilesql.club/blogs/Ed-Elliott/2018-02-01/GDPR-Panic-Part-2
This is part three: https://the.agilesql.club/blogs/Ed-Elliott/2018-02-01/gdpr-panic-part-3

In part two I started looking at previous enforcement action taken by the ICO, Talk Talk (3!!! times) and the historical society:


In this part, we will start by looking at the Royal & Sun Alliance Insurance PLC from January 2017:

Royal & Sun Alliance


The RSA has a data centre in Horsham, West Sussex - I only mention this as I live nearby.

In the second half of May 2015 someone who had access to the room stole a NAS device.

Whoever took it had a key card to get in, i.e. it was a secure area. However, 40 of RSA's staff and contractors (some of whom were non-essential) were permitted to access the server room unaccompanied.

This for me is the key here, letting people do more than they need to - it is a common theme amongst a lot of the actions.

The Nas device had (among other things):

"personal data sets containing 59,592 customer names, addresses, bank account and sort code numbers and 20,000 customer names, addresses and credit card ‘Primary Account Numbers’. However, it did not hold expiry dates or CVV numbers"

The device was password protected but not encrypted. This is key - if the data was encrypted and stolen not so bad. The ICO decided here that the lack of monitoring of the device and its whereabouts and disappearance was a problem.

The server room didn't have CCTV monitoring, non-essential staff could access it if instead of the 40 people, 5 people had access then it probably wouldn't have happened.

The ICO considered it an ongoing issue as they first installed it in April 2013 and until 2015, before it was stolen, it was un-encrypted and non monitored.

The ICO said they had no evidence the data was ever even accessed, it might have been a cleaner accidentally spilt coffee on it and chucked it, but the fact they don't know what happened to it is a problem. When the RSA notified its customers there were 196 complaints to the ICO. The ICO, therefore, fined RSA £150,000 and it would have been higher if they hadn't voluntarily taken substantial remedial action.

Outcome? £150,000 fine

The next one is the Carphone Warehouse, who were fined a stonking £400,000.

Carphone Warehouse


Carphone Warehouse had a set of virtual machines which they hosted internal and external websites. Someone used the admin wordpress account on one box to upload some code that gave them access to the box and then the ability to find and download a large amount of data.

In this case, it wasn't that the incident happened, as much as the generally poor security around the incident that led to such a big fine.

- There was no WAF (web application firewall) in-front of the applications.
- The attacker used an off the shelf hacking tool to find vulnerabilities that it could use to "very quickly" gain access and steal data.
- It took them 15 days to discover there was an attacker on their systems
- They don't know what data was stolen so have assumed the worse, all of it
- The attacker found credentials in plain text to the systems it needed
- The wordpress installation was from 2010 and hadn't been patched in six years
- Patch management was not being followed at all in that business area
- The system was accessed using valid credentials but they had no credential management to know who could have used the credentials or who even knew what the credentials were.
- They have no pen testing or vulnerability scanning procedures
- None of the systems had anti-virus on even though there was a policy to implement av
- The servers in this VM farm all had the same root password which was known by 30-40 members of staff. Carphone Warehouse couldn't give a good reason why this wide-ranging access was allowed
- The system contained historic financial data like credit card numbers as an external developer started logging it as a temporary measure and forgot to turn it off again. Carphone Warehouse said it was not aware of this storage and the ICO told them that not knowing about it means that they had an "inadequate understanding of its IT systems, architecture, at least in terms of locations of personal data on those systems." Ouch and "Without an adequate understanding of these issues, security arrangements were likely to be inadequate" and double ouch!
- The historic transactions were encrypted, but the keys were stored in plain text in the application code.

The personal data stored in the applications were:

- 3,348,869 customer records with full contact details, marital status, phone numbers, current and previous addresses
- 389 customers across two other companies
- Historic financial transactions including name address, expiry, and all card numbers (PAN, CID, CVC2, CVV2)
- Approximately 1,000 employees details including contact and car registration numbers

So they suffered from a general malaise in security and had almost 3.5 million customers personal details stolen.

I am going to finish up this part (and now make it a four-part series) by looking at what happens when instead of being a bit poor and being attacked you are on the other side of the fence, up to shenanigans.

Outcome? £400,000 fine

Keurboom Communications Ltd

Keurboom is another company part of the £400,000 club.


Keurboom used an automated dialling system to make over ninety-nine and a half million phone calls in one and a half years. They would call the same number repeatedly in the same day and at unsocial hours and often couldn't event connect someone if they wanted to be put through. The calls were typically about PPI and gave the impression of being urgent, upsetting anyone who was in the process of dealing with a PPI claim or road accident.

The ICO was happy that they did not mean to upset anyone but the calls were made without prior consent and they were made deliberately on a massive scale.

Outcome? £400,000 fine

I really feel that post-GDPR Keurboom would have been hit a lot harder, let's hope so!

So, that is enough for this part in the final part I will look at some interesting uses of telematching by charities and a couple of household brands who got a bit exciting with their outlook address book.

Part one is: https://the.agilesql.club/blogs/Ed-Elliott/2018-02-01/GDPR-Panic-Part-1
Part two is: https://the.agilesql.club/blogs/Ed-Elliott/2018-02-01/GDPR-Panic-Part-2
This is part three: https://the.agilesql.club/blogs/Ed-Elliott/2018-02-01/gdpr-panic-part-3


Ed Elliott's Sql Developer Blog

Ed is a Sql developer who has a mixed background in support, as a dba and as a developer working with a number of languages c, c#, vb, go, assembly with a variety of technologies and is currently trying to make the sql developer community a little bit more agile, one build step at a time!


Leave a comment on the original post [feedproxy.google.com, opens in a new window]

Loading comments...