Holy Grail, No More

Computerworld
Holy Grail, No More
Frank Hayes

MARCH 13, 2006 (COMPUTERWORLD) - It's happened again. In late February, another laptop was stolen that reportedly contained tens of thousands of names and Social Security numbers. This time, it was grabbed from the home of a state college employee in Denver; that employee had the data on the laptop in order to write a grant proposal and a master's thesis. As usual, the data was unencrypted, the investigation is ongoing, and there's a howl going up about whether the employee should have taken the data outside of school premises at all.

Funny thing, though. No one involved seems to be raising a more fundamental question: Why exactly did this employee have access to 93,000 student Social Security numbers in the first place?

After all, Social Security numbers are the Holy Grail of the identity thief. They're so widely used as unique identifiers that attaching that one number to a name is all it can take to find out nearly everything else about a potential rip-off victim.

On the other hand, they're not particularly useful for someone who is writing a grant proposal or a master's thesis.

So why was this employee hauling around all that highly sensitive and almost certainly unnecessary information? You know the likely answer: It came with the package.

The data that the employee wanted probably included personal information about students. The names and Social Security numbers weren't necessary for analyzing that information. Most likely, they just happened to be part of the data set.

It's possible the employee was using the Social Security numbers as unique identifiers for each student. But they still weren't necessary; any unique number would have served that purpose.

And that number wouldn't have had any value to identity thieves.

Isn't it time you started seriously protecting this highly sensitive piece of information about students, employees and customers? Not just with encryption or beefed-up authentication or gimmicks like self-destroying data, but with a much more effective technique: not giving out Social Security numbers to people who don't need them.

What a concept, huh?

Most users won't object. They don't need Social Security numbers to interact with you, and they know it. As long as you give them an alternate unique ID, they'll be happy. Some won't even need that.

Other users, who are accustomed to using Social Security numbers routinely, will complain. And there's no need for IT to be unreasonable: If a user has a legitimate need for that particular number, deliver it to them. You don't even have to set a high bar for what you count as legitimate. The goal isn't to give users trouble.

It's to keep trouble away from the people those Social Security numbers belong to.

But it's time to stop treating this information as just another set of numbers. There's no mystery how this mess came to be: It dates from decades back, when Social Security numbers weren't so sensitive and the thick, green-bar reports IT generated weren't so likely to leave the office. Back then, including Social Security numbers really wasn't such a big deal.

Those reports gave way to client/server applications, and then data sets that users could access directly using spreadsheets and carry anywhere in laptops. Rejiggering that data to remove Social Security numbers never seemed like a high-priority project.

Make it a priority now. Identity theft isn't becoming less of a problem. Neither is laptop theft. The next stage is easy to predict: class-action lawsuits that slap a hefty penalty on organizations that let thieves grab personal information.

You can't prevent that, any more than you can prevent laptops from being stolen. But you can keep the damage to a minimum. And a great place to start is to keep Social Security numbers out of the hands of anyone who doesn't need them.

Because you know it'll happen again. And you want to make sure it doesn't happen to you.

Frank Hayes, Computerworld's senior news columnist, has covered IT for more than 20 years. Contact him at frank_hayes@computerworld.com.