Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Security Recommendations

READ-ONLY SITE MATERIALS: Historical voting TWiki site (2015-2020) ARCHIVED from https://collaborate.nist.gov/voting/bin/view/Voting

Note: This topic is a work-in-progress. Edits are welcome, and discussions can take place on the Cybersecurity Constituency Group mailing list. 


Voting systems connected to the Internet will be exposed to online attacks.

It is commonly accepted that voting systems should not be connected to the Internet. However, we should first consider what constitutes an Internet connection that could potentially expose vote data to an online attack.

There may be a perception that a vote counting or tabulating system must be continually connected to the Internet to expose it to online actor, or that the system must be connected to the Internet at the time the votes are being tabulated for the attack to be successful. It may be expected that a computer hosting an Election Management System (EMS) can be kept offline but networked to the local county network safely. However, if any devices on the local county network are connected to the Internet, this creates an exploitable Internet connection that could compromise the security of the EMS. It may also be expected that a voting system component which does not operate on the Internet - like the EMS – can operate safely offline while the same server hosts other programs and systems which do operate on the Internet. Finally, it is important to note that many computers which host the EMS are laptops which have wireless internet capacity installed which could make them vulnerable to online attacks. All of these situations create an Internet connection which could be exploited to compromise vote data.

If the EMS is exposed the Internet, it can be targeted and infected with malware intended to corrupt vote data. This malware can then be transferred the memory cards configured by the EMS for use in the individual voting machines and optical scanners.

Election officials are encouraged to take the following steps to ensure their voting systems are isolated from the Internet.

  1. Map the network: Except for the simplest networks it makes sense to use a commercial network mapping tool to map all of the routers, links, hosts and other devices on the network. The point is to determine whether any of the devices on the network to be isolated has a path (wired or wireless) to an Internet-facing router. (We should develop simple instructions on mapping a network.)
  2. Physically disconnect from the Internet: If a device or host on the network to be isolated does have a path to an Internet-facing router, then physically disconnect it. Do not rely on software disconnection.
  3. Prefer wired over wireless networking: Wireless networks (WiFi and even Bluetooth) should be avoided on networks that are supposed to be isolated. Although they have nominal communications radii of only 300 and 30 feet respectively, devices with special antennas can listen to and interact with WiFi and Bluetooth over much longer distances, which can allow them to be attacked remotely.

The following steps can then be taken to ensure the data is securely backed up.

  1. Transfer data in and out of the isolated network using only clean media: No device that has ever been connected to the Internet should be connected to the isolated network. This means no personally-owned laptops or mobile devices should be connected. Use write-once media (like a DVD) or other clean media that have never used in a platform connected to the Internet (e.g. a thumb drive never used with any Internet-connected device). If virgin or clean media is not possible, at least use re-initialized media. (We should develop instructions on re-initializing media.)
  2. Revise procedures so that they do not depend on services unavailable on isolated networks: It goes without saying that there can be no email, or web access, or message service, or teleconferencing service, or VPN service, or network time service, on a network isolated from the Internet. But it is important to recognize that even software updates cannot be done by direct downloading from online sources to an isolated network, and neither can file transfers. Updated software and database updates should be physically carried to and from the isolated network on write-once media. A thumb drive is not a good choice because it would have to first be written on an Internet-connected device and then read by a device on the isolated network, which is unsafe.
  3. Voting networks should not be connected to Internet facing systems, online ballot marking systems, etc. If the state received ballots over the Internet, via email, fax or an online ballot transmission system this should be quarantined and isolated from the voting system network.

Voting systems on an intranet may be vulnerable to Stuxnet-style attacks

  1. Do not use USB drives to transfer data to or from voting equipment of any kind. As the Stuxnet attack showed, USB drives can be a vector for transmitting software viruses.
  2. Vote casting equipment (such as Direct Record Electronic (DREs)) used by the public shall not have ports exposed (including wireless connections) other than those limited to activation for a voter to cast a ballot.
  3. Numbered tamper evident seals shall be affixed to each piece equipment placed in the field, with procedures to verify these seals (by number when appropriate) are intact. When equipment completes its use for the day (e.g., upon closing on Election Day or at the end of each early voting day), new numbered tamper evident seals shall be affixed to the equipment with logging of the number of those seals and a signature of the people affixing the seals. That includes vote casting and tabulation equipment as well as electronic poll books.
  4. Update software only from write-once media, such as CDs and DVDs, that is retained for future inspection. That includes voting system software, and operating system software. Do not update systems in advance by connecting them to the Internet, even if they are disconnected from the Internet during normal operation. Ensure when loading voting system software that it has been obtained from the authorized source and that it has received the appropriate certifications required.
  5. Train personnel in the chain-of-custody requirements as well as the proper inspection and use of the tamper evident seals. Clearly distinguish tamper evident seals that are intended to be removed by poll workers and replaced later from those that should remain during the entire voting process.
  6. Ensure that all equipment has tamper evident seals that prevent any changes to programming or set up information (e.g., ballot definition files).
  7. Give a pre-printed list of all equipment at a polling place along with the numbers of all of the tamper evident seals as part of the materials to the chief election official for that polling place.
  8. Retain the temper evident seals that are removed for opening the polls and retain them to election headquarters at the close of polls on Election Day or other earlier appropriate times
  9. If the voting system requires the re-use of flash media, the media should be re-initialized from a clean device before use. (We should develop instructions for re-initializing media.
  10. Voting machines can get ballot images downloaded from devices that are configured at county headquarters on machines that may be connected to online VRDs and not properly airgapped. If the computer that has configured the memory cards was exposed to an online attack and infected with malware designed to impact votes, it can then spread through the memory cards to the individual machines.

Security procedures for States that receive ballots over the Internet.

One of the most common methods of infecting a computer with malware is to infect an attachment with malware that is transferred when the receiver clicks on the attachment. For states receiving ballots by email or digital fax, their computer system will be highly vulnerable to malware infection. States are urged to take the following precautions.

  1. Voters should be encouraged to vote by postal mail as much as possible. Military overseas voters should be informed of free, expedited postal mail return options. Voters should be warned that ballots returned electronically may be subject to hacking and may not be counted as cast.
  2. For states which allow ballots to be returned by email or digital fax, election officials should quarantine the computer used to accept emailed ballots and ensure it is not connected or networked to the voting system network or the EMS through Ethernet or wireless means.
  3. For states which permit ballots to be returned electronically, scan all incoming email and digital faxes for malware; the mail program should be configured to verify that attachments are of the expected type and fall into the expected size range. [1]*
  4. Ensure ballots returned by email are printed for counting, not electronically transmitted to the EMS for counting
  5. Election offices should transfer ballot files to the online ballot marking system via brand new or securely wiped and reformatted portable media such as a flash drive or disk. Do not connect the ballot marking system to the Election Management System.
  6. For a voter using online ballot marking systems, election officials are encouraged to hand count these ballots, avoiding the need to remake these ballots.
  7. If the 2D barcode is used, implement a process for careful checking of the remade ballot’s printed choices against the original voter-marked choices to ensure all the voter’s selections were captured correctly
  1. If election officials must re-make ballots, do so directly from the voters’ choices marked on the ballot rather than electronically remaking the ballot from a barcode. (If remaking the ballot, the original should be retained and used to audit remade ballots for accuracy, and used in case of recounts.)

How can we leverage audit trails and logs to detect possible errors or fraud?

  1. Maintain a clear chain-of-custody for all paper ballots and electronic media containing individual or aggregated ballots, with record-keeping that documents transfer along the chain-of-custody. Two people should accompany transfers of ballots and media.
  2. Maintain appropriate records to ensure that each batch of ballots is included in the aggregation exactly once.
  3. For early voting and early tabulation, maintain controls to ensure no release of voter selections occurs prior to the close of the polls on Election Day and that the equipment and the cast vote records and tabulations are not tampered.
  4. Report election results incrementally on election night at as low a level of detail (such as by precinct) as feasible from an election reporting system connected to the Internet. Consider using the Election Results Reporting NIST standard. Retain these incremental reports in persistent form. For example, a CD or DVD of the accumulated results can be burned (and retained) each time a CD or DVD is loaded from the internal ballot tabulation or aggregation system.
  5. Help jurisdictions find ways to evaluate quality of audits and surveillance
  6. Encourage precinct-level reporting to enhance transparency
  7. Encourage audits of all paper based systems
  8. Focus attention on voting system audit logs: look for anomalies, report and investigate any ASAP.
  9. Develop recommendations for recounts and procedures.
  10. Election officials should do everything they can to encourage citizen participation in this part of the canvassing process.

How do we protect the security and integrity of online voter registration systems?

  1. Send postal notifications to old and new address when registrations are changed, especially when it is done online.
  2. Provide paper voter-lists in the precincts, as backup to the electronic pollbook system; credentialed party representatives and citizens may be permitted to inspect/audit these in advance. When provisional ballots are used, officials must systematically check the provisional ballot envelopes and tally the field that tells the reason why the voter was not issued a regular ballot.
  3. Deploy mechanisms such as commercially available intrusion detection and antivirus systems to reduce the risk of cyberattacks or insider misuse.
  4. Minimize the use of VRD systems for other purposes, and minimizing the amount of non-VRD-related software installed on it.
  5. Limit the number of access points to the VRD with access to particularly sensitive information such as complete or last-four digits of Social Security numbers.
  6. Obtain independent security review of the VRD system before deployment and periodically thereafter through penetration testing.
  7. Track and logging all changes to VRD data and systems.
  8. Establish access control policies that:
    • Do not grant the same privileges to all users; rather the policies should group people by established roles and geographic areas. For example, the security policy might give the same level of privileges to all data entry officials for a particular county, but privileges should be different for VRD administrators.
    • Minimize the number of people who receive privileges both to access each piece of information and to grant access to others.
    • Ensure that each person is granted only the minimal set of privileges needed to do his or her job.
    • Cover all records stored in the VRD including records on both voters and non-voters.
  9. VRDs should use access control mechanisms provided in the database management systems provided; trying to implement access control entirely at the application level leaves greater opportunity for security mechanisms to be bypassed or compromised.
  10. VRDs should create public logs of all changes to the list of authorized users and their access rights, and any changes to either of these should require authorization from two different persons.
  11. Authorized users of the system should receive security training, including how to protect passwords and how to resist social engineering attacks (attempts to deceive someone into performing certain actions), and the importance of never sharing passwords.
  12. Retain older versions of access control policies, along with their dates of applicability, and consider making those available to the public to increase the transparency of the system.

Administrative Privileges and Emergencies

  1. The number of people with administrative privileges for the VRD should be limited; very few users should have the ability to grant access to others.
  2. People with administrative access should not be allowed to grant themselves new access privileges unilaterally; rather, such a change should require the consent of another administrator.
  3. Officials should create rules that allow trusted election officials to increase temporarily the privileges available to others during emergencies in a controlled and fully audited manner.
  4. Emergency overrides should require two-person authorization and generation of detailed audit logs.

Security Metrics

  1. Those responsible for managing VRDs should measure how effectively they have limited VRD users' privileges by determining how many people have access to how much data and by tracking effectiveness over time using these metrics.

Protecting Against Attack

  1. Secure all communication channels used by the system. Anything transmitted over open communication networks, such as any wireless connection, the Internet, or the phone system, should be protected using end-to-end cryptography.
  2. Use firewalls to severely limit connectivity between internal and external networks.
  3. Deploy detection mechanisms to detect any penetration of system defenses or any insider misuse.
  4. Obtain independent security reviews of the VRD before system deployment and periodically thereafter. Establish a notification policy for notifying individuals if an unauthorized person may have obtained their data.

Dealing with Security Failure

  1. A recovery plan should be in place to insure resilience from security failures; this plan should include steps like retaining historical copies as well as the latest, regular backups with offsite storage, etc.

Internet-based e-pollbook or voter check-in systems have the effect of exposing this critical data to attack, as well as the Internet-connected endpoint that receives voter check-in info, and every one of the devices as well.

placeholder

How do we communicate to the public about security features in place to support voter confidence in the election process?

placeholder

Relevant Resources

Contingency Planning


[1] National Institute of Standards and Technology NISTIR 7711 “Security Best Practices for the Electronic Transmission of Election Materials for UOCAVA Voters,” September 2011 “Incoming SMTP connections from the Internet should be routed through the mail gateway. The mail gateway should scan message content and filter or quarantine suspicious messages prior to delivering them to the internal mail server. If possible, this gateway should be configured to verify that attachments are of the expected type and fall into the expected size range, in addition to checking for malware.”

* Important: scanning may find attachments for executable malware programs, but may be unable to detect malware inside a PDF file, which are much more complex and generally cannot be found by scanning
 


Voting TWiki Archive (2015-2020): read-only, archived wiki site, National Institute of Standards and Technology (NIST)


ARCHIVE SITE DESCRIPTION AND DISCLAIMER

This page, and related pages, represent archived materials (pages, documents, links, and content) that were produced and/or provided by members of public working groups engaged in collaborative activities to support the development of the Voluntary Voting System Guidelines (VVSG) 2.0. These TWiki activities began in 2015 and continued until early 2020. During that time period, this content was hosted on a Voting TWiki site. That TWiki site was decommissioned in 2020 due to technology migration needs. The TWiki activities that generated this content ceased to operate actively through the TWiki at the time the draft VVSG 2.0 was released, in February of 2020. The historical pages and documents produced there have been archived now in read-only, static form.

  • The archived materials of this TWiki (including pages, documents, links, content) are provided for historical purposes only.
  • They are not actively maintained.
  • They are provided "as is" as a public service.
  • They represent the "work in progress" efforts of a community of volunteer members of public working groups collaborating from late 2015 to February of 2020.
  • These archived materials do not necessarily represent official or peer-reviewed NIST documents nor do they necessarily represent official views or statements of NIST.
  • Unless otherwise stated these materials should be treated as historical, pre-decisional, artifacts of public working group activities only.
  • NIST MAKES NO WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT AND DATA ACCURACY.
  • NIST does not warrant or make any representations regarding the correctness, accuracy, reliability or usefulness of the archived materials.

ARCHIVED VOTING TWIKI SITE MATERIALS

This wiki was a collaborative website. NIST does not necessarily endorse the views expressed, or concur with the facts presented on these archived TWiki materials. Further, NIST does not endorse any commercial products that may be mentioned in these materials. Archived material on this TWiki site is made available to interested parties for informational and research purposes. Materials were contributed by Participants with the understanding that all contributed material would be publicly available.  Contributions were made by Participants with the understanding that that no copyright or patent right shall be deemed to have been waived by such contribution or disclosure. Any data or information provided is for illustrative purposes only, and does not imply a validation of results by NIST. By selecting external links, users of these materials will be leaving NIST webspace. Links to other websites were provided because they may have information that would be of interest to readers of this TWiki. No inferences should be drawn on account of other sites being referenced, or not referenced, from this page or these materials. There may be other websites or references that are more appropriate for a particular reader's purpose.

 

Created August 28, 2020, Updated February 5, 2021