Registered Technology Providers (RTPs)

A registered technology provider (RTP) is an organization that develops election technology and has met the minimum requirements in this section.

RTP Request Package

Technology providers register for the RABET-V program by submitting a completed request package to become an RTP. A complete package will contain the following information:

• Company name and legal address

• Sales and technical support points of contact

• Website URL

• Company description

To complete the request package, please follow this link to the RABET-V registration portal.

Program Commitment

RTPs must agree to the RABET-V program commitment. The commitment establishes the ethical and responsible behavior expected by all program providers.

The program commitment requires:

• Accurate representation of the product capabilities and its security provisions to RABET-V administrators, customers, and other stakeholders

• Organization implementation and regular assessment against an organizational security framework like the CIS Controls. The RTP must provide evidence of regular audits (e.g., audit letters, reports) to the RABET-V administrator

• Continuous product maintenance, including patching components within reasonable time frames

Submission Types

The RABET-V process begins with a product submission from an RTP. All product submissions are either an initial product submission or a product revision submission.

Initial Product Submission

The initial product submission is a first-time submission of a product to the RABET-V process. It includes statements about the product and the RTP that will be used throughout the RABET-V process. An initial product submission is required for each unique product an RTP would market and sell independently to an election jurisdiction. An RTP may be required to submit a new initial product submission if more than three years have elapsed since they last submitted a product revision submission.

Product Revision Submission

A product revision submission is for changes being made to a product that has already been through the RABET-V process. It includes information about changes to the product since the last submission.

An RTP can make a product revision submission at any time after that product has been verified through an initial RABET-V iteration. It can improve the likelihood of a smooth process by engaging the RABET-V administrator ahead of the submission about upcoming changes and understanding how the established test plan will be impacted by deviations from the previous version.

A product revision submission requires only the version change list, artifacts, desired deployment date, and version numbers, as well as any other meaningful changes, such as to the organizational process.

Submission Items

This section describes submission artifacts for the RABET-V process. Each description indicates if it is required for an initial product submission, product revision submission, or both.

Product Goals

The product goals statement is a description of the product’s purpose in non-technical language. It should be brief: a one or two paragraph summary of what the product is designed to do. The RTP can update the product goals during any product revision submission and should always confirm whether there have been any changes.

This description will be used by the RABET-V administrator in the submission review activity to determine if the stated security claims align with the product goals. For example, if the product goals include managing sensitive voter information, the RABET-V administrator will expect to see security claims designed to protect sensitive voter information.

Initial Product Submission: Always required

Product Revision Submission: When changed from last submission

Expected Usage

The expected usage statement describes how the RTP expects the election office to use the product. While it can communicate this through a number of means, a good approach is through high-level use cases that list the actions and interactions between involved parties and the system to achieve the product goals. Usage of the product will be limited to the use cases expressed in the expected usage. The RTP can update the expected usage during any revision submission and should always confirm whether there have been any changes.

Initial Product Submission: Always required

Product Revision Submission: When changed from last submission

Product Claims

The product claims workbook is a listing of requirements met by the product. This workbook is a product of the security requirements in the appendix of this program manual. The RTP completes and maintains this workbook for any submitted product.

For each requirement, the RTP will describe the implementation approach and whether the requirement is “Met,” “Partially Met,” “Not Met,” or “Not Applicable.” If the RTP only implements the requirement on certain components, it should provide details and the rationale for excluding it from other components. The RTP should include well-reasoned arguments for the implementation decisions and how they result in the appropriate level of security for the product. This approach allows each product to implement a unique approach to the application that is specific to its goals and usage. To ensure proper testing to meet or exceed the benchmark, the claims should cover the minimum controls to pass the benchmark. For example the 2023 benchmark states that 100% of Level 1 controls must pass and 50% of the Level 2 and 3 controls must pass.

The RTP can update the product claims during any product revision submission and should always confirm whether there have been any changes.

Initial Product Submission: Always required

Product Revision Submission: When changed from last submission

Process Descriptions

RTP’s should submit documentation related to the RTP’s development processes and operating environment. These should cover key aspects of software development as described in the OWASP Software Assurance Maturity Model (SAMM), which is used as the foundation for the organizational assessment.

The type of documentation requested includes:

1. Policy and compliance documents that are related to or help define efforts related to acquiring, managing, designing, developing, testing, and supporting software at the organization

2. Process related documents that help define which processes the RTP follows related to software activities

3. A representative sample of artifacts from completed activities related to the above policy and compliance or process related activities

Initial Product Submission: Preferred, but not required

Product Revision Submission: When changed from last submission and in cases when a new product is being submitted with a different business unit, development team, or development process

Architecture Documentation, Diagrams, and Related Representations

The architecture documentation and diagrams is a set of documents that fully describe the architectural design of the product. The product’s architecture can be described using diagrams, narrative, or, ideally, a combination of the two.

The RTP should submit documentation of the architecture at the system and the software levels. The system architecture should describe deployable subsystems, such as web services, databases, as well as hardware components such as firewalls and tablets. The software architecture should be described in terms of software components.

The term component is used generically within RABET-V to describe part of a product. Components can be broken down into subcomponents, as required. The architecture should be deconstructed to the level that exposed functionality (e.g., a particular web service, program API) can be identified.

RABET-V does not dictate a particular notation for submitted diagrams; however, where possible RTP’s should follow provided examples, which are based on UML component diagrams.

RABET-V uses automated analysis tools to evaluate software architecture without direct access to source code. RTPs will be required to process their source code through such tools in order to make further software level analysis possible.

Initial Product Submission: Preferred, but not required

Product Revision Submission: When changed from last submission

Product Environment and User Documentation

The RTP must provide access to a product environment that can be used by the administrator to conduct the RABET-V iteration. This should be a dedicated environment running the new product version. The administrator must provision user accounts and test data consistent with the expected usage statement. Test data should not include sensitive information, but may include data from real elections that is sanitized as necessary to remove personal information, product passwords, etc.

On the initial product submission, the RTP should include user documentation and be available for a meeting to assist the administrator in understanding the product usage. Updated documentation should be provided when changes are significant enough to warrant the update. User documentation must include the product version number it was written to support.

For many products, the product environment is the deployment of the web application to a sandbox hosting environment. For products like electronic pollbooks with physical devices, the product environment must include deployments of the product revision on physical devices provided to the administrator.

Initial Product Submission: Always required

Product Revision Submission: Always required

Summary of Revision Submission Artifacts

The RTP can submit a product revision to the RABET-V process at any time. Engaging the administrator about upcoming changes and consulting the existing Test Plan will help the RTP better prepare their submission.

All revision submissions require the following artifacts:

1. Change list - Indicates which components have changed and what level of change was made. It should reference the components identified in the architecture assessment activity

2. Artifacts - The product development artifacts identified in the existing organizational review. These artifacts provide the necessary information on product changes to conduct a review of the changes in the change list

3. Desired Deployment Date - Target date for deploying the product revision in a production environment

4. Version Number - The version number of the current product revision. It must indicate and correspond to code branches and change size (i.e. minor version number changes must correspond to minor changes)

A provider may change any of the initial product submission items during a product revision submission by providing updated information and alerting the administrator. If they are not submitting updates for any given artifact, the RTP will have to attest to there being no change.

Initial Product Submission: Not applicable

Product Revision Submission: Always required

Submission

Once the initial product submission or product revision submission package is complete, it should be submitted electronically to the RABET-V Administrator through the RABET-V Portal.

Items	Initial Product Submission	Product Revision Submission
Product Goals	Always required	When changed from last submission
Product Claims	Always required	When changed from last submission
Process Descriptions	Preferred, but not required	When changed from last submission
Architecture Documentation & Diagrams	Preferred, but not required	When changed from last submission
Product Environment & User Documentation	Always required	Always required
Summary of Revision Submission Artifacts	Not applicable	Always required

Product Listing

After going through the RABET-V Program, RTPs may choose to list one or more of their products on the RABET-V public listing site as a listed product. RABET-V listings include the following information:

• Company name

• Product name

• Product description, including version and configuration details

• Verification status

• RABET-V verification baseline met

• Date of verification

Provider Deregistration and Product Delisting

Failure to meet the requirements of the program commitment can lead to deregistration of the RTP and delisting of the RTP’s products. Activities subject to deregistration are any that breach the program commitment or other activities that undermine the intent of the RABET-V program.

Deregistration Process

The RTP will be notified of the reason for deregistration and given 60 days to remedy. If the breach of program commitment has not been remedied within 60 days, the RTP will be deregistered.

Delisting Process

If a product has not been resubmitted to the RABET-V program in the last three years, the product will be delisted. The RTP will be notified of a delisting action with 90 days notice.

Products may also be delisted if a substantial issue, such as discovery of a critical vulnerability, becomes known. Generally, the RTP will receive a cure notice and will be delisted 60 days after the notice.

In the event of a severe issue, the RABET-V administrator reserves the right to delisted the product immediately and until the issue has been resolved.