BOARD OF ADVISORS &
STANDARDS BOARD
VVSG TRAINING WORKSHOP
VVSG Tutorial
Security Testing Requirements Part 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.
* 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.
Page Created:
December 4, 2007
Last Updated:
July 10, 2008
Privacy
policy / security notice / accessibility statement
Disclaimer / FOIA
NIST is an agency of the U.S. Commerce Department