CIS Logo
tagline: Confidence in the Connected World
 

A Guide for Ensuring Security in Election Technology Procurements

Part 6: Best Practices

This guide contains a set of best practices that election officials can use in their procurements to improve security outcomes. The best practices are intended to generate responses from potential vendors that can help election officials make informed decisions.

For each of the best practices, we provide a few classifications to help understand and prioritize their use. Each best practice can fall under multiple items within each category. For instance, a best practice may address hardware, software, services, or cloud-based IT, or it may apply to some combination of those. While we also provide descriptions of good and not-so-good responses, for all of this guidance, it’s up to the officials to know if a proposer’s response meets their needs. The online tool has more filtering options that we couldn’t neatly fit into the tables.

The following table provides the format of each best practice and includes:

  • A description of the best practice, numbered sequentially beginning with #1
  • A classification for system applicability as described above
  • The type of IT to which the recommendation applies
  • Suggested language you can put in your procurement documents
  • A description of a good response or activity
  • A description of a bad response or activity
  • Some additional tips, if any
  • Helpful references and links, if any
1
Practice: #1
Qualifications and experience of individuals proposed for work.                                                                          
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
Suggested Language:
Provide qualifications and experience of all proposed personnel, including subcontractors. In addition to basic qualifications (e.g., certifications obtained), include descriptions of experience in the area of elections or cybersecurity, or both. Where applicable, provide any specific knowledge and experience with state and local policies, architecture, and related aspects of the proposed work.
Good Response:
Bad Response:
While combined experience of a team is valuable, it's not always sufficient. To provide confidence that they understand the complexities of the election infrastructure as well as modern cybersecurity principles and practices, at least some personnel with significant time on the project will have experience with both elections and cybersecurity. Listing of key personnel without specific names or qualifications. Lack of personnel with direct cybersecurity experience. For those listed, years of experience are provided as a qualification but with a lack of specifics on skills or role in security.
Tips
  • Expect demonstrated experience doing exact work that has similar cyber challenges (preferably within elections domain)
  • Proposed personnel should have a number of years of experience appropriate to their proposed responsibilities as well as relevant degrees and certifications. (Note, however, that certifications can be obtained without demonstrating hands-on experience and should not, on their own, constitute qualification)
  • Look at the ratio of knowledge and experience in-house vs. with subcontractors. It is preferred to have qualifications in-house.
  • A team of resources who have worked together on relevant projects are preferable to one that has not worked together on prior engagements. The sum of the whole may be greater than the parts.
2
Practice: #2
Demonstrated past performance performing proposed work. Includes awareness of, and experience adhering to, applicable certifications and legal and regulatory requirements.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Provide references, including contact information, for past performance with comparable-sized customers and, in particular, in the election environment. Ideally, these will be public sector election organizations at a state or local level. Contact information should include those responsible for the security portion of the project. Include work in a similar legal and regulatory environment and in obtaining any relevant certifications.
Good Response:
Bad Response:
  • The contacts provided match the prior engagements that were similar to your organizations needed approach. Ideally you will recognize at least some of the organizations, if not the names themselves. The references should be true cybersecurity people, or as close to one as exists in the client's organization.
  • The responder demonstrates an understanding of the legal and regulatory regimes applicable to the contract and other work in which the proposer is involved, including knowledge of local and state requirements as well as any applicable federal regulations.
  • Generic statements of experience in the field or related field, but not citing any examples.
  • Generic statement that legal and regulatory requirements will be met during the work.
Tips
  • Require comprehensive disclosure of projects of similar scope and complexity by the proposer within the past three years, whether they are included as a reference project or not. You want information on challenging project engagements as well as successful projects when you are considering past performance.
  • Multiple references are a must. They can be from the recent past but should also include some more recent ones. Generally, references that are older than three years can be considered not useful. Evaluate references with points of contact to validate past performance to ensure that the proposer does quality work and has appropriate focus and experience with security requirements expected for this work.
  • If the proposer indicates the contact is the only allowable reference (some organizations may only allow a procurement official to field reference calls), explain to the procurement official that you are checking on technical cybersecurity credentials and would like to speak with a technical representative.
  • In addition to solicitations in which the proposer was selected, consider requesting information on similar solicitations pursued when the proposer was not selected.
References & Links:
3
Practice: #3
Proposer personnel policies regarding hiring and conduct standards, including background check, citizenship, and visa requirements.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Describe your company process for background checks and security training of those who will be working on the project. Individuals working under this contract must have the same or equivalent background screening and IT security training as government employees.
Good Response:
Bad Response:
Detailed descriptions of the types of vetting that occurs: criminal, financial, federal, etc. Statements that background checks are conducted with no additional details on the type or extent of vetting.
Tips
  • All personnel that work on the contract should have at least a national agency check and should be U.S. citizens. If some employees are not U.S. citizens, proposer should detail risk management procedures and provide results of background checks on those staff members or contractors.
  • Proposer should provide their processes to ensure that malicious employees cannot compromise security (e.g., limited access and two-person rule for most critical jobs or functions, with appropriate access monitoring in place).
References & Links:
4
Practice: #4
Proposer location(s) where work will be performed and equipment supported as well as administrative and facility security at the location(s).
System applicability:
  • All
IT type:
  • Services
Suggested Language:
Provide all work locations and descriptions of physical and logical security requirements, handling of sensitive materials, and emergency and disaster backup provisions. Describe how you will manage various work locations from the perspective of election security. This includes adherence to government requirements that all work and data storage be maintained in the United States, as applicable.
Good Response:
Bad Response:
Describes any work locations and, if multiple, the work performed at each. Facility security descriptions do not need to provide precise measures but should state basic approaches such as entry door badge requirements and presence of security systems.
  • No defined policies. Not responsive to stated requirements (such as if, in the RFP, you state that personnel must/must not work in specific locations).
  • Failure to specify the locations at which the proposer anticipates work. Vague statements about commitment to security and maintaining properly secure facilities.
Tips
  • Care should be exercised in using out-of-country contractors or contractor personnel who are not U.S. citizens. They are not inherently bad, but the government needs to be aware that there are risks that will be more difficult to quantify and control. Moreover, some countries may not be acceptable work locations and others may require special controls. Citizenship requirements may be set by the state or locality and may reflect the sensitivity of the products or services being procured.
  • For most specialized election products and services, it is reasonable to expect development to occur in the United States by U.S. citizens. Generalized hardware and software will often have global supply chains, but election officials may want to have the final product developed by a U.S.-based company or, at minimum, one with an established U.S. presence and reputation.
5
Practice: #5
Training procedures for the proposer.                                                                                                                              
System applicability:
  • All
IT type:
  • Services
Suggested Language:
Describe security training requirements for personnel. Include descriptions of different training for different types of personnel (e.g., system administrators, developers, administrative). Confirm that these same requirements also apply to any subcontractors.
Good Response:
Bad Response:
All employees undergo security awareness training and those in sensitive and critical security positions have more in-depth training (e.g., threat identification and risk identification. Proposer should describe training content, frequency, and testing approaches. Basic statements that employees undergo security training without further description of the type of training. Failure to describe specialized training for critical positions. Indications that suggest security training is ad hoc or otherwise lacks a systematic approach.
Tips
  • Security training from a reputable provider is most common. Training provided by internal personnel is acceptable if the person is sufficiently qualified.
  • Look specifically for mentions of phishing, email, and browsers in training curriculum.
  • If software development and customization will be provided under the project, request specific information on secure coding and development curriculum.
  • Look for monitoring and reporting of training activities - e.g., 100% of all proposer personnel have completed required cybersecurity and awareness training.
6
Practice: #6
Company ownership, board members, and stakeholders.                                                                                                  
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Disclose all countries in which your organization operates. Describe the corporate structure and ownership (e.g., publicly traded corporation, privately held partnership, nonprofit). Disclose all board members or any entity with more than 10% ownership in the organization. Also, disclose any ownership in your company by non-U.S. persons or entities, regardless of ownership percentage.
Good Response:
Bad Response:
Companies with foreign operations are not necessarily a problem but should be disclosed and disclosures researched for accuracy. Foreign ownership is not in itself a problem; however, it should be fully disclosed and you may want to put restrictions on certain countries. Failure to fully disclose foreign activities or interests.
Tips
  • At minimum, you should ensure that the organization does not come from a country with sanctions against doing business in the United States or have investors that are restricted, such as under the Committee for Foreign Investment in the United States (CFIUS).
  • Regardless of percentage ownership, look for multiple foreign interests that may add up to a significant stake.
  • Include a clause in your contract requiring notification of any ownership changes to the election official.
References & Links:
7
Practice: #7
Proposer process for identifying and approving changes of key personnel who perform most critical management and technical functions.
System applicability:
  • All
IT type:
  • Services
Suggested Language:
Describe the review process for key personnel that perform critical management and technical functions. Also identify the timing of notification to the government when a change occurs and the plan for replacing those key personnel.
Good Response:
Bad Response:
Describes thorough vetting procedures as well as technical reviews. Indicates that the government will have the opportunity to review key personnel. With regard to contractor changes in key personnel, provides a sufficient notice period, typically at least 15 business days before the change. The replacement plan should indicate government review and approval and minimize any gap between personnel. States only that reviews will occur in an efficient manner and that replacements will meet required qualifications
Tips
  • The government may choose to define what constitutes a key person. Alternatively, the government can request that the contractor define their criteria for key persons and the specific roles that they are proposing be key.
  • Government should retain the right to refuse reassignment of a resource that remains employed by the contractor.
8
Practice: #8
Proposer authorization procedures for personnel with access to sensitive information and systems.      
System applicability:
  • Operation
IT type:
  • Services
Suggested Language:
Define sensitive functions and sensitive positions and describe how individuals involved in sensitive functions and with access to sensitive information are trained and tested for knowledge and job performance. Also describe your process for how access to sensitive functions relates to an individual's assignment as key personnel.
Good Response:
Bad Response:
Proposer clearly defines what constitutes a sensitive function and the related roles that are therefore considered sensitive positions. Personnel involved in sensitive functions should be trained and regularly tested (certified) for knowledge and job performance. Identification of specific personnel authorized to access sensitive information and systems as well as how and when that access will be revoked. Blanket statements of appropriate training or assertions that all personnel have substantial training, failing to acknowledge that certain positions require greater levels of training than others.
Tips
  • Look for proposers to identify administrator functions and who has access to those functions.
  • Look for references to new hire and termination checklists that are completed for each new employee and each terminated employee.
9
Practice: #9
Proposer policies and practices for subcontractor personnel.                                                                                
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
Suggested Language:
If subcontractors will be used under this procurement, provide details on each subcontractor and the parts of the project in which they will be involved. The government should preapprove all subcontractors. Describe your process for selection and management of subcontractors, including how subcontractors are evaluated on an ongoing basis for meeting security requirements. Describe what information subcontractors will be allowed to access and how you will monitor their activities.
Good Response:
Bad Response:
Subcontracting plans are complete and clearly define the tasks completed under a subcontract. Details are provided for how the subcontractors are vetted, selected, and managed. Plans to use subcontractors are incomplete or undefined. There is no evidence the subcontractors are vetted for security controls.
Tips
  • Most procurement offices will have specific requirements around subcontractor use and how requirements for the prime contractor apply to subcontractors. From a security perspective, it's important to ensure that all security requirements also apply to subcontractors-including those involving the security of the subcontractors' internal operations.
  • Background check requirements should always apply to subcontractors.
  • Monitoring of contractors and logging of events should have regular reporting, with sample reports available to the government.
10
Practice: #10
Proposer's regular process for identifying and remediating cyber risks, with particular focus on components and information that are critical for mission success and increased attention to these elements.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
Suggested Language:
Describe your processes for identifying specific cybersecurity risks and mitigating them in the election environment and how the implementation of the mitigation processes will increase the likelihood of success on the current proposal. Be specific and provide specific examples of how this process has been successful in both confirming proper implementation and identifying needed changes. Include lab testing and third-party testing you regularly employ.
Good Response:
Bad Response:
Includes identification of specific types of risks and the specific actions that were taken to mitigate them. These descriptions should be of a moderate to highly technical nature, referring to specific types of threats or attack vectors, specific port configurations, or the like. The proposer should be able to reference past experience and document their repeatable processes. Provides general statements about client satisfaction or periods of uptime without a known incident. Refers back to the list of engagements without providing specific examples of risk mitigated.
Tips
  • A good response may not refer to a specific contract so it doesn't reveal a particular client, but should still be able to provide substantial information on approaches.
  • It's OK for a response to be understandable by a non-technical reader, but it should give the clear impression that they understand the approach in a technical sense as well.
  • Ideally there should be process alignment with the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF), ISO 27000, or another standard risk management framework.
References & Links:
11
Practice: #11
Security processes that include incident handling, recovery, and contingency arrangements to ensure availability. Includes incident response, such as when and how the government will be notified in the event of an incident.
System applicability:
  • All
IT type:
  • Services
Suggested Language:
Provide a description of processes you use for testing, patching, and anomaly handling. Define, or provide documentation on incident handling, recovery, and contingency processes, including communication plans, backup procedures, and process for operational data availability. This should also include items such as log and audit, log analysis and assessment, and forensics capabilities. Define what constitutes an incident and any levels of severity. Include procedures for notifying the government in the event of incidents of each level of severity, to include responsibilities and liability. Additionally, provide a communications plan for handling an incident. If you have cybersecurity insurance, provide proof of coverage and describe any relevant details of the policy. [If the government has a security incident and event management system (SIEM) system] Are you capable and willing to provide logs into the SIEM used by the government?
Good Response:
Bad Response:
  • The incident handling process covers all major phases, through recovery and follow-up activities. Demonstrates the proposer's ability to adequately respond to a variety of incidents.
  • The best responses will include a thorough description of when and how the government will be informed of incidents for a given severity of incident.
  • If asked, the proposer should be able to provide logs into the SIEM.
Does not clearly identify all phases of incident handling. Procedures are general. The proposer demonstrates no experience or competency in handling incidents.
Tips
  • The communications plan should demonstrate preparation for public communications regarding incidents and breaches (e.g., holding statements, qualified individuals with experience in incident response and media, messaging management). Consider the Belfer Center's Incident Communications Plan template for an example of how to construct a good plan.
  • If you are operating a SIEM, make it clear to the proposer that, even if they submit logs to you, they still maintain responsibility for detecting and addressing incidents.
References & Links:
12
Practice: #12
Transition plan for the end of the contract.                                                                                                                
System applicability:
  • All
IT type:
  • Services
  • Cloud
Suggested Language:
Provide a contract transition plan for the end of the contract.
Good Response:
Bad Response:
Specifies how transition will occur, including status and planning documents that will be provided. Defines the time for these documents to be provided. The plan should cover data, transitioning administrative rights, and other critical services and the approach to maintaining security throughout the transition. Lessons learned should be documented. Provides only remediation for its own performance or rationale to continue services.
Tips
  • If you have specific requirements for how data or systems should be handled in the termination of a contract, consider adding those to the language.
  • Transition plan should clearly state contractor's obligations during transition (e.g., side-by-side monitoring and operational management of systems with transition target; training documentation; change management database handoff; knowledge base handoff)
  • Transition plan could include readiness assessments during the transition (initial contractor assessing any perceived gaps in the transition target's capabilities and knowledge plus transition target's assessment of their readiness to assume responsibilities)
13
Practice: #13
Proposer's understanding of the scope of security tasks under the project, responsibilities and processes for monitoring adherence to those requirements, and security controls and their applicability in the solution.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Clearly describe expected scope of cybersecurity-related tasks under this contract and who (e.g., contractor, government) is responsible for executing those tasks. Also clearly describe how you will monitor service and development processes to ensure adherence to the security requirements of this contract. In providing these descriptions, clearly articulate the security controls you intend to employ in the solution. Include hardware, software, and physical security measures, the risks that they mitigate, and any residual risks resulting after implementation of these controls.
Good Response:
Bad Response:
  • Provides clear explanations of how the proposer will manage cybersecurity risk throughout and beyond the period of performance.
  • Provides a specific standard or known set of controls. Descriptions include which controls apply to the specific work and why some controls do not apply. These descriptions should demonstrate knowledge of the standard and how it applies to the work at hand.
  • Generic statements of implementing security measures throughout all aspects of the project.
  • Vague statements that implementations will follow standards, even a specific standard, but no demonstration of experience implementing the standard or standards.
Tips
  • The extent to which a proposal can define the expectations and responsibilities can provide insight into the preparedness of the proposer to address cybersecurity challenges. At a minimum this must include access controls, storage location(s) for data at rest, authorization to storage location(s), implementation of secure transport (confidentiality and integrity), and logging.
  • The proposer should be able to show how controls align with your desired best practices. To that end, it's reasonable to request that the proposal include a mapping to best practices documents such as the CIS publication, A Handbook for Elections Infrastructure Security.
References & Links:
14
Practice: #14
Proposer's understanding of the threat environment, its proposed risk mitigation approaches, and identification of any residual risks. Proposer's approach to keeping abreast of evolving security threats and taking appropriate actions in response to evolving threats.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Provide a description of the threat environment as it applies to the systems and their interconnections that are addressed in your proposal. Provide an assessment of the severity of threats and identify and align mitigation approaches to the threats. Also, provide an assessment of the residual risks following mitigation actions. Describe how you monitor ongoing security threat changes and respond to evolving threats, including monitoring common vulnerabilities and exposures (CVEs) and any ability to receive and share real-time threat information. Indicate participation in information sharing networks, including the Sector Coordinating Council of the Election Infrastructure Subsector (EIS-SCC), the Information Technology Information Sharing & Analysis Center (IT-ISAC), the Election Infrastructure ISAC (EI-ISAC), and others.
Good Response:
Bad Response:
  • Actual risks are shown, usually in a table that lists, for each threat, the risk likelihood and consequence presented by the threat-usually in low, medium, and high-both pre- and post-mitigation. Mitigation approaches are listed for each threat to show how likelihood and consequence changes. Mitigated risks are realistic; it is unrealistic for all risks to be mitigated completely.
  • Proposer should participate in information sharing networks such as the EI-ISAC or other similar organizations. If not a member of the EI-ISAC, the proposer should commit to being sponsored for membership if awarded a contract.
  • Proposer claims there are no risks or that they can be completely mitigated in all circumstances. No acknowledgment of residual risks. No stratification (e.g., low, medium, high) of initial or residual risks.
  • Failure to identify concrete sources of cyber threat information.
Tips
  • This should be a listing of expected threats to your systems and how those threats will be mitigated by the proposer. This listing should be thorough and indicate significant thought.
  • If the proposer has had a risk assessment performed internally or by a third party, ask to see their latest risk assessment.
  • The decision of the acceptable level of residual risk is yours. The proposer should be providing you a realistic evaluation of residual risk, acknowledging that no solution is perfect.
  • Not knowing or understanding ISACs is not disqualifying, but the proposer should be open to leveraging additional sources of security and threat information.
References & Links:
15
Practice: #15
Processes for moving information, whether digitally or physically, to ensure that security is maintained at all times. This includes moving vote data, such as for tabulation or election night reporting. Specific focus on security requirements that apply to information and communication products or services.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Describe your process for moving data, whether digitally or physically, while maintaining appropriate security protection and data integrity. This includes between organizations such as the proposer and proposed subcontractors, and, to the government, where applicable, during transitions to new systems and technologies. Also, specifically describe security requirements that apply to information and communication products and services.
Good Response:
Bad Response:
  • For digital transfer of data, describes both data-in-motion requirements for secure communications (e.g., transport layer security (TLS), hypertext transfer protocol-secure (HTTPS)) and authentication requirements.
  • For physical movement of data, describes physical security approaches including tamper-evident seals as well as chain-of-custody monitoring.
  • For deployment of new systems, describes expected downtime, backup procedures, and data security approaches during the transition.
Describes only that secure approaches are taken without describing specific measures for establishing secure transport of information.
Tips
  • These days, it's standard to use HTTPS for secure communications everywhere.
  • There may be two separate policies or processes: one for the solution and one for transferring data between you and company. They should only differ in that the policies and processes for communication amongst one another may solely be documented process, whereas the policies and processes for HW and SW you are purchasing should be baked in.
  • The proposed approach should align with a commitment to patching systems to ensure the latest security protections are in place, such as implementing the highest level of encryption standards.
16
Practice: #16
Proposer's agreement to implement a specific set of security controls such as the CIS Elections Best Practices.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Describe the specific security controls that you will implement. These may be international information security standards such as ISO 27000 or common sets of controls specific to elections, such as the CIS Elections Best Practices.
Good Response:
Bad Response:
If the government provides a set of controls, confirmation that the proposer will implement them. If the government does not provide a set of controls, the contractor should specify controls or principles it considers best practice. If provided: failure to confirm that the proposer will adhere to the set of controls. If not provided: failure to identify a candidate set of controls or best practices that the contractor believes will appropriately mitigate risk.
Tips
  • Include any set of security controls to which the proposer should adhere. Ideally this will be a public, recognized set of controls, but controls specific to your organization are OK too, whether as the primary set or in addition to others.
References & Links:
17
Practice: #17
Proposer's willingness to adhere to your organization's established security practices.                          
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Confirm that you will adhere to the required security practices under this contract. [Provide reference to the security practices or a link to them.]
Good Response:
Bad Response:
Confirmation that products and services will adhere to the required security practices. Describes experience implementing the same or similar security practices. References copy of proposer's own information security plan or practices. No demonstrated experience implementing similar security practices or a lack of clear commitment to properly implement them as a part of this contract.
Tips
  • Proposer should be willing to provide a legal attestation to remain compliant with the jurisdiction's cyber and information security policies, standards, and guidelines.
  • Proposer should affirm that any changes in requirements will be accomplished within a reasonable, specified time frame.
  • Ask for the proposer's own information security plan to show alignment with your organization's established security practices.
18
Practice: #18
Service level agreements (SLAs) for security that can be defined and agreed to as a part of the contract (either within the contract or as a companion document) that address day-to-day activities and activities around an election.
System applicability:
  • All
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Define specific levels of service for key work activities including performance standards for each service. These should include, but not be limited to: - Expected outcomes for normal security activities and, separately, around the time of elections. - Include your policies for response time, types of support (e.g., in-person, phone) provided. - Approach to ensuring continuity of mission critical services (e.g., failure restoral, patching and updates, and other relevant service component failures). Clearly describe trigger points for deploying updates and the approvals needed on both the vendor and government sides. This response should address vulnerability detection and remediation, patching speeds, and incident response and escalation procedures. For those products that cannot be readily updated, describe controls and monitoring that will be used to identify suspicious access or activity.
Good Response:
Bad Response:
Clear descriptions of pre-established measures of success that define specific quantitative goals that are stratified and provide definitions for each level (e.g., response of 15 minutes for critical issues, two hours for major issues). Specifies remediation actions for failure to achieve stated goals. Patching schedules and triggers for out-of-cycle patching are defined. Approval requirements are clearly defined. Clearly demonstrates sufficient capacity to be able to deliver according to the agreement. Demonstrated understanding of changing needs around an election. Not clearly defined service levels and normal maintenance/support functions. Solely an as-needed patching schedule with no definition for "needed." No description of which approvals are necessary to approve deployment. Lacks specifics for goals or provides qualifiers to statements such as "usually" or "typically"
Tips
  • Patching is a vital part of all hardware and software. Well-defined policies for patching should describe how, when, and with what approvals patching will occur, including any institutional steps required, such as re-certifications with the EAC.
  • While the proposer should include an SLA in its RFP response, details of that SLA are commonly negotiated.
  • SLAs should address patch and update management procedures for all systems managed by the proposer. Changes should generally be made on pre-production systems for testing prior to changes to production systems. The proposer should outline the request, approval, and testing process for emergency changes (i.e., critical changes with a limited window to apply to production).
19
Practice: #19
Proposer's experience in using standardized information technology lifecycle management processes for the exact scope of work. Includes proposer's lifecycle approach for development of its own hardware and software.
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
Suggested Language:
Do you have a standardized lifecycle management process for information technology? If so, describe your experience in using that lifecycle management process for work of the same scope as this project. Describe the lifecycle processes used to manage hardware and software. How will these processes ensure that updates appropriately address security considerations?
Good Response:
Bad Response:
  • Describes a defined, repeatable processes and adherence to standards and standard processes such as ITIL or Control Objectives for Information and Related Technology (COBIT). Provides concrete examples of prior use of the process in its work.
  • The proposer should use modern tools that are augmented by human inspection to validate that changes to do not degrade security.
Failure to describe a previously defined and demonstrated lifecycle process used in management.
Tips
  • You may want to tailor this question to meet the type of procurement you are conducting. For instance, if data management is a primary aspect of this work, this would be a data lifecycle. If it is an IT hardware or software product, detailing the product lifecycle approach most appropriate, to include, for example, development, service and maintenance, and transition planning. For a service, a project management lifecycle would be most appropriate.
  • You may want to specify that the proposer periodically provide a comprehensive list of all assets, including serial numbers, hardware and software versions, when they were last serviced, patched, updated, and upgraded (i.e., a transaction log of service on each piece of equipment). The service logs should provide sufficient data for you and the proposer to know when it needs to be upgraded, updated, or replaced, based on the policies, procedures, and contractual arrangements.
References & Links:
20
Practice: #20
Security plan for proposed work.                                                                                                                                        
System applicability:
  • Operation
IT type:
  • Services
Suggested Language:
Provide the security plan for implementing the security requirements and controls for the product or service. In the absence of the detailed plan, provide an outline of such plan along with examples of security plans for similar products or services provided under similar contracts you have been awarded and successfully implemented. The plan will be finalized in coordination with the government during the period of performance. If using a reference standard to develop your security plan, please identify which one. As part of this, include whether you have a responsible disclosure policy for vulnerabilities and, if so, include it with your submission. Describe the scope of responsibilities, assignment/ownership of tasks, and processes and procedures for adhering to security requirements and controls for the product or service.
Good Response:
Bad Response:
Implementation plans should define security tasks, responsibility for tasks, and criteria for assessing adequacy of task results. Proposers should be realistic and assign responsibility in a meaningful way with consequences. Especially in an operation like elections that has strictly defined deadlines, proper planning matters. It will describe risks to the timeline and approaches to mitigating those risks. It should demonstrate an understanding of potential barriers, such as applicable laws and regulations or formal approval processes. Poorly developed implementation plans typically feature unrealistically aggressive timelines, oversubscribe resources, and underappreciate the potential for bumps along the road. An absence of or lack of detail in basic project management tools such as Gantt charts and handwaving of risks are hallmarks of bad implementation plans.
Tips
  • Implementation is the "who" and "how." A security implementation plan should describe the process of reaching a desired end state. In addition to basic timelines for implementation, it describes roles and responsibilities, resources needed to get the job done, and transition management.
  • Specifically request that risks be carefully addressed and provide some known risks (e.g., implementation is not complete by the freeze period prior to an election) and ask for their mitigations.
  • A system security plan (SSP) should be developed in accordance with a reference standard (like NIST SP 800-18) and should include information on how periodic auditing of the deployed system against the SSP will be performed to demonstrate continuing compliance. It should also address roles and responsibilities of contractor and government in achieving a formal Authorization to Operate or ATO, if that is required in your jurisdiction.
References & Links:
21
Practice: #21
Proposer's processes for monitoring adherence to standard information and physical security processes in its products and its own operations.
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Describe the security audits and penetration analysis performed on a regular basis. If conducted, provide annual security audit reports conducted by an independent auditor. Are you willing to be subjected to external analysis and penetration by an organization of the government's choosing? This may occur at the planning stage, during implementation, as a verification of proper implementation, or during operations. Provide examples of prior security testing and evaluation reports, vulnerability assessment reports, and any related reports. Additionally, the government may require contractors and their suppliers to provide security testing reports and independent audit reports from similar work to this project that details the effectiveness of security controls and demonstrates timely correction of issues.
Good Response:
Bad Response:
  • Contractor can provide history of past audits and penetration testing and resolution of findings. These should demonstrate sound processes and timely risk mitigation. Ideally, they will be from work similar to this procurement. They will show identified risks and mitigations. They should reflect adherence to a common standard or set of rules. If those rules are an internal set, that should also be provided.
  • Permission to conduct reviews and testing at any time during the contract using the government's chosen auditors (e.g., state auditors, National Guard, independent assessment specialists).
  • Summaries clearly written for this proposal or a generic statement of auditing practices. Submitted reports are incomplete or fictitious examples and do not contain recognition of risks that need mitigation.
  • Limits on reviews or insistence on the proposer conducting its own internal reviews.
Tips
  • These reports may be from an internal review team or external source but should have a report form. Vulnerability reports should cover not only assets deployed for your specific project but also for core contractor functions and services (e.g., if they do coding or configuration work on systems separate from yours, make sure they are also paying attention to vulnerabilities in those systems as well as your production/UAT/QA/test systems)
  • Claiming proprietary limitations is not acceptable for this, especially if a nondisclosure agreement is in place. As a potential client, you need to be able to review their practices. The proposer may redact items to protect the identity of clients but should be able to provide reports in some form. Often, you will not get a full report, but rather a summary showing findings. There may also be restrictions on sharing this information publicly. This is generally considered acceptable.
  • Products that are provided for use in elections should be subject to review before acceptance. Any item altered through a service contract should similarly be subject to review before being put into production. The contractor may wish to limit the frequency with which audits or testing occur. A reasonable frequency is once or twice annually or whenever a new product is deployed.
  • It is normal for contractors to produce vulnerability and penetration results that have residual issues. These may be false positives or be too difficult for the contractor to address currently. The contract should be able to explain false positives and address why any high or critical priority issues have not been addressed. If they are not addressed, the contractor must be able to provide you procedural or other mitigations they have in place.
22
Practice: #22
Companywide process certifications and demonstrated adherence to proposer's documented processes.      
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Provide evidence of certification or registration according to national quality or security standards. Describe your adherence to standardized quality principles, such as through registration as ISO 9001 (general quality) and ISO/IEC 27001 (information security). Both are strongly preferred. If you do not follow a standardized quality principle, provide your documented processes and evidence that you monitor adherence to those processes.
Good Response:
Bad Response:
Up-to-date proof of certified adherence to both standards. Organizations should be able to submit verifiable proof. Proposer can provide evidence of past testing and evaluation and related reports. Claims of adherence without certification. Claims of following an alternate approach that is not a well-recognized standard. Lack of evidence of testing and evaluation history.
Tips
  • Standardized quality principles are an objective way for an organization to demonstrate that it understands and adheres to industry best practices. It may be acceptable for an organization to not adhere to these principles, but, if so, it should be able to explain its rationale for not doing so.
  • Smaller organizations are less likely to have these certifications. At a minimum, they should be able to provide evidence they have and follow documented processes.
  • Organizations will often state their certification but not provide documentation. If an organization claims certification to a standard, ask for proof.
  • If an organization says it adheres to a standard but is not certified, it should have evidence of its own internal evaluations. These are not just checklists, but detail how the organization manages its processes. There are some instances, like with EAC certification, in which you should consider requiring certification.
References & Links:
23
Practice: #23
Proposer's supply chain management and selection process for suppliers and managing transitions when necessary, including contractor's approach to evaluating replacement components or new technologies evaluated for use in the environment to ensure adequate security. If open source software is part of the proposed solution, explain how you will vet the software.
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
Suggested Language:
Detail your approach to supply chain management, including the selection process for suppliers. Provide specific information including, but not limited to: - How do you handle content originating from non-U.S. sources? - How do you review suppliers and their products to ensure that they do not contain security vulnerabilities or malicious content and are free from unexpected or unwanted procedures? - Which processes are used to monitor compliance of suppliers to requirements of the contract? Describe any process for auditing suppliers' ability to maintain security in their development process. - How is information regarding supply chain issues shared among the organization and suppliers? - What is your process for managing hardware and software that is no longer supported by the supplier to ensure continued maintenance of appropriate security? Describe your transition process for changes in suppliers to ensure security measures are continually met. How will you maintain appropriate communication with the government for such products? Additionally, what is your proposed approach to evaluating replacement components or new technologies to ensure adequate security?
Good Response:
Bad Response:
  • Processes described provide confidence that proposer carefully evaluates origins and specific security characteristics of new technology or replacement components. Evidence of certifications or, absent certifications, evidence of supply chain risk management activities, such as requiring suppliers to follow established best practices such as NIST SP 800-161. The response should describe compliance monitoring requirements, testing practices, and (if not provided elsewhere) work locations.
  • Recognition of limitations in the updates process, such as that older components may not receive updates and that updates may be complicated by certification procedures. For those products that can be readily updated, description of a clear process for making updates and notifying the government when updates are available and the approach to implementing the update.
Statements that the contractor uses only genuine or quality components without any reference to a process, quality assurance, or requiring suppliers to implement specific controls.
Tips
  • It may be appropriate to rely on an outside evaluator to assess new technology and replacement components.
  • Open source software can be OK to use as part of a solution, but it should be long-standing, well-vetted software. Open source software can be as or more secure than proprietary solutions, but it, like all software, must mature.
References & Links:
24
Practice: #24
Processes for managing and documenting access to different categories of sensitive information.          
System applicability:
  • Operation
IT type:
  • Software
  • Services
  • Cloud
Suggested Language:
Describe how information sensitivity is categorized and how access to sensitive information is managed and documented for each category, including your ability to create reports and machine-readable data extracts for both private and public dissemination. Clearly designate responsibilities, obligations, and procedures for key aspects of a data governance plan (data owner, data steward, data retention, information sensitivity, etc.). Demonstrate your understanding of this jurisdiction's data governance policies and practices and propose a data governance approach as part of your submission. Your response should include how various categories are treated when transmitted, such as when and how information is digitally signed and encrypted.
Good Response:
Bad Response:
  • Acknowledges and properly addresses that different types of data have different sensitivities. Provides a sufficient stratification to address the different needs and describes appropriate controls for each. Should include descriptions of the types of data anticipated in the product or throughout the course of the project (e.g., voter personal information, candidate filings, precinct records).
  • Proposer provides a clear data classification scheme and also describes how it will be continuously applied to data in the system(s).
Describes an approach in which data are secured "as needed" or with "appropriate" security without clear thought on the types of data that will be encountered under the proposed work.
Tips
  • Proposer should affirm their acknowledgment and acceptance of requirements for jurisdictions to easily comply with a jurisdiction's laws around providing non-sensitive public reports and data subject to your open records/open data laws within the timeline required under those laws.
  • At minimum, the plan should describe which categories are signed and which are encrypted. For example, you should expect to see transmitted data of importance signed, while sensitive data should be both signed and encrypted.
25
Practice: #25
Controls on data and access, including where the data reside, who has access, and how access rights are maintained; encryption approach; and incident capabilities, including logging and forensics.
System applicability:
  • All
IT type:
  • Cloud
Suggested Language:
Describe in detail the controls placed on data and access to data. Include requirements for location, access rights, maintenance and enforcement of access rights, encryption, incident response and backup capabilities, and logging and forensics capabilities.
Good Response:
Bad Response:
All controls should have clearly documented policies. For each control, the contractor should either include a link to the policy or describe the recommended control or control options. Though most applicable to cloud service providers, this also applies to first-party providers in which the contractor provides data management or the government manages controls. In the latter case, it should detail the options for managing controls available to the government and the manner in which those controls are managed. Overly optimistic statements that the provider can implement any required controls.
Tips
  • Logging of events should follow a common data format, such as NIST SP 1500-100.
  • Look for data handling to include encryption for data both while in transit and while stored at rest.
  • Access to the data is restricted to only those with the need to see it, by established and documented access control methods.
References & Links:
26
Practice: #26
Cloud security options.                                                                                                                                                          
System applicability:
  • All
IT type:
  • Cloud
Suggested Language:
If the solution will be hosted in a cloud or multi-tenant environment provided by Azure, AWS, or Google, include information on the adherence to the appropriate CIS Benchmark for Cloud Service Offerings. Explain the reason for any deviation from that Benchmark and provide any additional options that are available. If using another cloud provider, include the full menu of security options and services offered by the hosting provider, and which specific security options and services are included in the proposal.
Good Response:
Bad Response:
The proposer should include all security options that are available, whether or not they will be used. While it's not necessary to justify every decision, the chosen set should make sense. Anything less than the full list of security options.
Tips
  • The goal of including the full menu is to see what the provider has available. You may want to include a different set of security options as part of negotiations.
  • Look for implementation of the solution in an approved "Gov" cloud with FedRAMP baselines of high and moderate, or the equivalent. This would cover many of the key security components, but documentation should be provided showing that secure features are enabled, such as encryption at rest.
  • Be sure to ask about specific data compliance requirements in your state and jurisdiction. For instance, many states require cloud providers to keep all data within the United States. If you have this requirement, be sure to explicitly ask about it.
References & Links:
27
Practice: #27
Use of open standards and common approaches in software and common data formats.                                        
System applicability:
  • All
IT type:
  • Software
Suggested Language:
For user- and client-specific software and applications, confirm on which types of systems and, where applicable, browsers the product will have full functionality. In general, products should be fully functional on a host of systems, to include netbooks (such as Chromebooks) and all major browsers. If managing voter or ballot data, provide the data format(s) you are using and identify common functions supported with those formats (e.g., risk-limiting audits)
Good Response:
Bad Response:
Applicable products are fully functional across a host of systems and browsers or, if not, a full description is provided as to why this is not possible. A lack of planning or formalized decision around the approach. Support only for specific browsers or systems that don't represent the whole of your environment.
Tips
  • Development toward specific systems--even if they are the only systems you have in your environment--is generally frowned upon. This goes beyond compatibility: if something is developed in such a way that it only functions on a specific system, this may indicate that the proposer is not using the most common, and thus best-vetted, standards.
  • While it is good to have flexibility to work across multiple versions of a browser, it should be expected that the software will be maintained to use the most current or very recent versions and have a policy of deprecating older versions that are no longer secure.
  • Security audit functions are typically performed outside of the system and thus it is important that systems make data available for auditing in common formats that meet the auditing needs of the election officials.
References & Links:
28
Practice: #28
Security architecture for proposed or required solution.                                                                                        
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Provide a full description of the proposed solution's security architecture. Describes completely how architecture will ensure security of election infrastructure.
Good Response:
Bad Response:
  • A good response will provide diagrams, examples of mitigation of threats and risks, and descriptions of a proposed security architecture. It should demonstrate that the proposer understands their systems and how they fit into the larger context. It should include descriptions of all system components and detail multiple layers of security, internet connections, firewalls, intrusion detection and prevention systems, and other critical components. It should describe the security approach for each aspect of the system.
  • When drafting a proposal, it's often difficult to determine how much detail to provide, especially if there are page limits. Concisely written proposals are a signal that a vendor has put thought into their work. For this reason, it's important to make it clear that the successful proposal will provide significant details on their approach to security.
It's OK for vendors to make claims that they use security approaches that are "state of the art," "best in class," "military grade," or the like, but they need to back up those claims with details of security architectures and processes.
Tips
  • Most proposers will be reluctant to provide detailed information in a public document (assuming your jurisdiction's laws require bid materials to be public). Work with your procurement team to allow for confidentiality of detailed security architecture information in your solicitation.
  • Expect layered architecture that partitions most sensitive data/critical systems from less critical/sensitive ones.
  • It's OK to put a page limit on proposals, but allow for additional pages for diagrams of security approaches. If a vendor has implemented in a similar environment, they'll be able to provide detailed diagrams fairly easily. This can help officials identify the best qualified proposers.
  • Some (or most) of your solicitation reviewers may not have the breadth or depth of technical knowledge to assess detailed security architecture materials. Consider carving out an assessment of these materials to a separate group of tech reviewers and incorporate their findings/ratings into the other evaluation materials.
29
Practice: #29
Approach to cryptography and key management for data security.                                                                            
System applicability:
  • Operation
IT type:
  • Software
  • Services
  • Cloud
Suggested Language:
Describe your approach to cryptography, including which cryptographic modules and protocols you use, and how you conduct key management and manage the secrecy of private keys, if applicable.
Good Response:
Bad Response:
Demonstrates understanding of where cryptography can and should be employed as well as familiarity with different types of cryptography and the rationale for the selection of the specific cryptographic solution proposed. In addition, thoroughly addresses cryptographic key management including protection of keys. General descriptions of the use of encryption as a means to protect data at rest or in transit.
Tips
  • Use of standard cryptographic modules is a must. We highly encourage you to permit only cryptographic modules validated under Federal Information Processing Standard (FIPS) 140-2.
  • This best practice is intended for specialized applications leveraging cryptography. Standard encryption, like websites with HTTPS, should be on all systems.
References & Links:
30
Practice: #30
Ownership of software and other assets.                                                                                                                          
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
If the proposal includes commercial off-the-shelf (COTS) or modified off-the-shelf (MOTS) software, address ownership of the software and design assets both during the project and afterward. Also, address whether source code and other artifacts will be held in escrow or delivered to the government during the project, and ownership of IP rights at the end of the project.
Good Response:
Bad Response:
  • Addresses ownership of all assets in the project, including software licenses and software developed (or modified) as part of the project.
  • Includes statements that code will be delivered to the government, put in software escrow, or a similar mechanism to ensure that the government won't be left with a build that can't be updated should the proposer go bankrupt or otherwise cease operations.
Insufficiently addresses ownership. The government should own licenses for COTS and MOTS software and should have a process for accessing source code for any proposer that has even a small risk of going out of business.
Tips
  • Some companies may not be willing to participate in software escrow. This may be OK, especially for larger, more established companies (such as Microsoft©) that are unlikely to go bankrupt and over which you have little contracting leverage. But for smaller organizations, the risk of failure is higher and should be mitigated.
31
Practice: #31
Certifications received for the solution, including EAC and applicable state or local security standards. Or, in lieu of certification, rationale for lacking certification and approach to ensure that security in the solution is mature and reliable.
System applicability:
  • Operation
IT type:
  • Hardware
  • Software
  • Services
  • Cloud
Suggested Language:
Detail certifications obtained for the solution(s) you intend to deploy and how these meet applicable federal, state, or local security standards. If the solution(s) will not be certified, how will you ensure mature and reliable security? Additionally, describe your process for ensuring the certified system will be updated to reflect current security patches and updates to underlying components (e.g., operating systems, databases, communications systems)
Good Response:
Bad Response:
For products with a known certification process, evidence of certification. For other products, a clear process for assessing security. For all products, a clear description of how updates will occur and how that affects certification or other validation processes. Lack of demonstrated knowledge of certification processes. Lack of procedures or assessing the security of implementations.
Tips
  • You will likely want to modify this question for the given type of procurement, especially when thinking of voting systems vs non-voting election systems vs. backend COTS IT systems.
32
Practice: #32
Personal information management, including transmission and approach to protection.                                  
System applicability:
  • Operation
IT type:
  • Software
  • Services
  • Cloud
Suggested Language:
If personal information will be handled, describe how you will manage the minimization, collection, storage, and transmission of that personal information. Describe confidentiality and privacy approaches with regards to personal information.
Good Response:
Bad Response:
  • Gives attention to minimization of personal information as a first measure for reducing risk.
  • Where personal information must be collected, gives a thorough response for managing personal information through data security at rest and in transit. Provides anticipated encryption techniques and secure communication protocols.
Suggests only that personal information will be protected at all times, without describing specific approaches.
33
Practice: #33
Advanced endpoint protection on core systems.                                                                                                              
System applicability:
  • Critical
IT type:
  • Hardware
  • Software
  • Cloud
Suggested Language:
Confirm that you have advanced endpoint protection for any server or workstation that is either part of the core service offering. All systems accessing the core service offering must have advanced malware detection along with traditional anti-malware software. Specifically, the advanced malware software must allow root-cause analysis with forensics showing how infection occurred along with actions malware took.
Good Response:
Bad Response:
Explicit confirmation that the relevant systems meet the requirements for advanced endpoint protection. The proposer should be able to provide details on how it employs this endpoint protection. General statements of endpoint protection without a description of the specific software used or its capabilities.

Information Hub : Elections Resources


CONTROL: 1 --- ADVISORY CONTROL: 0
CONTROL: 2 --- ADVISORY CONTROL: 0
CONTROL: 3 --- ADVISORY CONTROL: 0

Pencil Blog post 18 Jul 2019
CONTROL: 4 --- ADVISORY CONTROL: 0