Protect government databases with data encryption

With the recent proliferation of data thefts, you should be revisiting the security environment of your organization's data. While firewalls and physical security are important, Ramon Padilla advises you to implement data encryption to seal the gaps.

Keep up with the issues and challenges that uniquely affect public-sector IT with TechRepublic's free Government IT newsletter, delivered each Tuesday. Automatically sign up today!

In the last couple of months, we have seen the reporting of 1.4 million credit card numbers stolen from DSW Shoe Warehouse, personal information from 98,000 past and current students stolen from UC-Berkeley, 185,000 patient records at risk due to a burglary in a San Jose, CA medical office, and theft of large amounts of personal data from LexisNexis and Choice Point. As a result, the media is warning consumers to be extra vigilant concerning their personal information. But how about the warning to keepers of the data to be extra vigilant? The above incidents should have caused you to pause and take note of the data security in your organization. If not, when they put your photo next to the news story about the lost data from your government organization, try not to look so shocked.

For some weird reason, the public will cut private institutions some slack when it comes to such mistakes, but someone's head will roll should a similar error be made by a governmental institution. In either case, this type of blunder is inexcusable. We have been warned numerous times, and we have the technology to deter, if not to stop completely, the theft of sensitive data.

If you don't think you have data worth stealing just because your organization doesn't collect credit card information, think again. Government agencies are a literal treasure trove of data: medical records and HIV status (health departments and EMS), social security numbers, sensitive legal information (police, courts, and others), and so on. Even if the information you collect is of public record, the new regulatory environment has raised the stakes on safeguarding particular types of personal data.

One of the most interesting things from all the stories above is the ways the data loss occurred: lost hard drives, stolen PCs, faked credentials, and fraudulent identities. There were no super-secret stealthy hackers making their way past multiple firewalls in the middle of the night—these data were obtained the old fashioned way—through plain old theft and con artistry.

So what is the common thread? Unencrypted sensitive data.

Prepare to have your data stolen

I think there has been a feeling in the IT community that we must place our security emphasis only on the network defenses. We have been building impregnable fortresses against those who would come in from the outside to wreak havoc with our systems, trusting that if we do that, everything will be okay.

While we do need to protect our perimeter, we should be preparing to have our data stolen. In my opinion, it's inevitable. If someone wants your data bad enough, it can be captured. Whether it is through hacking, the physical stealing of equipment, or the inside job of an employee—data is vulnerable.

So, what can we do? Prepare to have your data stolen by using data encryption at the database level. Even if someone manages to steal it, it will be difficult, if not nearly impossible, to make any use of the data.

Of course, it's not that simple, or we'd already be doing it. Here are the issues with data encryption that complicate its use:

  • It can be slow and very system intensive because all encrypted data must be decrypted to be read, updated, or deleted.
  • It may not have been available on your chosen database platform.
  • Even if it is available, it isn't necessarily easy to use; it has implications for your database design, such as encrypted keys that being unusable in indexes.
  • By itself, it is not a panacea. You must still provide good access controls to help ensure your data security.

In short, encryption is pretty much ignored by much of the database development community because data encryption is a pain.

But the time has come for us to deal with this pain. As I alluded to in the opening of this article, it is not the job of the consumer to be extra vigilant regarding their data. It is our job. This starts with us, the keepers of the data, examining the risks of data theft and incorporating what we learn into the design of the databases we are responsible for. In addition, we should:

  • Investigate the access controls to make sure that only authorized users have permissions to access the data.
  • Utilize strong user authentication routines.
  • Implement appropriate auditing to determine who has been "in the data."

We need to bite the bullet and start utilizing data encryption in our new development, if not in our existing systems. I realize this is a big deal, which is why I say we start with new development rather than trying to retrofit encryption onto an old system. The best place to start is with the vendor of your most-used database systems: Oracle, IBM, and Microsoft. Then, take a look at what is available from the gamut of third-party providers and other security experts on the Internet. Wherever you start, start today—you don't want to end up as tomorrow's headline.

Editor's Picks

Free Newsletters, In your Inbox