Protecting Sensitive Data

I found this article from a recent issue of InformationWeek on sensitive data and the lack of security that we apply to it very interesting. I’ve personally managed many projects with sensitive data including employee health records, IRS data, student financial aid information, bank records, etc. I understand as a whole we do not generally do a great job of ensuring the integrity and safety of the data that our projects contain, transmit, integrate with, and process.

This article was written by Art Wittman, the director of InformationWeek Analytics, and it appears in the 7/6/2009 issue of InformationWeek. The title of the article is “Practical Analysis: Why Aren’t We Better at Protecting Data?”

We’re not as good as we should be at handling sensitive data. One strong data point toward that conclusion comes from the watchdog site Privacy Rights Clearinghouse (www.privacyrights.org), which has been doing its best to track both the cause and effect of data breaches since 2005. Since then, the site has cataloged more than 262 million compromised records. Some are more severe than others, and some have been handled better than others, but that grand total should serve to verify my basic thesis: As a group, we aren’t very good at this.

There’s no particular group of institutions that fare worse on this list than another– banks, state governments, federal agencies, educational institutions, insurers, healthcare organizations, and all other manner of businesses show up. What’s striking about the list is that a large number of breaches result from simple theft, and from either poorly devised or poorly implemented policies. For these sorts of breaches, tighter regulation typically isn’t the answer, and technology is only part of the answer.

Clearly, if systems with sensitive data are stolen from public places–one of the more common methods for exposures–there are policy issues, training issues, and technology issues at hand.

Do your policies allow for users taking significant numbers of sensitive records outside of the relative safety of your corporate walls? Maybe that’s not such a good idea. If it’s truly necessary, are your users adequately and regularly trained in how to keep that data safe, and have you employed the right technologies–like encryption–that will allow you to put some technical muscle behind your policy?

In our recent survey and report (available at dataprotection.informationweek.com) on data loss prevention, we found organizations still applying relatively the same policies to all users. At the same time, well over half have not yet implemented any form of encryption on mobile devices. Let’s face it, if you’re still more worried about whether Ed in accounting changes his password monthly to something longer than 12 characters with alpha, numeric, and punctuation symbols and is otherwise impossible for Ed to remember, while your sales team is running around with unencrypted client data on their laptops, something is very wrong with your data protection policies. To put it plainly, you’re doing what’s easy and cheap for you, but not what’s in the best interest of the business and its customers.

Other discontinuities between policy and risk aren’t hard to find. Poll respondents worried most about e-mail as a mechanism for losing sensitive data (47%), followed by removable media (32%); however, almost half don’t encrypt sensitive data on removable media. It’s a disaster waiting to happen, and the only thing worse than losing sensitive data is losing it and not knowing that it’s gone. Here, too, it’s a matter of policy, training, and technology. Log analysis software along with a policy and practice of actually using it is critical for protecting sensitive data.

Common sense and awareness of risks will go a long way in guiding DLP policies.

Related posts:

1. The Most Serious Data Threat May be Sitting Next to You
2. Dashboard Data for Government IT Projects
3. Data Security and the Cloud it Rode in on….
4. Sensitive Data Often Exits with Employees
5. Ten Guidelines for Managing Passwords in the Enterprise