Those emails have prompted me to to go back 2 1/2 years in my history with the CCBOE, when throughout '05, I was taking information to our board, who had made their unwavering decision to buy lots of Diebold in Feb. '04,
- when the public could have no idea of what they were doing (their agendas had one word entries like "HAVA" when no one knew what HAVA was, or "Vendors" again with no explanation);
- then attempted to bully, intimidate, gag and otherwise quiet away all activists and information brought to them that said they should not make the purchase;
- and finally, in the same month that the Center for Election Integrity held their one forum, "Election Reform", with only one panelist, Bob Ney (then inches from indictment and now convicted for fraud, and one of HAVA's main authors that spread the electronic systems made by essentially 2 main vendors into every county across the nation,)
- on 11/11/05, in a non-announced, non-public gathering, the then-board signed Cuyahoga's purchase order that started the slipping away of 10's of millions of taxpayer dollars - for more work, no public verifiability, secret vote counting, the ability to have insiders undetectably manipulate our vote results, and more.
Since those old Blackwell tests have again worked their way into public light, and now to a much wider audience, it seems wise to revisit here, just a few of the '05 statements I made (in vain then) to our now-previous board.
(I will upload and link all documents mentioned as I have time.)
I begin with a paraphrase of an email I recently sent to some colleagues in SoS Brunner's Voting Rights Institute, her visionary action to each year bring new groups of activists and advocates, election officials, party officials, together to work toward the common purpose of finally reforming Ohio's elections. While the Institute and its constituents is public information, the only reason I paraphrase is that I've not asked permission of the one sender whom I address a couple of times, to use his name. All else is whole.
One poster said:
In my opinion, it is very important that we distinguish between
1) testing one or two machines in a controlled environment as was done 2003, 2004, & 2005 and
2) testing the machines in a realistic situation.
I replied:
I too am eager to know clearly what the stated GOALS are for this state testing.This is the statement I orally summarized and submitted to the record in writing at the 10/24/05 CCBOE board meeting the week after their supposed public hearing, where still the public had no access to Blackwell's Master Contract and the entire morning had been one long Diebold sales pitch, while the almost 100 in the audience who came almost unanimously to speak against the machine purchase, had 3 afternoon hours, to fit in about 9, 5-minute speakers (and while the board reserved the right to answer NO questions.) The following statement also reveals how fewe answers the year-long asking public had gotten - until the two days before "the hearing" when they suddenly but progressively put onto their website more than 800 pages of documents, not all immediately relevant - another form of stonewalling.
Until such a thorough plan about what is being tested, and for what, I don't think any testing can or should begin.
Yours are excellent points.
At least in the case of the Diebold machines, which I followed, while parallel CompuWare reports were coming out about ES&S, BOTH kinds of tests are necessary to do any kind of valid review of DREs, because:
1. Even the problems/risks found in the '03-'05 CompuWare studies, paid for by Diebold, with only the 11/03 study included as addendum to Ohio's Master contract indicating they would be satisfied - HAVE NEVER BEEN SATISFIED.
Mr. Blackwell, then as the "master' of the state '04 and '05 Master Contract (as he distributed and controlled HAVA funds) and with all county contracts and agreements needing to serve and go through his Master Contract ( a rather "strange" awkward, and almost powerless contractual arrangement for counties )- never insisted that the problems CompuWare found in '03 were fixed.
And many of those were NOT, even by 4/05 -the last of the 4 reports, or since.
Even the problems CompuWare highlighted were minimal, as pointed out by other states relying on Ohio's commissioned CompuWare studies, because CompuWare was both being paid by the vendors to help them make sales, while as a lab with their own liability, CompuWare needed to point out at least, the most glaring issues.
(And as you know, Ciber, which did the federal "certification" has just recently been decertified themselves for their poor practices and what they overlooked, as they too were paid by the vendors.)
2. As you point out, we have also now found through usage, that there are also many additional operational and security obstructions/problems that the Diebold machines also present, such as:
• soaring cost of poll worker training, with still too complicated and impossibility of properly running machines under a normal load -
• printers jamming;
• Voter Access Cards stopping after being handled 50 or more times,
• legs crashing;
• "tamper tape" left to impossibly "protect" our votes on removable memory cards, unable to really protect or easily show when tampering has occurred;
• small memory on GEMS server necessitating hours more work to batch and feed according to machine limitations; and GEMS inability to handle more than one operation at a time, vastly slowing down and adding work to massive tasks
• inflexible reporting - and data bases unable to "talk to one another"
• impossibility of proper L&A tests to be completed on every machine, which is necessary, just because of the sheer amount of months and personnel it would take to do so - so we use, in effect, worthless tests - to say we've done them.
• and on, and on, and on.....
What amazes me over and over again, is how nationwide, by having been led down and boxed into these few, in effect, totally insufficient, horrible computer options for voting, by a few serving a few select vendors, so that now, we keep going round and round in the same insufficient, horrible and growing circles - writing reports about the problems, that have basically been added to, not diminished over time, and the core of which have no answers other than to rid ourselves of those vendors, and start again with excellent computer designers, starting with our real election needs.
We end up buying into that the only way to solve these problems is by buying more layers and equipment from the same vendors who caused the problems in the first place, by providing insufficient, poor equipment and services, lowest cost and effort/highest profit for themselves. We even end up arguing about Holt, and unfunded mandates for the same useless and dangerous reasons.
I include here, a copy of an email I sent to then Cuyahoga board member Ed Coaxum in October, 2005, trying to dissuade Cuyahoga from buying Diebold when they did.
The biggest problem is, is this 2-year old email is still relevant! What is mentioned here, is a core of what the Princeton Report found at the end of 2006! And nothing has essentially changed since the Princeton report, other than more problems have occurred and been found, and millions more have been spent.
To: The Cuyahoga County Board of Elections - For The 10/24/05 Meeting
From: Adele Eisner
On October 21, 2005, the Government Accountability Office released its study, "Federal Efforts to Improve Security and Reliability of Electronic Voting Systems Are Under Way, but Key Activities Need to Be Completed", GAO-05-956. Unlike Diebold's paid Joe Andrew at your last meeting, this report, which was conducted in accordance with generally accepted government auditing standards during the first 8 months of this year and which included a widely diverse range of governmental and non-governmental reports and interviews, including the EAC, and NIST, states clearly that security is NOT the last and most minor issue to be considered with deployment of these black box machines determining election outcomes.
Vastly incompletely dealt-with security and reliability issues are THE ABSOLUTE priority issue. This report also affirms that security is THE issue on the minds of the vast number of people who have been standing nationwide against these DRE’s, knowing that methods and protocols have not yet been developed to allow public validation of what goes on behind closed doors and inside computers that are rampant with undetectable opportunities to easily manipulate election results - with unprecedented ease, and in wholesale quantities.
On page 22, the GAO report briefly reiterates its essence:
“Electronic voting systems hold promise for improving the efficiency and accuracy of the election process by automating a manual process, providing flexibility for accommodating voters with special needs, and implementing controls to avoid errors by voters and election workers. However, in a series of recent reports, election officials, computer security experts, citizen advocacy groups, and others have raised significant concerns about the security and reliability of electronic voting systems, citing instances of weak security controls, system design flaws, inadequate system version control, inadequate security testing, incorrect system configuration, poor security management, and vague or incomplete standards, among other issues.”
It continues later: ” In light of the recently demonstrated voting system problems; the differing views on how widespread these problems are; and the complexity of assuring the accuracy, integrity, confidentiality, and availability of voting systems throughout their life cycles, the security and reliability concerns raised in recent reports merit the focused attention of federal, state, and local authorities responsible for election administration.”
The report deals with everything fromThe citizens of Cuyahoga County have overriding our proposed purchase, instead,
- a publicly transparent procurement process,
- election administrators rigorously conducting their own protocol, not the vendor’s, for testing of each machine with each ballot style,
- to demanding background checks of software developers and vendor personnel- none of which is has been demanded in Ohio.
And we have a contract looming that has Diebold
- a highly partisan Secretary of State with future designs for his own advancement;
- demanding his boards of elections serve at his pleasure;
- having Diebold help him put online his obfuscating plan, which also allows himself be the ultimate hearing adjudicator for voter complaints;
- having Diebold help him create training videos with him and his own message included – just in time for his governor’s race;
- signing a contract that gives him the right to arbitrarily accept Diebold’s mere explanations of patches, certifications, or lack thereof;
- allows him to arbitrarily tell Diebold to do things that are not written in the contract, thus are not publicly seen;
- and allows him to stress a kind of confidentiality between the Secretary and Diebold that predicts litigation by citizens.
Further a 2004 California Task Force on DRE’s states:
- basically designing the initial testing of our machines which is to be completed during the first 30 days of “dog and pony show”, to assure our “acceptance” – ie.
- designing our proof that their machines and contents are all exactly alike, that they work accurately with all ballot styles, to prove their own security;
- and a contract that only demands of Diebold personnel who have made our software and will be the only ones inside our machines for at least five years with our “wonderful warranty”, that they
- not be illegal aliens,
- that Diebold pays their benefits and insurances,
- and Diebold says they know what they are doing. The heck with Diebold’s history of hiring and promoting ex-felons, charged with fraudulent computer coding, or others with difficulty finding jobs.
…the Compuware analysis of the four voting systems is not as critically rigorous as that employed by as Hopkins and RABA authors. The Compuware report does not characterize any vulnerability characterized as “high risk,” as being due to poor design, or based on the failure of the system designer to understand security principles adequately. Finally, the report appears to give no serious consideration to recommending that one or more of the systems might not be ready for deployment, rather than proposing ways to minimize the risks it did identify.And the authors of the highly regarded RABA report referred to, which was commissioned by the state of Maryland after Compuware and SAIC, to evaluate Hopkins and SAIC, and the Diebold AccuVote TS system itself, were critical of Diebold’s security architecture. This company whose principals work with the National Security Agency, concluded that Diebold’s software could not be brought to the level of “best practice security” just by upgrading it, or fixing a specific list of identified problems. They said:“It is our opinion that the current DIEBOLD software reflects a layered approach to security: as objections are raised additional layers are added. True security can only come via established security models, trust models, and software engineering processes that follow these models; we feel that a pervasive code rewrite would be necessary to instantiate the level of best practice security necessary to eliminate the risks we have outlined in the previous sections. Our analysis lacked the time and resources to determine if DIEBOLD has the expertise to accomplish this task.”
With these “drop in the bucket” examples, please do not again offer your overused, but non-valid replies that "no election is perfect", and/or "this is an evolving process”.
As you well know, no one is asking for perfection, only for reasonable security as set out by non-vested experts and for the public’s ability to reasonably be able to check those who handle the many yet unresolved security issues.
As to "evolution", obviously a computer purchase used to determine one-chance election outcomes affecting this planet’s future, is nothing like an individual or business who says “OK, we'll just buy this computer and upgrade as things get better.”
The 2006 elections, as HAVA well predicts are important, though its late starting EAC has only provided for voluntary and scant security guidelines for electronic voting by that date.
BEFORE ANY election is held on computers – and BEFORE millions of taxpayer dollars are spent on thousands of them, thus, concretizing the death knell to secure elections in this county too - whether the dollars come from the federal, state or county level, it’s up to YOU to serve the this county’s public’s interest in preserving our last vestiges of democracy and fair elections.
And should you decide not to do the right thing by continuing on your “roadmap to electronic voting”, I have a few questions regarding security:
1. John Washburn, the Wisconson computer expert in election systems and security, including LAT testing, traveled here to attend last week’s meeting. In the 5 minutes you allowed him, he handed this Board a full written report about LAT testing and machine pretesting, which I hope you’ve read and considered more seriously than procedures outlined from the company vested in its own machine’s rightness. His report and other experts in this field determine that to truly demonstrate all of 6,000+ machines’ logic and accuracy, lack of bugs, etc. this procedure, with even testing only 200 ballot definitions, would take a few years for 6 people to complete in 10-hour days, at a low estimate of 2 minutes per test. And this must be done and audited, before the public. Please describe your initial machine testing on each machine, that the SoS plan shows you will be doing in 30 days to provide assured acceptance, and your LAT testing procedures.
2. Please describe how and where you will store and seal these machines, once tested before and between elections.
3. Please describe how provisional ballots will be handled at the polls with these machines, what a voter will need to do, what a poll worker will need to do, and how provisionals will be validated.
4. Since signatures can change vastly over years, as mine has, please describe how you have updated your signatures on registration files, which for one thing may be used to verify provisional ballots.
5. Please clearly describe the process of publicly witnessed recounts with these cash register-like paper trails.
6. Please describe how, and how long you will preserve these paper rolls securely.
7. Please describe how you will supervise Diebold personnel, the standards you will use to hire or fire them, and how they will be audited as they have access to the coding of your machines.
8. Where will the public be allowed to view the central tabulator’s election night counting?
9. And last – a moment of silence for the death of fair elections, ironically played as a knee-jerk reaction to the Florida election debacle – which even then had less to do with chads, and far more to do with unethical Secretaries of State and political theft. Same story then as now, but primitive efforts and results compared to what now can come - even to Cuyahoga County - with your help.
The following was my 10/25/05 follow-up email to Ed Coaxum, who at least listened and asked questions about the documents I was mentioning:
10/25/05
Dear Ed,
To facilitate your locating the reports I referred to at yesterday's Board Meeting, I will attach them by email to you. I will also forward the URL of the 10/21/05 GAO Report, "Federal Efforts to Improve Security and Reliability of Electronic Voting Systems Are Under Way, but Key Activities Need to Be Completed", GAO-05-956.
I truly appreciate your serious and excellent consideration of this very serious matter.
To be sent:
1. California "Final" Report - Re: March, 2004 - which I quoted about CompuWare studies on Diebold, based opn their own direct experience, since CompuWare studies have also served as the main bases of security/reliability for Ohio's purchases.
2. The Maryland RABA Technologies Report, dated January, 2004 also known as the "Trusted Agent Report"
Though the above two reports were done before the implementation of VVPAT, and thus, direct much attention to the necessity of having voter verified paper trails, you will also see that both reports also clearly demonstrate that even properly done, VVPAT alone, is only a necessary minimum, and only a beginning to necessary election security.
The California study speaks articulately, and from that state's own direct experience, about the insufficiency of CompuWare studies (the ones used as main bases for the Ohio's Diebold purchase) to validly demonstrate Diebold's sufficiency for secure and reliable election deployment.
RABA speaks to Diebold's “lack of mature and systemic understanding of coding and security to achieve even minimum best practices levels.”
At the 10/24 BOE meeting I quoted RABA, via quotes in the California study. That was one of only 2 RABA entries that California included in their report from their Diebold experience, as they saw those points critical to emphasize.
The RABA quote can be found on page 23 of their full report, but I urge you to begin reading there at least at page 17 where RABA begins it's assessment of Diebold's previous DRE model - the Accuvote TS. The picture is far from "pretty".
The report also makes it clear that this highly regarded company, RABA, had nothing to gain or lose from being honest. Yes, they were being paid by the state of Maryland, but in this case, all that Maryland was paying for was a non-vested, highly expert opinion - not affirmation to make a sale, nor to push any preconceived agenda.
The California quote I used can be found on page 27 of that study:
" The Compuware report does not characterize any vulnerability characterized as “high risk,” as being due to poor design, or based on the failure of the system designer to understand security principles adequately. Finally, the {Compuware} report appears to give no serious consideration to recommending that one or more of the systems might not be ready for deployment, rather than proposing ways to minimize the risks it did identify."
I also urge you, if time precludes a full reading of the California report, to begin on page 21, Section IV. The section is titled Security. And then read to the end. It presents a very clear picture.
The RABA quote I used was:
“It is our opinion that the current DIEBOLD software reflects a layered approach to security: as objections are raised additional layers are added. True security can only come via established security models, trust models, and software engineering processes that follow these models; we feel that a pervasive code rewrite would be necessary to instantiate the level of best practice security necessary to eliminate the risks we have outlined in the previous sections. Our analysis lacked the time and resources to determine if DIEBOLD has the expertise to accomplish this task.”
As stated above, it is on page 23, and here, I urge you to at least begin reading at page 17, the assessment of the Accuvote, through the end (page 25.)
3. To demonstrate the above 2 points, I will also send you three successive CompuWare studies, 8/18/04; 1/26/05; and 4/15/05 as commissioned by our own SoS. Though they are linked to his website, I found them difficult to discover, if one does not go beyond the first layer of pages via guessed links, so I was not sure you were aware of them.
I will not, however, send the first CompuWare assessment, the one dated 11/21/03, as it is linked to the CCBOE website.
However, only portions of the first CompuWare study, the 11/03 assessment, are even addressed in the Master Contract. They can be found in Schedule C, Attachment A, "Diebold Risk Mitigation Plan", starting I believe, on page 49 of the Contract. I don't believe that "Mitigation" is mentioned at all, in the later contract addendum.
In the Master Contract, all that was contractually required of Diebold regarding such "risk mitigation", was that they respond to a portion of the list of risks that CompuWare had identified in 11/03. Diebold thus, copied a portion of the Compuware list, along with CompuWare's mitgation recommendations, and then added a column for Diebold responses. In the majority of those replies, Diebold just repeated the same two things:
1.that they had instituted a Key Card Tool for changing of authorized PINs - which they stated fixed a number of things - but which fix was identified by Compuware later - in the 8/04 report as a new and different risk, and which Compuware identified as a risk again in 4/05 - because Diebold had not changed it/ the last CompuWare recommendations had not been implemented. One would only know that however, by looking at each report.
2. Secondly regarding Diebold's contract mitigation statements -
Diebold paraphrased over and over in their Contract risk mitigation section, just what CompuWare recommended far too often for very serious hardware/software security risks that could massively change an entire election outcome. Diebold repeated: "We agree that administrative policies and procedures are an important part of a well run election and should be used to enhance security whenever possible."
You may note for yourself that CompuWare risk mitigation recommendations - as also pointed out by California, and by RABA - concerning major computer risks for huge-scale, and hard to detect election tampering by insiders is unreasonably and too frequently addressed by CompuWare as.... "administrative policies and procedures must be put in place...."
Many point out that certainly regular election security policies must be adhered to. But as RABA points out, when considering huge scale election risks, for people to rely so heavily on "administrative policies and procedures" - which all know may not be adhered to evenly among all election workers, and certainly not among all election day workers, one has to be both very foolish and very unwise.
The rest of Diebold's Master Contract mitigation replies consisted again of their own similar explanations of rightness, with NO expert counterpoint even demanded.
In the three later CompuWare assessments I will send, you will also note, for instance, that just as RABA had predicted, Diebold did not seem to know how to truly fix security concerns.
For in 1/05 they had added another "layer", another off the shelf security measure, Digital Guardian, for some detection of tampering and other preventions, but did not know how to configure this highly sophisticated tool, thus causing, again, more and different wholesale security risks.
By the next and last assessment I found, the one dated 4/05, though Diebold had then changed some things about Digital Guardian, they had again caused still more problems, while still not preventing Guardian from being uninstalled, or turned off.
This pattern repeats over and over, in many different ways, from one assessment to the next - with non-implemented recommendations and with exchanging one risk for another, sometimes worse, - all risks still too great.
Also, two of the three reports, stresssed that Diebold bring it's programming understanding up to CM2 engineering levels by the end of 2005, then quickly to CM3. Even InfoSENTRY referred to below talked about the need for Diebold to make it's programming more "mature" and up to these basic professional levels.
And even the last Compuware report, 4/05 still has many supposed mitigations still needed - along with high quality checks of them, I might add.
Though you may feel that a thorough look at these 3 last CompuWare studies is warranted, if time does not allow, much can be gleaned from just comparing the progression of risk/threat asssessments sections. Those sections begin approximately at the following pages:
8/18/04 - page 58
1/26/05 - page 17
4/15/05 - page 42
4. Next to the last, I will send 2 more documents from the SoS website:
a. the InfoSENTRY Report, also commissioned by the Ohio SoS, which was interestingly released the same date as the first CompuWare study, 11/21/03. The second half of its 46 pages is comprised of an iteration of what they term "Principle HAVA Security Sections".
InfoSENTRY continually points out the SoS great efforts, and the foolish need for speed. For instance, page 25:
"Ohio’s Secretary of State has undertaken an aggressive program to assess voting system security, including the condition of vendor’s hardware, software, and data transfers. The Security Assessment points up that no system can be truly secure until the plans, policies, and procedures of all of the voting system supply chain links are made stronger. The Security Assessment found no “show stopper” {their bold and underline} to indicate that the introduction of computerized voting systems in Ohio should be slowed or stopped solely because of security concerns. The Security Assessment found that Ohio’s election officials and the vendors who supply them with these systems must take many important mitigating steps in the near future to remedy security problems that do exist. "
They cover their own very risky statement at the end ..."must take many important mitigating steps" which is what Compuware always did too. And though they may have just been trying to sound flip, an election - at least a fair one - is NOT in any way comparable to a "show".
b. And the SoS's “Detailed Gap Analysis Findings” - prepared by his own office, dated February 26, 2004, and which is basically a reply to RABA. It states
"...our gap analysis found nothing of substance that had not already been identified by Compuware, InfoSENTRY, or SAIC, documented, acted upon, and presented to the vendors as recommended changes. For details of the gap analysis, refer to section “Detailed Gap Analysis Findings” on the next page. As stated in the Ohio study, { InfoSENTRY} “The Security Assessment found no ‘show stopper’ to indicate that the introduction of computerized voting systems in Ohio should be slowed or stopped solely because of security concerns.” The Ohio study found that the DRE systems could be deployed as scheduled, provided the vendors take necessary mitigating steps."
(And I add... if they say the vendors need to take mitigating steps, and the vendors and CompuWare state what’s needed are "election official administrative policies and procedures..." this sounds like a bit of buck-passing back and forth to me, with no one being held accountable.)
5. And last, I will send you the body of the email I received regarding the GAO Report, "Federal Efforts to Improve Security and Reliability of Electronic Voting Systems Are Under Way, but Key Activities Need to Be Completed", GAO-05-956, released on 10/21. It contains the URL for the full report.
Again, I apologize for the length of this email, and the number of emails to come. This seems, however, necessary to get a more valid picture from the information that has been released since last week.
I very much appreciate your consideration of this matter.
Adele Eisner
No comments:
Post a Comment