They can't steal data that you don't have

Data theft has become big news in recent weeks. Between data lost or stolen from Bank of America, ChoicePoint and a unit of Reed Elsevier, the public (and more importantly, Congress) is up in arms about the protection of personal and financial data that can be the subject of massive identity thefts.

Data loss is, of course, nothing new. In our work, we are frequently called upon to investigate these incidents and to find out what happened and who was involved.

Any competent information security professional will tell you that there is no such thing as 100% incident prevention. Incidents happen and will continue to happen. But there are things an organization can do to mitigate the risks of certain types of incidents, as well as the damages if an incident should occur. Failure to examine and mitigate these risks will increasingly expose companies to bad publicity, increased regulation and perhaps costly litigation.

When you look at a lot of incidents, as we do, you can start to draw some conclusions that go beyond the specifics of a particular situation -- whether the loss involved theft of a backup tape or unauthorized intrusion into a system or whether the perpetrators had inside help in carrying out their plans.

We have observed that some of the sensitive data that gets stolen fits into one of several categories:

  • Data that was never needed
  • Data that was needed but should never have been stored
  • Data that was originally needed but was kept far beyond its useful life
  • Data that should never have been stored in an unencrypted form

When we point out these issues to the victims, it seems that they never thought about these problems. We want to take a few minutes to explore them with you.

Data that was never needed

When you look through the data that you record on customers, transactions, employees and processes, when is the last time you checked each and every data field to determine why you needed it?

If you collect information that you don't actually need, not only are you spending money needlessly, but you're also opening yourself up to the risk that the unneeded data might be stolen or misused. You should look for a specific reason for collecting everything you ask for. If you can't define a valid business need or some legal or regulatory requirement for the data, why are you collecting it?

Sometimes we're told that the current system mirrors an earlier system that collected the same information, and no one realized that some of the information was no longer of any real use. Sometimes we're told that when the system was developed, the users defined the fields and IT assumed that it was needed for something or other.

Sometimes no one can even begin to guess why anyone thought that a particular piece of data would be useful. Given the risks that a company faces today relating to data loss, you should go through your data warehouse and determine whether there is a good reason for collecting the data you are storing.

Data that was needed but should never be stored

Many online stores that accept credit cards ask the customer for the card-verification value: the three- or four-digit code printed on the signature strip of Visa and MasterCard cards or the four-digit number printed on the front of American Express cards. These are security codes that verify that the person making the transaction actually has the card and not just the account number. Account numbers often appear in places that can be easily compromised by thieves, such as statements stolen from mailboxes or discarded by account holders (if you don't have a cross-cut shredder at home to shred your old credit card and bank statements, get one now!).

However, the card-verification value almost never appears anywhere except on the card itself. Collecting the information to use in verifying the transaction with the card issuer is perfectly valid, but once validated -- something that generally happens while the customer is online -- the credit card issuers make a strong point of telling merchants not to store this kind of information anywhere, including on transaction logs. Their point is simple: Once the transaction is validated, the vendor doesn't need the code. Storing it just provides a thief with the ability to be a more effective crook. You should check your file structures to see if you are storing anything that is needed during the transaction, but not once it has been completed. If you are, you should eliminate it from your files. Just because you have to use a piece of data doesn't mean you have to store it.

Data that was needed, but has outlived its usefulness

We were called in to an organization to look into the suspected loss of hundreds of thousands of customer records. While our investigation showed that the would-be data thieves were unsuccessful, we noted that the company retained credit card information for customers who had neither asked them to retain their card data nor had been repeat customers.

Certainly, we could understand why the company needed the credit card information until it was sure the goods were delivered and accepted and no refund would be required, but unless a customer asks you to retain his credit card data (through checking a box or other opt-in scheme), shouldn't that data be held for only a limited time and then automatically destroyed? Having this data didn't represent an advantage to the company, and it certainly represented a potential liability when the company thought it might have to notify many thousands of long-ago customers that their credit card data had been compromised.

Data can have a defined useful life, after which it should be deleted in a way that precludes its recovery. In thinking about this, don't forget about information stored on off-site backup media. It might make sense to segregate backup files that have such data onto separate media that can be recycled more frequently than other data, so that risks associated with the loss of a backup tape can be minimized.

Data that is or was needed, but should have been encrypted

Encryption technology is readily available. It isn't difficult to implement software that ensures that sensitive data elements are stored for use when needed, but in a strongly encrypted form. Some data must be stored in a way that it can be retrieved. Other data can be stored in a form that can be validated, but not necessarily retrieved in its original form.

For example, where it's appropriate to store a credit card number, it should always be stored in an encrypted form using an encryption technology that permits you to retrieve the original card number when it's needed. But other fields, like passwords, can be handled differently. A password can be encrypted with a so-called one-way encryption scheme. Put the password into the one-way encryption module, and you get an encrypted value that can be stored. When the person tries to log in again using the password, you put the value they entered into the encryption module and compare the encrypted result to the encrypted result on file. If they match, the original passwords matched.

The advantage of using such a scheme is that it's impossible to reverse the process and go from the encrypted code back to the original password. Of course, where this method is used, it's impossible to retrieve a lost password. Where needed, a new temporary password must be issued and the user prompted to select a new one when logging in. If you're storing sensitive information in plain-text form, not only should you move to secure it through encryption, but you may also be in violation of specific requirements of credit card issuers or of industry-standard best practices if you fail to do so.

The simple fact is that too many IT people think in terms of storage technology, speed, transfer rates and storage network architectures when they should step back and ask whether it's appropriate to store the data they are holding, whether it's being stored for an appropriate period and whether it's being stored in a sufficiently secure fashion. By examining these issues, asking these questions and taking the appropriate actions, you can reduce the risk, aggravation, expense and bad publicity surrounding the compromising of unnecessary or unprotected data.

Alan Brill is senior managing director, and Jason Paroff is director, computer forensic operations, at Kroll Ontrack Inc. in Secaucus, N.J. They can be reached at abrill@krollontrack.com and jparoff@krollontrack.com.

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
 
Shop Tech Products at Amazon