If you haven't heard about the Ashley Madison hack and data disclosure yet, check it out. A group of hackers calling themselves Impact Team breached Ashley Madison, a dating site geared toward people who wanted to cheat on their spouse. They demanded that Ashley Madison and partner site, Established Men, be shut down. The site failed to comply and, 10 days ago, the data of the site's 32 million users were released.
You can only imagine the uproar that ensued. Marriages ended, adulterors were unmasked, and a lot of people had a really awful day. What's interesting, though, is Impact Team's motive. In statements, they condemned the site's "full delete" feature, which charged users $19 to completely delete their accounts. The catch was that the site would still store the data from the transaction when deleting the account, which means a user's real name and address would remain intact.
While this is clearly an extreme case, it demonstrates the need for strong deletion and data retention practices. This is generally bad news for Ashley Madison (which may be good news for the world). A perceived lack of security on such a sensitive application could be the end for the service.
What went wrong? Ashley Madison had poor standards for the deletion of data and, whether or not that inspired Impact Team, it makes the hack a whole lot worse for the company. This is true for all companies that store sensitive data.
From a business perspective, enforcing good deletion standards is essential to developing a competitive product. While regulations sometimes govern how long data may be stored, it is important for businesses to clearly define what they mean by "deletion" and enforce that standard in their products.
In reality, deletion can take countless forms. Calling a built-in delete() method in code will typically remove references to data in memory, but that data still exists and can be accessed if you know where to look. The following table outlines some common methods of deletion, whether the data still exists, and whether it is recoverable.
|Deletion Method||Does the Data still exist?||Is the data recoverable?|
|Make Data Unsearcheable within a system (common delete)||Yes||Yes|
|Remove pointer in memory (call delete())||Yes||Yes|
|Encrypt Tabular Data and Destroy Keys||Yes||No (within a reasonable time frame)|
|Remove pointer and overwrite data with all zeroes||No||No (Occasionally on older hard drives, it is possible)|
|Repeatedly Overwrite data with random 1s and 0s (Guttman's Method)||No||No|
|Destroy or render the hard drive unusable||No||No|
All of these methods can be employed in a useful way, depending on the sensitivity of the data stored. For example, social media data of minors might be best deleted after a shorter period of time using a more thorough deletion method. On the other hand, emails of users may require less stringent and exacting deletion standards.
Regardless of what method one uses, it is essential to be transparent about the thoroughness of the deletion type specified. More importantly, a business should never, under any circumstances, charge users to delete their data, especially if you can't be sure that it's gone.