I have a couple of details to add, but first let me re-iterate that the system in question does have vulnerabilities which have been well known for years, and reference exploits are old news. Sure, Cylance techs did write some code to create a new variant on previous exploits, but as Princeton election security expert Andrew Appel noted, the particular exploit was detectable and correctable, unlike some other hacks.
Regardless of whether Cylance violated the unwritten code of reporting on new vulnerabilities only, and regardless of good intentions vs. fear-mongering effects, the basic premise is wrong.
You can’t expect election officials to modify critical voting systems in response to a blog. In fact, election officials should not be modifying software at all, and should modify hardware only for breakage replacement.
Perhaps the folks at Cylance didn’t know that there are very special and very specific rules for modifying voting systems. Here are 5 details about how it really works:
- The hardware and software of voting systems is highly regulated, and modifications can only be done following regulatory review.
- Even if this were a new vulnerability, and even if there were what some would claim is an easy fix, it would still require the vendor to act, not the election officials. Vendors would have to make the fix, and re-do their testing, then re-engage for testing by an accredited test lab (at the vendor’s expense), and then go back to government certification of the test lab’s finding.
- Election officials are barred from “patching” or any kind of unsupervised modification. This makes a lot of sense, if you think about it: someone representing the vendor wants to modify these systems, while each of 10,000+ local election bodies is supposed to ensure only the legitimate changes happen? That’s not feasible, even if were legal.
- Local election officials are required to do pre-election testing for machines’ “logic and accuracy,” and they must not use machines that have not passed such testing, which in some localities must also be signed off by an elections board. Making even a legitimate certified change to a system 4 days before an election would invalidate it for use on election day. Consider early voting! It is really many weeks since modifications of any kind were allowed.
- So there is no way that a disclosure like this, with this timing, could ever be viewed as responsible by anyone who understands how voting tech is regulated and operated. I expect that it didn’t occur to the Cylance folks that there might be special rules about voting systems that would make disclosures 4 days before, or even 4 weeks before, completely impractical for any benefit. But regardless of a possible upside, it ought to have been clear that there is considerable downside for fear-mongering the integrity of an election a mere days before election day– especially this one.
And that would still be the case if this were a new finding. Which it isn’t.
Making a new variant exploit on a vulnerability well known for some time is just grandstanding, and most responsible security folks steer clear of that to maintain their reputation. I can’t fathom why Cylance in this case behaved so at variance with the unwritten code of ethical vulnerability research. I hope it was just impulsive behavior based on a genuine concern about the integrity of our elections. The alternative would be most unfortunate.
— John Sebes, CTO