Future of Voting Systems: Future Requirements (Part 2)

At the recent NIST/EACG Future of Voting Systems Workshop II, EAC folks asked participants for input on possible future requirements for future voting systems. I subsequently blogged here some suggestions based on the experience of the TrustTheVote Project. Today, I’ll continue that theme, but first briefly revisit my prior remarks.

Evidence-Based, Component-Based, Modular

Let me say first that all of these suggestions are intended to be about voting systems that enable “evidence based elections.” As I said earlier:

• Evidence based voting systems are a category of voting systems for which demand is increasing.
• Requirements for them should be different from requirements for other types of voting systems, with completely different properties.
• Requirements should support testing and certification of individual voting system components.
• Requirements should be modular, or chunked, with chunks that can applied (or not) to different types of voting systems, and especially, to individual components.

One recommended net result of all these recommendations is that individual states could choose which requirement-chunks to apply to testing of individual components of evidence-based voting systems, so that the state election officials’ choices can drive a test and certification process that best fits the needs of the individual state.

Two Out of Nine

Lastly, of the 9 areas of future requirements that the EAC folks solicited suggestions, I previously wrote about 2 of them. For future requirements for evidence based voting systems …

Auditability: Yes, yes, and yes. The standards should embody the definition of evidence-based elections and the already well-agreed-to features to support them. For details of those features, see my earlier post.

Software Security: no. There should not be be specific requirements for specific types of coding standards, software quality, quality assurance, software configuration management, and so on. Rationale is in my earlier post, but suffice it to say that a voting system provider needs to rigorously document their own standards for software development issues, in order for a test lab to be able to reproduce the provider’s tests that demonstrate compliance to functional requirements.

This form of “self-attestation“, independently validated by a test lab, should be sufficient for state election officials to decide whether to not certify a system based on inadequacies in software assurance. Hobbling providers with pages of specific requirements — not necessary, and makes the whole process much more burdensome for all parties.

And Now, Three More

Risk Management: yes, but. Yes, voting system providers must document the threat model that they claim a voting system is designed for. However, much of the threat model should already be defined, in 2 forms: the definition of an evidence based system; and the functional requirements of specific voting system components. So really it is a matter of defining the threat model largely by reference, defining threat-relevant features also largely by reference, and documenting specific claims (that a test lab can test for) that the required functionality is there.

However, a formal risk assessment process is not something that a voting system provider should do — it’s not likely that every provider would even have the expertise in house. Instead, documenting a threat model, and functionality needed to operate within that model, is another form of self-attestation that (a) a test lab can validate, and (b) state election officials decide whether the model fits the needs of the state, and whether the validation was sufficient.

If a state wants to retain real software risk assessment experts to audit voting system source code and build procedures, they certainly can do so, but remember: the whole point of evidence based systems is that the election integrity does not depend on correctness of software. We certainly don’t want to rely on low-quality software, and there may well be a limited role for software proofs and other high assurance software techniques. However, a test and certification process (for evidence based systems) also need not require investment in stringent review or proof of correctness of every part of every component of a voting system.

Self-attestation about software quality (see above), with independent validation of attested claims, should be sufficient.

Communication Security: no. Consider a component-based future, with definitions of individual components of evidence based voting systems. No individual component should need to be doing network-based communication at all. Hence no need for communication security requirements other than this one: don’t do network based communication.

Physical Security: yes! But again, this is largely a matter of self-attestation, and also documentation. The voting system provider must define the recommended procedures for using an individual component, and where physical security related activities are required. Future voting system requirements might provide some examples of types of physical security issues to be addressed, such as access ports, locks, tamper-evident seals.

However, voting system providers need to define the component-specific physical controls. Test labs will need to test that when following the recommended practices for the component, the attested physical security measures are adequate, and that no other physical security issues were un-addressed.

But again, remember, perfectly physically secure systems, like perfectly secure software, is not possible. And the whole point of evidence based voting systems is to not have to require super-high physical security. We certainly don’t want easily tamperable components, but they don’t need to mini Fort Knoxes either.

Five Down, Five to Go

In the next and perhaps last installment, we’ll tackle the 4 remaining areas of requirements that EAC solicited input on: Access Control, Data Security, Monitoring and Logging, Documentation, plus Human Factors (Usability and Accessibility) which wasn’t one of the solicited topics, but is a very important part of existing voting system requirements.

The RDCV for all of those is “yes!” and the details consist of where existing standards or other ongoing work is relevant.

— EJS