CyberSecurity Proposal: Fighting Identity Theft
Submitted for Public Comments
Entrapment Id:
Unnerve Identity Thieves by Peppering Transaction Databases
with Fake Id Records That Implicate Whoever Tries to Use Them
In the identity theft war the hackers enjoy significant advantages: Once the essential data 'coordinates' of an individual are stolen, they can be abused right away, or much later, because we are not likely to change our name, get a different social security number, or ask our mother to change her maiden name. With biometric data added to the list, our vulnerability further entrenches itself: try to acquire a new set of fingerprints... Also, when a victim finds out that his private data parts are private no more, he has no idea where they were stolen from, because the same personal information appears on countless merchant accounts, and with numerous financial services organizations. Oftentimes the source of a security breach remains hidden, and the leaking source is unaware of its culpability. The recent trend in id abuse is not to steal money but to cover up unseemly transactions. Abusers would open a credit card account with a stolen identity, pay it in full every month, but use it to acquire dishonorable services, aiming to protect their reputation, at the cost of tarnishing the victim's reputation, without him or her realizing this fact, and wondering why they have been turned down on a job that seems a perfect fit for their qualifications... These 'soft abusers' are operating today with a sense of impunity, fearing little or no repercussions. Similarly, the compromised databases don't feel too much heat either. So here is an idea that might help change the game a little bit. Please read it, and let us have your opinion.
Suppose that every database that lists stealable identities will be peppered with fake records. A fake transaction will be stealthily entered: a fake name and identity parameters. Each database will have its own fake records. The card company will keep a master list of which fake records were implanted in which database. Now, if a particular database is getting compromised, and the thief then retails his spoils, and sells the stolen identities to the end abusers, then at some point an identity thief will try to execute a transaction with the fake identity at his disposal. As the transaction flows through the authentication and approval sequence, the card company will spot it, and then counter action can be taken. Rather than rejecting the transaction (which will beat the purpose of this countermeasure), the deal should go through, and in parallel the authorities should be notified in order to track down the thief, confront him or her in person, throw the book at him and extract from him the source that sold him the stolen identity. By climbing back through the ladder of middlemen, the original hacker will be flashed out. And because each database will have its own fake records, it will be quite clear which database was compromised. And since in many cases the compromise is a product of unfaithful employees who strip their stolen identity from every piece of data that would betray the source -- all these insider's job will be unearthed. Merchants, processors, and financial institutions will know with great certainty if their records have been compromised or not -- a very important feedback, which is missing today. And on top of all that boon we create a powerful deterrent. Would be abusers, some of them have a hard-earned reputation to protect, will be nervous about using a purchased stolen identity, fearing it is a trap identity. So, in summary we will improve our security by identifying where it is breached, when breached, and by deterring a large fraction of abusers from their abusive acts, fearing the trap.
Implementation is a technical issue that must be resolved, but before delving into it, we should consider the operational parameters. Would database owners wish to participate, and be exposed in case they are the source of security compromise? For this scheme to work, it must be implemented with the involvement of the various card companies -- will they take it on?
We must be mindful that we are engaged in an unending cyberwar (see Samid's book so titled), and like every war, it is full of surprises. A good general prepares a set of 'drawer plans' fully thought-out, but not necessarily implemented for the time being. Yet, should circumstances so dictate, the plan can be pulled from the drawer and turned into reality. The entrapment-id concept may not be ripe for immediate deployment, but we might want to keep it ready just in case. And why not use the time to contemplate the less obvious, hidden aspects of this plan, and furthermore, why not let the digital transactions community voice its opinion on this matter. Please do!
