Site of the Living Dead: Defending against Zombie Data

The dead walk among us. Both humans and data declared digitally deceased are actually alive, and the information saying otherwise is doing continued harm. These are the harrowing tales of zombie data, where death takes on a twisted meaning and what is dead may not stay dead. Spooky!

The dead walk among us. Both humans and data declared digitally deceased are actually alive, and the information saying otherwise is doing continued harm. These are the harrowing tales of zombie data, where death takes on a twisted meaning and what is dead may not stay dead.

Reports of My Death Have Been Greatly Exaggerated

Fraud detection and prevention is a serious business in most benefit and insurance companies—sometimes, deadly serious. There are multiple incidents where United States veterans lost their benefits due to a lack of understanding of the fraud-prevention systems in place, and agent inability to correct a simple mistake. Veteran zombies are multiplying, and the virus spreads not by bites, but by bytes.

Consider the plight of Army veteran Robert Pressley, who was very much alive when the US Department of Veterans Affairs notified him of his own death. Two checks arrived to pay for his unneeded burial. Letters were sent to his ex-wife informing her of his death, despite his call to the Veterans Administration to inform them multiple times that not only had they both remarried, but he was also obviously still alive. However, his benefits were terminated, along with his virtual life. With no death certificate, the VA had no proof that Pressley died; they were unable to provide a reason for his account being marked deceased.

Army veteran Jerry Miller had a similar experience. His account was wrongly marked deceased—not once, but four times. After receiving a letter from the VA informing his estate that his benefits were being cut off, he notified them that he was alive, and his benefits were reinstated. But he soon received another letter, again notifying him of his death. Each time the mistake was fixed, the fraud-detection algorithm “corrected” for this issue, terminating his benefits. Each time, the VA sent letters asking for his benefits to be reimbursed by his estate. Each time, he would call and explain the problem again. “I can't die but one time,” he said. “They have killed me four times.”

How Social Security Creates Thousands of Zombies

Another case of fraud prevention gone wrong is the false reports of digital deaths to the Social Security Administration. Between January 2004 and April 2007, the Social Security Administration made 44,000 corrections for when it had incorrectly listed people as deceased. This required face-to-face interviews with each person, along with processing "resurrection transactions" to remove the individuals from the "death master file.”

A conflict of interest between supporting the dependents and spouses of the recently deceased and having continued benefits for those who may be wrongly reported as deceased makes this situation tricky. The strategy is to try to quickly correct the falsely reported deaths rather than delay reporting deaths in an effort to reduce the number of false reports. The Social Security Administration has a reputation for usually correcting the issue in weeks, sometimes taking up to a few months in the most difficult cases.

But the “death master file” is sent to Medicare, Medicaid, and the IRS, causing a cascading effect that can complicate correcting errors if they aren’t found quickly. Those falsely entered as dead may experience a delay in benefits and a loss of insurance or pension plans, or even impact housing and leave individuals without necessary medication. These mistakes become a bureaucratic nightmare to correct. Even when fixed quickly, those wrongly declared dead are more susceptible to fraud and identity theft.

A simple mistake such as a numerical typo can cause a living person to be considered dead, like when a Social Security number is entered incorrectly. It is a challenge to balance the need of protecting against identity thieves and fraud while still subjecting as few living people as possible to being marked as deceased.

Creditor Hauntings

The federal government isn’t the only potential source of an unexpected deceased status. Kimberly Haman filed a lawsuit against her St. Louis, Missouri, bank and Equifax when the bank declared her dead for unknown reasons in 2013 and the credit-reporting agency picked up the claim. When she tried to refinance her mortgage, Heartland Bank notified Haman that her refinance loan couldn’t be processed because Equifax had reported her as deceased. When she spoke to Equifax, they indicated that the report of her being deceased was from Heartland Bank. Multiple attempts to fix the error did not result in a correction by either company. Over half a year later, she was denied a credit card because she was still declared dead.

While a vast majority of mistakes are quickly fixed once reported by the person impacted, the weaknesses in credit reporting are more frequent than those we face from the federal government. The Consumer Data Industry Association said in a statement, “The (Federal Trade Commission’s) research determined that 2.2 percent of all credit reports have an error that would increase the price a consumer would pay in the marketplace and that fully 88 percent of errors were the result of inaccurate information reported by lenders and other data sources to nationwide credit bureaus.”

Ashley Madison Accounts Back from the Dead

There were undoubtedly many uncomfortable conversations earlier this year after the dating website Ashley Madison, which exists to help married people cheat on their spouses, was hacked and members’ information was made public. But in addition to revealing data about individuals with active accounts, those who had paid to cancel their subscriptions and have their accounts removed were still exposed. According to the databases, 185,948 deleted accounts were leaked, and now a multimillion-dollar class-action lawsuit has been filed against parent company Avid Life Media because the data was not properly deleted or sufficiently secured.

Deleted accounts marked each person’s account number, name, street address, “looking for others” abstract, and security answer as <paid_delete>, but GPS coordinates, weight, height, date of birth, email address, account dates, ethnicity, turn-ons, and other data was not removed. Not only did the site charge $19 to get rid of an account and then fail to do as promised, but by using <paid_delete> rather than NULL for a value, the breach is potentially more damaging to those account owners.

While Ashley Madison paid deleted accounts aren’t digitally coming back to life after death, like the other cases mentioned, the data itself is a terrifying zombie. As a tester, how could this issue have been detected? What if it was reported and ignored?

Without proof, here’s how I imagine this bug could be found by a tester on an agile team. The story card is estimated and picked for this sprint. The story card says, “As a married client, I want to delete my account so that I can’t be found on Ashley Madison.” The developer made a solution that solved this issue on the front end, only without considering the scope. If it can’t be seen, does that mean it can’t be found? These are the questions we need skilled practitioners to ask. It doesn’t matter if the practitioner is a developer, a tester, a product owner, or a business analyst; in cases like this, failing to ask these questions can cost reputations—and more.

Defending the Dark Data Corners

If you are working at a bank, employed by a social media company, or handling medical data, at some point you have to consider user impact beyond the features. What is happening on the back end? Part of security is deciding how much data we need to keep, and how it is kept.

Defense against our own algorithms is also important. What happens when our fraud prevention systems make mistakes? We need to define who has authority to properly override that mistake, as well as how we log and audit those results. Considering the digital complexity of preventing fraud for the government, I can understand why it isn’t perfectly efficient. What is harder to defend is the human impact of a disabled veteran fighting for deserved benefits for multiple years.

While no system is going to be perfect, we testers should keep asking the questions that can prevent more zombies from being created. Because asking these insightful questions could stop the zombie apocalypse from spreading.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.