Keeping Private Data Private: Tips and Tricks

Posted on by Joshua Marpet

MouseTrapCompanies produce data. Some of it is public data, some private data. The classification of data into public and private is important, but right now, the means to keep data private is incredibly important as well. Keeping data private is a process.

It starts with examining the use cases for the data. Is this piece of information going to be used every day? Or does it just need to be stored in case we need it sometime in the next 7 years? Is there a date when it should be destroyed? Who should have the ability to examine or read the data? Most businesses have a few profiles for data. Typically, they come down to:

  • Data used constantly (daily, weekly, monthly)
  • Data used infrequently (annually or once every few years)
  • Data used in case of emergency only (emergency keys, backups)
  • Data to be stored for audit or compliance

Each of these profiles should have a data destruction date associated with it. Perhaps the "data used constantly" has an annual date, so that kind of data has a one-year lifespan. Emergency-only data might never get destroyed, and audit/compliance data typically has a seven-year lifespan (depending on regulations).

Then there's the methodology of keeping each class private. "Private data" implies complete privacy. But that's not true—certain people need to be authorized to use or examine the information. How do we distinguish who is authorized?

Start with the easiest. Data stored for emergency only should be encrypted. The encryption should be an extremely tough algorithm, with a high key count. It may take a lot of time to encrypt or decrypt, but this is not data that will be used every day, and the encryption must withstand the test of time. Authorization can be handled by using multiple keyfiles, all of which need a pin or password to unlock them. So the COO, the CISO, and the IT admin must be present to unlock the emergency key store, and they must all have their flash drive and password with them. TrueCrypt includes this capability and is a free and open source.

Data to be stored for audit or compliance is normally stored all year, and used for a short time each year, for the audit. This data can be encrypted in batches, with a single keyfile, where the head of audit or compliance holds the key. At the end of the year, decrypt all the batches, and get to work compiling for the audit.

Data used infrequently, whether for annual reports or reconciling all the accounts payable/receivable, can be stored in an encrypted file share, with very restricted security groups having access. Windows Active Directory and BitLocker can handle this easily.

Data used frequently can be stored in an encrypted file share, or simply a restricted file share, with locked down access control lists (ACLs), and the audit logs for access should be checked regularly. Windows Active Directory is built to do exactly this.

So the tools to keep data private, and audit the access, are either already within most corporations' grasps or are free and open source. So why aren't they used more? Because the first step, data classification, is the hardest.

Neat tip: Set up a file share with an attractive name, "Secret Sauce," or "Financial Data: Eyes Only!" Fill it full of trash documents. Don't give anyone access, and set the audit logs to alert if anyone tries to look at it. You've built yourself a hacker mousetrap!



data security privacy

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community