The Utah Listgate Scandal: A Lesson In the Need for Real Data Privacy

Thursday, July 22, 2010

Outrage erupted in Utah last week after an anonymous group delivered a detailed list of 1300 alleged undocumented immigrants to media outlets and law enforcement, with a demand that these individuals “be deported immediately.“ The immigration hit list contained birth dates, workplaces, addresses, phone numbers, Social Security numbers, names of children, and the exact due dates for several pregnant women.  All of the names appeared to be Hispanic.  [Deseret News]
Initially, the group claimed it had compiled the list by “quietly watch[ing] Hispanics in their neighborhoods, schools, churches and ‘public welfare buildings."  Despite this terrifying and Orwellian statement, an investigation quickly revealed the source of the list data to be a database maintained by the Utah Department of Workforce Services, which administers food stamps and Medicaid programs.  Two state workers have now been found responsible for distributing the list after compiling it over the course of several months by gathering records in a methodical manner to get around department security protocols.  [MSNBC]
Beyond the despicable attempt to intimidate and harass the people on the list, the Utah “Listgate” scandal is a frightening lesson in the sheer volume of personal data collected and stored about all of us in countless government databases. This incident should serve as a wake-up call about the vulnerability of our personal data and the need to develop real protections for our data privacy.
In recent years, various bills have been introduced in Olympia aimed at providing some transparency for the labyrinth of government databases, including SB 5869, introduced by Senator Adam Kline in 2007, which called for an audit and report of all state databases containing personally identifiable information. None of these bills have become law. We need to move, however, beyond simply knowing what the state has in its data archives and towards actually protecting the privacy of this data.  
When one hears of a large-scale data intrusion, one’s first presumption often is that the security breach was the work of some malicious hacker. We as a society have adopted criminal laws to deter against and punish such conduct.  But, for the same reason we wouldn’t build houses without any locks simply because burglary is illegal, we consider network security to be part of the fundamental design process for computer systems; indeed, security professionals are always in enormous demand.  

As any retail store owner will lament, though, most theft is an inside job.  The same holds true for data theft.  A 2004 report indicated that as much as 70% of ID theft starts with employee theft of personal data. The Utah Listgate scandal makes clear that the problem is not limited to private companies. 

Unfortunately, unlike external security, protecting our private and personal data against internal threats has never been a fundamental component of any system design.  Instead, privacy is tacked on as an afterthought statement somewhere in a policy manual.  So our house may have a lock on the front door, but we keep everything of value stored in the cupboard, and anyone with a key can access anything they want despite the note on the door saying otherwise.  Yet we act surprised when the cupboard turns up bare.  

Unless and until privacy becomes a fundamental part of the administrative and technical design of any system, given the vast troves of data stored on government servers, data privacy atrocities just like the Utah Listgate scandal are certain to happen again.