Blog

How to Avoid a Data Breach

On September 7, 2017, Equifax published a press release announcing a “cybersecurity incident potentially impacting approximately 143 million U.S. consumers.” In the parlance of cybersecurity and information management, they suffered a data breach.

While data breaches are fairly common, and undoubtedly happen more often than the general public realizes, this one was spectacular. Not just for the fact that around 143 MILLION Americans were impacted, but because of the sensitive nature of the data that was leaked. According to the press release, the data included “names, Social Security numbers, birth dates, addresses and, in some instances, driver’s license numbers” – everything you need to effectively perpetrate identity theft.

It could happen to you

A data breach can happen to anyone. The big data users like Equifax, the government, and countless other organizations can afford to implement security measures most of us can only dream of and they get ‘hacked’ regularly. As is seen time and time again, these are often thwarted by basic human error. Someone forgets to change a default password, or fails to set the correct permissions on a legitimate user account that later gets compromised.
But I’m not going to dwell on how perps manage to defeat security measures. To an extent, that’s irrelevant. I’m not saying you should let any Tom, Dick, or Harry access your data. But maybe it’s time to adopt one of the central tenets of business continuity planning.

Plan to fail, don’t fail to plan

You should definitely try to prevent unauthorized access to your data. That is beyond question. But you shouldn’t rely solely on preventing access because, chances are, there’s someone out there who’s a little smarter than your security vendor.
You need to think about what you can do if (or when) your security breaks down. While the following tips are more applicable if you have built (or are building) your own application, they can also be used with ‘off-the-shelf’ software to a lesser or greater degree.

It’s all gibberish

Encrypting the data you store will help to protect it should you suffer a data breach. Assuming, of course, that the encryption is strong enough. The problem is that few ‘off-the-shelf’ applications support encryption for anything other than passwords. Sure, you can yell at your vendor and ask them to build encryption into every field but it will come at a price – and not just a monetary one.
Firstly, encrypting data ‘on-the-fly’ carries overheads in terms of processing power, memory, and disk space. It also requires a ‘front end’ solution that can decrypt the data stored in the ‘back end’.

Divide and conquer

Storing all your data in one database is bad. Not as bad as letting someone run riot with it but still bad. And unnecessary.
Think about it for a minute. While there may be some occasions where you absolutely need a customer’s social security number, you don’t need it to call them or make a sale. So strip out the SSNs and store them separately from their name, address and phone number. If you need it, just look in the database or application that contains it. Sure, it’s an extra step but it helps protect your customer (and you from expensive fines or lawsuits) if your main data is compromised.
Likewise with sales records. You don’t need anything other than a way to identify the customer (see the following point) and the products or services they have bought.

Who said that?

Anonymizing the data as much as possible is definitely recommended. Your data has a unique id – maybe an email address, or (really, really bad idea) their SSN – but it could just as easily be anything so long as it’s unique. Something like 24J6R6JPP0N.
When you combine this with the divide and conquer strategy, suddenly your data becomes more secure. Instead of this:

You get multiple files like this:

Unless someone steals both your SSN file and the other files that contain the other personal data, there’s little they can do with it. If all they have is the unique id and the SSN, they’re not going to be able to run up a huge debt with the name of 24J6R6JPP0N!
With DataMatch Enterprise, adding a unique id and splitting data into multiple files is child’s play. And when you need to pull data from the separate files into one file again, DataMatch Enterprise can link the records based on the unique id.

Schedule a demo to see the power of DataMatch Enterprise for yourself.

In this blog, you will find:

Try data matching today

No credit card required

"*" indicates required fields

Hidden
This field is for validation purposes and should be left unchanged.

Want to know more?

Check out DME resources

Merging Data from Multiple Sources – Challenges and Solutions

Oops! We could not locate your form.