Preventing identity mega-theft

While companies say they collect information on consumers to better serve them, the worst disservice they can do is to inadvertently expose customers’ private information. Every few weeks it seems that another huge number of credit cards or Social Security numbers (SSN) is stolen from a database. Consumers are understandably furious - they can buy shredders to make sure they’re not putting their private data out there, but what can they do when their data is mixed with millions of records in a poorly secured database?

There are several things data center managers can do to protect customers’ identities. The simplest solution of course is to not collect information that you don’t really need. If you want to be able to find a customer quickly, a phone number will often suffice - you do not need to store an SSN. Pet’s names, high school names and favorite colors can be used instead of birthdates or mother’s maiden names. No database is guaranteed to be secure, no matter how many security tools or precautions you use. Assess the risk of storing each individual piece of data against the benefits, and try to find less risky alternatives.

If you must store an SSN for verification, then perhaps you can store it as a one-way-hash (see Peter Wayner’s “Translucent Databases,” in related links below). Instead of storing 123-12-1234, you convert it to a one-way-hash of 23F5A1C2 and store that instead. Now, if you need to find someone, you ask for their SSN, convert it (once) and search on the index of one-way-hashes. If you need to verify their SSN, ask for it and then just check if its one-way-hash matches 23F5A1C2. Do you ever need to retrieve the actual SSN itself, or are you only using it as an index key?

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

While companies say they collect information on consumers to better serve them, the worst disservice they can do is to inadvertently expose customers’ private information. Every few weeks it seems that another huge number of credit cards or Social Security numbers (SSN) is stolen from a database. Consumers are understandably furious - they can buy shredders to make sure they’re not putting their private data out there, but what can they do when their data is mixed with millions of records in a poorly secured database?

There are several things data center managers can do to protect customers’ identities. The simplest solution of course is to not collect information that you don’t really need. If you want to be able to find a customer quickly, a phone number will often suffice - you do not need to store an SSN. Pet’s names, high school names and favorite colors can be used instead of birthdates or mother’s maiden names. No database is guaranteed to be secure, no matter how many security tools or precautions you use. Assess the risk of storing each individual piece of data against the benefits, and try to find less risky alternatives.

If you must store an SSN for verification, then perhaps you can store it as a one-way-hash (see Peter Wayner’s “Translucent Databases,” in related links below). Instead of storing 123-12-1234, you convert it to a one-way-hash of 23F5A1C2 and store that instead. Now, if you need to find someone, you ask for their SSN, convert it (once) and search on the index of one-way-hashes. If you need to verify their SSN, ask for it and then just check if its one-way-hash matches 23F5A1C2. Do you ever need to retrieve the actual SSN itself, or are you only using it as an index key?

Encrypting actual data in a database, unlike one-way-hashes, can involve some significant computational overhead. Furthermore, it requires careful key management to avoid data loss. If you want to pursue such an approach, it is best if you use a front-end encryption device that transparently encrypts and decrypts. Beyond improved performance, hardware-based database encryption products such as Ingrian’s DataSecure appliance provide key management and recovery.

Finally, if you can’t protect each individual record you can at least protect against mega-theft by fine-tuning the database permissions. A database access control and monitoring product such as Guardium’s SQLGuard can filter and selectively block SQL statements that do not match a pre-defined policy, or detect transgressions and alert your security team. After all, even you database administrators don’t often need to do “SELECT * from CREDIT_CARDS” (a bulk retrieval of sensitive data).

Bottom line: Avoid storing data you don’t really need to store, use one-way-hashes to protect data, encrypt where appropriate and filter SQL with policies. All of these approaches are much preferable to infuriating your customers and being “named and shamed” in the press.

Read more about data center in Network World's Data Center section.