include an unauthorized party obtaining voter information on a large scale or a spouse abuser obtaining the address of his/her spouse from a VRD even if such information is supposed to be protected.

  • Integrity. A secure system produces the same results or information whether or not the system has been attacked. When integrity is violated, the system may continue to operate, but under some circumstances of operation it does not provide accurate results or information that one would normally expect. An example of a failure that affects the integrity of a VRD is an unauthorized change in a VRD that could force an individual to show identification at the polls when in fact there is no such requirement for that individual to do so.

  • Availability. A secure system is available for normal use even in the face of an attack. An example of a failure in availability might be a system that is clogged with so much bad data that the system no longer operates reliably (for example, a flood of bogus paper voter registration applications that overwhelms the data-entry staff in a particularly critical jurisdiction).

A number of security breaches of VRDs have been reported.4 For example, on October 23, 2006, an official from the not-for-profit Illinois Ballot Integrity Project reported that his organization had used the Chicago voter database remotely to compromise the names, SSNs, and dates of birth of 1.35 million residents. According to a spokesman for the Chicago Election Board, the problem arose because the city’s database allowing voters to locate their voting precinct once asked voters for detailed information such as Social Security numbers, and even though the Web site was updated to require only names and addresses to make a query, the links to the Social Security numbers and the dates of birth were never eliminated.5

Developing secure systems (where “system” is intended to include the human and organizational aspects of a system as well as the technology) is a challenging task, and much has been written about such matters. But it is essential to consider three fundamental points about security.

First, good security practices require thinking about building security in from the start. Good system specifications inform analysts of what is “required and expected” behavior. Good software engineering enables the system to be implemented in a way that conforms to the system specification. Formal verification methods and other analysis tools may be helpful in showing that implementations faithfully conform to certain aspects of their specifications.

Second, security threats can arise even in systems that are not connected to the Internet. Although Internet connections are often an important source of vulnerability, they are most assuredly not the only source. The recent history of computer security is replete with examples of security compromises that had nothing to do with the Internet, such as data on stolen laptops, attacks from insiders abusing their privileges, and “social engineering” attacks involving humans posing as other humans, often over the telephone, in order to learn credentials such as passwords that can enable them to access systems and files they should not be able to access.

For example, video surveillance cameras caught two intruders in Mississippi on June 23, 2006, stealing hard drives from 18 computers. Data files contained names, addresses, and SSNs of current and former city employees and registered voters as well as bank account information for employees paid through direct deposit and water system customers who paid bills electronically.6

Third, any realistic assessment of a system’s security involves actual testing of the system’s security by an adversary who is motivated to compromise it. Although testing cannot, and does not,

4

See http://www.privacyrights.org/ar/ChronDataBreaches.htm. This site contains descriptions of a number of data breaches involving actual VRDs, and a number of others of potential relevance to VRDs.

5

See http://abcnews.go.com/Politics/story?id=2601085; http://www.electiondefensealliance.org/chicago_voter_registration_database_wide_open.

6

See http://www.privacyrights.org/ar/ChronDataBreaches.htm.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement