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

gdpr - panic part 2

Welcome GDPR friends :)

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

In this part, I am going to have a look at previous action the ICO has taken to give some context to the scary sounding 4% turnover or millions of pounds you will receive if you do something wrong. We obviously can't predict exactly how an enforcement action will go, but we can think about the sort of things we should be doing, before during and after a breach.

Talk Talk

We will start with Talk Talk and a breach they had in March 2016:


A customer found that they could use the password reset facility to access someone else's account and reported it to Talk Talk. Talk Talk fixed it but didn't notify the ICO. The ICO was notified by someone else and before GDPR this lack of notification resulted in a fixed £1000 fee.

Outcome: £1000 fine.

We then skip forward to October 2016:


Talk Talk bought another company, Tiscali which had a web app that was publically accessible and had an unpatched mysql database. Talk Talk didn't know that the app existed or was available.

Talk Talk bought Tiscali in 2009 and the breach happened in 2015. For 6 years a web site sat on Talk Talk infrastructure and no one knew it was there or that it contained customer data. The ICO wasn't very impressed with that.

A hacker exploited a vulnerability that was fixed in 2012 with a patch made available but as no one knew the site existed, no one installed the patch in the 3 years between patch release and attack.

The database contained personal data (name, address, dob, telephone number, email address, financial information) of 156,959 customers. The hacker accessed every single record. The hacker also accessed bank account numbers and sort codes of 15,656 customers.

The ICO didn't take the view that because Talk Talk didn't know about the application that it wasn't their fault and they should have been let off lightly. A common theme is that not knowing is as bad, if not worse than knowing and not mitigating.

The mitigating factors included the fact that Talk Talk notified the ICO, they helped with the investigation, they bought monitoring software for everyone involved plus they had already started an improvement programme. Still, they lost data that people had the right to expect to be kept private,

Outcome? £400K fine

It was almost at the top £500K but not quite!

Question: Are there any old applications on your network which contain customer data which you don't even know you have? Did any of your sales team do a POC with salesforce or something, send customer data over to it or stored data in a spreadsheet on a network share somewhere? These are the things that can cause you a problem.

Sticking with Talk Talk we zoom forward in time like bill and ted on some sort of excellent data spewing adventure to October 2017 and once again Talk Talk found themselves sat down for a chat with the ICO. There are a few historical enforcements that are interesting and should really be taken note of; this certainly is one of them.

In 2002, Talk Talk created a "web portal" to monitor complaints, back in 2002 we didn't have web apps we had portals! Talk Talk outsourced the managing of complaints to Wipro in 2014, but the portal was in use since 2002, presumably internally.

The managing of these complaints was both a business need and regulatory requirement of Ofcom as part of the 2003 communications act.

Wildly speculating, if the portal was delivered in 2002 for a regulatory requirement in 2003, I would guess it was probably rushed however that is just pure speculation.

The web portal used a username/password to access a publically available url, i.e. no VPN required. 40 users at Wipro had access to between 25,000 and 50,000 users personal details at any one time. Talk Talk managed the user accounts that Wipro could use to connect to the site.

Personal data, in this case, meant name, address, telephone and Talk Talk account numbers so no DOB, mothers maiden name, bank details etc.

Wipro had the ability to search using wildcards to find up to 500 accounts at a time, they could also export the result of searches to create reports which were used to meet Talk Talk's regulatory commitments.

In 2014, 12 years after first implementation Talk Talk began receiving complaints from customers regarding scam calls from people pretending to be from Talk Talk who were able to quote users addresses and Talk Talk account number.

In September 2014, Talk Talk commisioned an investigation and alerted the ICO. The investigation found three Wipro accounts which had accessed personal data of 21,000 users. The investigation found there was not a definite link between those downloaded accounts and the scam calls, i.e. it could not be proven that it was the source of the scam calls.

Talk Talk started mitigating the issue by writing to all of its customers telling them how to deal with scam calls. Talk Talk told the ICO what happened and they responded with their own investigation and the

Outcome? £100,000 fine

The reasons were:

- The system failed to have adequate controls over who could access which records, i.e. anyone could access any record not just the cases they were working on
- The exports allowed all fields, not just the ones required for the regulatory reports
- Wipro were able to make wildcard searches
- The issue was a long-running thing from 2004 when Wipro were given access until 2014

One of the mitigating factors was that there was no evidence that this was even the source of the scam calls, plus there is no evidence anyone suffered any damage or distress as a result of this incident.

So no one was harmed, a trusted third party was given access, and there is no evidence that anything bad came out of here BUT the system wasn't very secure and was generally not built with security in mind. Remember 2003 is a few years before Microsoft had their big security push and security wasn't really even thought about. Yet being a legacy app didn't buy Talk Talk any leniency.

£100K - I know there are applications out there where trusted 3rd (and indeed internal) employees have more access than this. This shows that even though you need to trust your employees, you still must make sure they can't go rouge and just start taking what they want. Do you have a sysadmin with unfettered access to everything? of course you do, everyone does - what does the ICO think of that? Do they think 4% of turnover or a slap on the wrists?

Talk Talk total fines £501,000 (you get a discount if you pay early) if the ICO use the same percentages to apply to GDPR then that is some big numbers!

The Historical Society

This is one of the other really interesting cases because it highlights that sensitive data might not be the things we normally think about like contact details or bank account details. This is heavily redacted, the most heavily redacted I have seen an ICO enforcement action. The redaction, for me, adds to the intrigue:


An admin officer left a laptop that was unencrypted somewhere redacted, there was a break-in and the laptop stolen with other things. The police did not recover the laptop.

The historical society bought the laptop specifically to be taken around to multiple sites so it wasn't a desktop meant to stay in the office, it was always intended to be carried from site to site in public. I wasn't sure why this was highlighted in the report but I think it shows that the ICO expect people to think about security in everything they do all the way from purchasing to losing the laptop in a redacted.

The artifacts were stored in four locations and the officer took the laptop home so they could visit one of the locations. The laptop contained, amongst other things, a list of individuals who had donated or loaned artefacts to the Historical Society including redacted.

The ICO imposed a fine and decided it was serious because of the sensitive nature of some of the personal data that was held on the laptop and the potential consequences. I take this to mean that someone owns something they probably shouldn't and would be publically embarrassed if that information was released. No date of birth, contact details but sensitive data over what someone keeps on their study shelf.

The ICO also knew the information hadn't been made public as they would have been out in the open.

One of the interesting things that everyone must take note of is that the ICO mentions that they published guidance on their website about inadequately protected devices such as laptops and this advice was not heeded and implemented - aka if the ICO do something, do it, you can't ignore them.

I point this out as the ICO have a checklist for GDPR, and I would expect if you can't demonstrate that you know and have completed this, during an investigation, it is not going to be looked upon favourably.

The fine was only £500, but if this was a corporation then you can bet this would have been higher, the ICO is not allowed to cause anyone financial hardship, each report has something along the lines of "The commissioner has determined that the amount of fine would not cause financial hardship" - We really need to see an action after GDPR is implemented, do they drop this?

I was going to have this as a two-part but there are some more previous enforcements I want to go over and this is already over 1,500 words so I will add a part 3, coming shortly.

What have we learned from Talk Talk and the Historical Society:

- Not knowing about a system isn't a reason to not be secure
- You have to be aware of your responsibilities and any guidance the ICO issues
- Sensitive data is not just bank account details
- Security starts before purchasing and ends when you have no data


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