Data Breach Handling – 3 recent examples.

Data breachYou might remember that last year, Yahoo! were shown to have suffered a data breach not once, but twice which led to the personal data associated with ~1.5 billion accounts being stolen by evil doers. This was a pretty massive story at the time and it was widely reported.

Data breaches occur on a frighteningly regular basis, which may not necessarily make it into the mainstream press and is simply discussed among cyber security and data privacy types, but with the impending EU General Data Protection Regulation (GDPR) coming into force in May 2018, all organisations will need to be aware that they will be bound by the breach reporting aspects of the GDPR, specifically Articles 33 and 34.

So in this post I take a look at 3 data breaches that have been reported on this month, which occurred to some well known organisations.

The AA Shop data breach:

First up is the Automobile Association (AA) in the UK. They were notified back in April that backup copies of their customer databases were publicly available on a cloud service, which they took down fairly promptly. However they did nothing more at that time. They were subsequently notified that details of over 100,000 user accounts from their on-line Accessories Shop had been exposed, which they did acknowledge, blamed a third party service provider, but claimed that no sensitive data or credit card information had been leaked as a result.

However security researchers begged to differ and provided evidence of partial payment card information being exposed as well. By 7th of July the AA had to make a grovelling apology and properly set out their position. Interestingly this apology does not show up on Google searches, but is buried in their website. 😏

The Information Commissioners Office (ICO) in the UK have now become involved in the matter and, while I can’t pre-judge the outcome, I would expect the AA to get some sanction for such awful handling of such a serious matter. If the GDPR were in force, the financial penalty for this handling would likely be much more significant, because they would be in breach of Articles 33 and 34.

Bupa’s rogue staff member causes a data breach:

Next was Bupa, the health insurance provider in the UK (and formerly of the Irish Market). An employee of their international health insurance division Bupa Global had made a copy of personal data belonging to 108,000 insurance policy holders and removed this copy from their offices. In their notification to their customers, Bupa states:

The information does not include any financial or medical data, and relates to a portion of customers with international health insurance.  …

We are contacting those policy holders who are affected to apologise and advise them as we believe the information has been made available to other parties. The data includes: names, dates of birth, nationalities, and some contact and administrative details including Bupa insurance membership numbers.

On discovery of the breach, they immediately dismissed the employee, then at some point notified the ICO, the Financial Conduct Authority and the Police. They also state they’re tightening up procedures. Their website gives a full, clear outline of what happened, what steps customers can take to protect themselves, an e-mail and dedicated phone line for more advice. This even shows up on a Google search. 😃

Bupa handled this incident extremely well and were upfront and honest about what happened. From a GDPR perspective, the only area of concern is the timeframe for them to notify the ICO? This is not clear from my research. It seems that Bupa became aware of the incident in or around the 23rd of June, but customers were not notified about it until the 12th of July. It’s possible they did notify the ICO in good time, but when the GDPR rolls into town, they will need to have done so within 72 hours of discovery, in a case such as this. This is definitely an example of how a data breach should be handled … kudos to Bupa. 👏

The Swedish Government’s data breach:

You read that right – a Government has had a data breach and this one is significant, deeply embarrassing and potentially life-threatening 😲. The Swedish Government is desperately trying to keep this under wraps, but it’s such an omnishambles they can’t even do that right. Expect to hear more on this in due course, here is some initial reportage.

The background to this is that back in 2015, the Swedish Government’s transport agency outsourced the managing of it’s databases and networks to IBM, who placed all of this in the “cloud”. These databases contain the details of every vehicle in the country, including those of:

  • Private citizens
  • Police
  • Military
  • Special Forces*
  • Individuals in Witness protection/relocation programmes*

*This is the reason I said that this breach was potentially life-threatening – their identities must be kept secret.

The non-secret parts of these databases are considered public information and are regularly provided to marketing companies who subscribe to receive the lists.

So what happened was that somebody in IBM sent an e-mail with a copy of the entire database (secret and not-secret) to the marketers. This was a huge mistake on it’s own. What they should have done next , was e-mail a copy of the database with the not-secret information in it and instruct the recipients to destroy/wipe the previous e-mail (perhaps throw in a threat of national security, etc.) But what they actually did was much, much, much more dangerous.

An IBM agent sent an open, clear text (i.e. not encrypted) e-mail, which could potentially be intercepted, to the marketers pointing out and identifying the secret records and asking the marketers themselves to remove them from the database. 😡 THIS is why this has got to be the most embarrassing and dangerous data breach imaginable at this time.

Other databases that were outsourced include ones that contain the weight capacity of all roads and bridges (which is crucial for warfare, and says a lot about what roads are intended to be used as wartime airfields) and another which stores the type, model, weight, and any defects of any and all government and military vehicles, including their operator, which says a great deal about the structure of military support units.

The very fact that these databases were outsourced to IBM, who stored them in data centres in Eastern Europe (Czech Republic and Serbia) without any apparent security controls, means that Swedish military secrets have been exposed to foreign entities. This is simply intolerable.

If this happened after May 2018 when GDPR is in place, I’m not sure what would happen to the transport agency, but IBM, as a data processor, would certainly be likely to be severely sanctioned by being hit with a big financial penalty. They could also be exposed to being sued by individuals for distress, as a result of their secret identity being revealed. It simply boggles the mind how awful a service they provided here.

Conclusion:

Give data breaches some consideration in your organisation before the GDPR comes into effect. Come up with a plan to handle them in keeping with Articles 33 and 34 and be sure to test that the plan works for you. You don’t want to be like The AA or worse, like the Swedish Government/IBM.

You can find out more about the GDPR here and if you want to contact us to learn how we can help you then simply send an e-mail to info@L2CyberSecurity.com or call us on +353-87-436-2675.

Leave a Comment