Advertisement

Data Protection: How Does This Figure Into Your Architecture?

By on

Click here to learn more about author David Schlesinger.

The credit reports that your company may keep when deciding to allow credit to a new customer just might be considered confidential, especially if your billing department included judgmental remarks and evaluations. The purchase requests from your accounts payable department could potentially show which ingredients you buy that make up your secret-sauce or amazing product. Certainly employee data regarding their home address, family information, and employment history is private, perhaps too private to automatically show every person in your HR Department. Your suppliers also have a great deal of exposure that should be protected by the mutual non-disclosure contracts that you and they signed. How does this figure into your architecture to keep these data protected from hackers who might steal the entire database?

Consider the unhappy companies and government departments that have recently had their data lifted and published on the Internet. They saw all their confidential emails, contracts, budgets, password lists, and employee detail data published on the Internet. All of these companies thought they were protected and PCI compliant. They believed that compliance was checking off boxes on a form. They were wrong.

Rather than throw up our hands and say “it is impossible,” it would be better to consider that a data breach is a possibility in the future and design systems that would be resistant to complete extraction by hackers. A number of creative and technical techniques can be implemented, and also some very simple policies that would limit the damage from an eventual hack.

The first requirement is to look at your data with an eye toward deciding which data elements require special care. This could be additional safeguards in access control, encryption, or limited availability within the corporate network. It may not by appropriate, for example, to download your entire HR database into the system that manages door security when all it needs is a current status connected with an employee number. What is easy to do often mindlessly combines highly sensitive and regulated information with non-sensitive information as if there were no difference.

Ignorance is Not Data Protection
Indeed, often the system design fails to take the difference into consideration, or even acknowledge that some data should be treated differently. This lack of visibility to the data within a system is even mistakenly assumed by amateurs to be some sort of “security.” They assume that if it hard to locate data for regular employees, then it will be much harder for hackers. Alas, it is trivial for hackers to find sensitive data since they search for known formats and do not care of they break or crash systems while they do their search.

Ignorance of data types, locations, and sensitivity prevents astute data administrators from finding the unprotected copies of sensitive data sitting on load-testing platforms, on local servers, or in backups. Even old personal data is highly sensitive since most of the numbers and information that the thieves want does not often change. An inventory of all the data within your information systems is essential for both data quality, a reduction in duplicated data and data protection.

So you not only need to know not only what is in your data, but where is it located and how many times does it exist duplicated within the enterprise data architecture. The elimination of all duplicate data is not always the goal, what is the goal is the elimination of unknown duplicates of sensitive information. To add to “What is in my data” we will also include “Where is my data?” Only when you know those things can you truly manage your data.

You cannot control what you cannot measure, and you have even less control over what you cannot find. Find your data!

Leave a Reply