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.