VVSG Tutorial\
Security Testing Requirements Part 1[^1]\
*\[Slide 1\]*

\[NARRATOR:\] This is Part 1 of the Security Testing Requirements
Training Modules for the next Voluntary Voting System Guidelines
Document. Parts 1 and 2 are presented by Dr. Nelson Hastings of NIST's
Information Technology Laboratory. The modules review security-related
testing requirements in Part 3 of the next VVSG including the conformity
assessment process and open-ended vulnerability testing. The
presentations include question and answer sessions with the Election
Assistance Commission's Board of Advisors and Standards Board.*\
\[Slide 2\]*

\[MR. HASTINGS:\] So, there are two specific sections where there are
security-related requirements that were developed: In Chapter 2 - The
Conformity Assessment Process, there are some parts there, and in
Section 5.4 - Open-Ended Vulnerability Testing.*\
\[Slide 3\]*

In the Conformity Assessment Process, the initial system build is one of
the items; unmodified COTS verification is another one; the voting
systems software version, and I'll talk about that in software
distribution for repositories, test labs and manufacturers.\
*\[Slide 4\]*

The initial build by test lab is the process used by a test lab to build
voting system software. This used to be called the witness build and the
trusted build. So that's what this initial build by the test lab is. And
it's based heavily on the information found in the testing and
certification program manual from the EAC, except it has a lot more
detail.\
*\[Slide 5\]*

It's performed by lab personnel and witnessed by manufacturer personnel.
It's really a two-step process: first establishing the build environment
that will be used to create the voting system software, and then
actually building the voting system software using that environment.
There are two ways of doing that: an initial build of the software and
the updating of previously built software. *\[Slide 6\]*

Basically the technical data package contains the procedures used to
establish the build environment as well as how the voting system
software will be built using that. It uses digital signature
verification on voting system software, because the manufacturers are
required to digitally sign their software as part of the technical data
package they deliver to the test lab. Then they also have to document
the actual procedures used, and if they deviate from the procedures used
that are described in the technical data package, there needs to be an
explanation for why that deviation occurred. At the end of building the
software as well as the build environment, you take a binary image of
the build environment and the build software onto unalterable media such
as a CD, and you digitally sign that.*\
\[Slide 7\]*

If you are updating previously built software, you could use that binary
image that was created when you first built the software. So you don't
have to actually go back and rebuild that build environment, because now
that you have that unalterable media on CD of that build environment,
that binary image, you can just use that to reestablish the build
environment. And then what you can do is place the updated source code
onto that build environment, and then, again, build the software using
the procedures found in the technical data package.\
*\[Slide 8\]*

The procedure used to verify that commercial off-the-shelf products are
unmodified for use in a voting system is outlined, and it's a process
used by the test labs. And what the manufacturers have to provide is
documentation and procedures on how to assemble and configure the COTS
products used by the voting system, because the test labs will be doing
that integration to verify that those products have not been altered by
the manufacturer. So the test labs will obtain those COTS products from
the open market.*\
\[Slide 9\]*

And then the test lab will assemble and configure those COTS products
into the voting system witnessed by the manufacturer personnel. And the
actual procedures used to do that need to be documented, and if there is
any deviation from that, that needs to be noted in that documentation.
*\[Slide 10\]*

Voting System Version: When we were looking at this, it really never
came out and said, after the test campaign, what version of the software
do you use? Obviously you use the one that went through the testing, but
we do talk about the initial build, and there could be changes to the
software as the test campaign progresses. And so if there have been
changes to the software, minor changes to the software, then you have to
perform a final build of that software at the end of the test campaign.
So that's what this requirement is really all about.\
*\[Slide 11\]*

Software Distribution Requirements are requirements on repositories,
test labs, and manufacturers. They can be used by jurisdictions. The way
it's set up, it provides traceability of software back to the master
software distribution package that's stored on a CD. So you can trace
back this piece of software to a physical piece of media.

It talks about records that need to be kept related to the creation of
master copies and copies derived from master copies of a software
distribution package.*\
\[Slide 12\]*

Some characteristics of a software distribution package include a
human-readable file that contains information about each piece of
software that's on that package, including the name of the package, the
manufacturer, the version, etc. Also, there has to be a digital
signature for each piece of software that's contained in the software
distribution package. And then there are some requirements related to
labeling and digital signature requirements for each piece of physical
media itself, so that you bind all that information that's on that one
piece of media.\
*\[Slide 13\]*

Repository Requirements: They should have a publicly documented process
to request copies of software distribution packages. They receive the
software that these repositories use from test labs, national
certification authorities, and jurisdictions, and digital signatures
should be verified before software is used for the repositories to
create software distribution packages. *\[Slide 14\]*

There are three types of repositories mentioned in the guidelines:
notary repositories which basically distribute integrity information in
the form of digital signatures and that kind of thing; escrow
repositories that hold software until formally requested; and
distribution repositories which provide software to parties that are
approved by the owners of that software.\
*\[Slide 15\]*

Test lab requirements in relationship to software distribution are that
they need to create software distribution master copies of the voting
system source code and executable code, configuration files,
installation programs, and third-party software used by the voting
system, and they need to provide copies of those to the manufacturer and
designated national repositories including the NSRL, as well as provide
copies of the build environment to the manufacturer and national
repositories.\
*\[Slide 16\]*

Manufacturer requirements include creating software distribution
packages that contain the source code of the voting system software,
configuration files, installation programs, and third-party software,
and a copy of that software distribution package has to be given to the
test lab as part of the technical data package.*\
\[Slide 17\]*

\[NARRATOR:\] Additional explanatory presentations on the Voluntary
Voting System Guidelines can be accessed from the Web site:
vote.nist.gov.

[^1]: \* Certain commercial entities, equipment, or materials may be
    identified in this presentation in order to describe an experimental
    procedure or concept adequately. Such identification is not intended
    to imply recommendation or endorsement by the National Institute of
    Standards and Technology, nor is it intended to imply that the
    entities, materials, or equipment are necessarily the best available
    for the purpose.