The Attack Surface of Data

Yesterday Lorenzo Franceschi-Bicchierai broke the story that VTech's "Learning Lodge" app store database had been hacked. Lorenzo's story for Motherboard has the details and Troy Hunt provided the detailed analysis.

Long story short, attackers managed to gain access and leak data on 4.8 million accounts, including over 200 000+ profiles of children. Worse, the data contains enough information to easily locate the children in the real world.

I wrote about VTech's response to the breach in a post called, "Hacked? Don't Respond Like This". In this post, I'm going to tackle a more important question;

Why did VTech have this data in the first place?

Data Is A Liability

The VTech case clearly demonstrates that there is a downside to storing data.

Simply put, from a security perspective data is a liability. This stands in stark contrast to the business perspective that data is the new black gold. This creates an automatic tension but that's good, making decisions around data collection requires balance.

Unfortunately, most organizations don't have that balance today.

It's rare that a security team is asked to evaluate what information should be stored. Typically security teams are faced with dealing with the aftermath of collection decisions. That's unfortunate because the easiest way to secure the data is simply not to every have it in the first place.

It's hard for a hacker to steal something that was never collected.

That fact that security is an after thought and not an integral part of all design decisions highlights how completely current organizational security thinking has failed. My friend and colleague Rik Ferguson recently rang the death knell of traditional information security in the enterprise.

I couldn't agree more. The VTech case is the perfect illustration of the point.

Principle of Least Data

A core tenant of information security theory is the principle of least privilege. This principle is applies to user permissions and can be summed up as;

A user/program must only be able to access what is needed to complete their task.

We apply this principle when determining what level of access users should get to various systems. A very simple example is that as an employee, I can access my email account and only my email account. I cannot access someone else's. 

I'm going to use this opportunity to establish a new security principle inline with a new, modern approach to security; the principle of least data. Simply stated;

An organization must collect and store only the data needed to complete their task.

Reducing The Data You Store

Looking at VTech from a customers perspective, there is no requirement for them to store all of the information found in the breach, let alone putting all of the data in the same insecure data store.

VTech uses the Learning Lodge to register various devices, allow users to download content from it's app store, and enable a feature called "Kid Connect".

Let's give them a pass on the information collected for device registration and app store billing (though it can be reduced and isolated for better protection) and look at the information captured on the children to enable "Kid Connect".

Kid Connect
The "Kid Connect" feature allows kids to connect with their parents in real-time. This can be VTech device to VTech device or (more likely) VTech device to parental device via a dedicated app.

In order to enable this feature VTech stores a profile on the child (login, password, date of birth, name, gender, date of birth, etc.) and associates it to a parental account.

This data isn't needed to accomplish the stated goals of the feature and therefore violates the principle of least data.

In order to facilitate the promised communication VTech should be using pseudonymous accounts (a/k/a almost anonymous accounts). An account simply needs a random username, password, and an association to a parental account.

There's no need (from the user's perspective) to provide additional information to be stored centrally. Yes, on the parental app it would be nice to associate a picture and child's name to a specific account but that should be stored locally and securely on their device.

This is a simpler solution and one that doesn't needless collect and expose personal details of children.

Balance Is Required

Storing data has little direct cost. In the age of big data, it's tempting to collect and store as much as you can. As the VTech and many other breaches show us there's also a downside to storing data.

You need to actively discuss what data you're storing and how you're protecting it. All too often organizations are overconfident or (worse) ignorant of their actual security posture and end up unnecessarily exposing themselves and their customers.

Here's a simple set of questions your team should ask anytime you're storing data;

1. Is this data critical to completing the task?
2. What would happen if this data appeared on the front page tomorrow?
3. Can this data be combined with something else we collect to create something riskier?

Still not sure about the risks posed by the data? Don't collect it.

BONUS FOR SALES & MARKETING

There's a massive amount of data collected in the name of better targeting and understanding you customers. I get it. All businesses need to conduct these types of activities on some level in order to stay competitive.

However—as highlighted by the issues around ad blocking—things are out of balance. If you're asking for and collecting data solely to better profile customers, run through the above list 2x and don't be shy about being "that person" in the team discussion.