and Transparency Subcommittee (STS) Conference Call *
Alan Goldfine, Alicia Clay, Allan Eustis, Angela Orbaugh, Anoop Singhal,
Barbara Guttman, Bill Burr, David Wagner, Donetta Davidson, John Kelsey,
Nelson Hastings, Patrick Gannon, Ron Rivest, Santosh Chokhani, Sharon
Laskowski, Wendy Havens
Administrative Updates (Allan Eustis):
Independence (SI) Impact on Access Control and System Event Logging
on Access Control and System Event Logging were forwarded around to
STS members. The access control document was presented (in substantially
the current version) at the March 2006 TGDC meeting, edited, and put
in final VVSG 07 format. The event logging document has received NIST
review, it needs to be reviewed by STS and TGDC.
software independence, do the chapters need to have more or less requirements?
Are there general guidance/broad principles that we should be using
to decide whether to add/remove requirements due to the new software
independence material? Answer by David Wagner and Ron Rivest is that
we should still be using the cost/benefit trade-off review. When you
remove or add a requirement based on impact from SI, make a note of
the discussion relating to this agenda item centered on requirements
that would require software versus hardware changes. Access control
requirements recommend multi factor access control that may need something
soldered to the mother board requiring a hardware upgrade. Logging event
requirements may require hardware upgrades that allow for writing to
write-once media. David Wagner and others expressed desire
for compliance be possible with only software upgrades. Donetta Davidson
stated that it should be made clear whether the new requirements would
make it necessary for hardware to be retrofitted or upgraded. This would
help TGDC and EAC when considering these recommendations. John Kelsey
is concerned that it will be hard to determine what kind of effects
the requirements are going to have on systems. Without a survey, we
are not going to know how many machines are affected. ACTION: Allan
Eustis and Nelson Hastings will discuss bringing this up at the next
The event logging discussion centered on the importance of keeping these logs. Are they being used? It was suggested that a requirement should be written that logs are forwarded to a central location, transmitted with the voting records. A system must have the capability so that everything can be pulled off the system at once ballots, event logging, etc. An inquiry was made whether there was a standard format for the logs. It was agreed that the requirement should be that the logs are in standard format or a utility provided to convert them to a standard format. There must also be a requirement saying that confidentiality must be protected when event logs are generated. The logs will be useful for finding problems with the system, e.g., shutdown or logout during use, software upgrades, administrator account access, etc. Further comments are requested by next week.
of Security Related Topics for Other Subcommittees:
of Innovation Class:
to the requirements we need to write. First, generic requirements that
specify what the voting system has to do. (Do we write new requirements
or identify requirements we already have? These are requirements that
transcend the architecture no matter what the architecture is.) Second,
we need to write setup procedures that identify the evaluation process.
This innovation class evaluation procedure needs to be ready when the
vendor has a new system. We have to allow for conceptual systems to
be reviewed before huge investments are made. The review process might
be in two stages. Stage 1, the vendor would provide a detailed description
of the system they would like to build with justifications. Stage 2
would be a regular full review with the panel of experts and VSTL review.
was asked if this panel would be EAC-run and if so we need to provide
a white paper outlining TGDC recommendations and allow for public comment.
STS teleconference is Tuesday, February 6, 2007, at 10:30 a.m.
policy / security notice / accessibility statement