:: extra ::

This is part two to my previous blog dated Sept. 11th, 2006. As I was coming into work this morning, I remembered that I had never finished my previous blog about why software development groups should ultimately be responsible for making their software secure and how we can help make that happen. That combined with a great viewpoint I read from Bill Joy titled “Software is not complete unless it’s Secure” inspired me to write this.

In a recent Rolling Stone article by Robert F. Kennedy, Jr. a second whistleblower from Diebold supports an earlier claim that unauthorized patches were applied to over 5,000 of the company's voting machines just before the 2002 Georgia election. The patches were allegedly distributed personally by the president of Diebold's election unit Bob Urosevich and were not certified at either the state or national level. Although Georgia state law requires that any changes to the electronic voting system be certified by the state, Diebold was allowed to certify their own changes due to a contract between Georgia Secretary of State Cathy Cox and Diebold, which effectively privatized Georgia's voting process. The whistleblower goes on to claim that similar patches have been applied prior to other elections, even at the national level, also without recertification of the machines.

If even some of these claims are true then what good does any public vetting or certification really do? Security gurus like Avi Rubin and David Wagner have worked with voters' rights advocates to make real progress towards requirements on public vetting and transparency into electronic voting machines. In particular, source code analysis and code review have been leveraged with great effectiveness to find and eliminate security vulnerabilities in the code that runs electronic voting machines.

But when the adversary controls the machines, the code and much of the election process itself (as was the case in Georgia in 2002), such processes provide sparse guarantees. It's time to demand that our votes be counted. Local, state and federal governments must be held accountable for defending our right to participate in fair, unbiased elections and verifying the security and correctness of the code that is actually used to run the election is paramount to these guarantees.

It's election season again. This post describes why I think voting is such a perfect exemplar of a security topic and summarizes the two big-picture questions that have to be asked about any new-fangled voting system. Those two questions give me an ideal place to stash my favorite links on voting.

Three things make voting an ideal security topic:

1. Voting is important. It's the foundation of our political system. If voting doesn't work, our system of government doesn't work.
2. Voting seems easy, safe, and trustworthy. The concept is easy to understand, the polls don't appear to be run by partisan thugs, and most voters come away believing that their vote has been counted. By and large, people trust the system.
3. Our track record is less than stellar. Looking back, we have a long history of election fraud and corruption. If you're wondering why we need to be worried about ballot box stuffing, election rigging, and widespread disenfranchisement, it's because we've seen them all before.

Part 4: The reason that security is such a challenge for the software industry
(see “Mom’s Warning” and “The Defender’s Dilemma” and “Patch and Pray” for parts 1, 2, and 3)

Why is security such a major challenge for the software industry?

First, lets consider “Quality Assurance” in the software industry. I have managed software engineering projects of all sizes from the simple to the massive, so I have had some experience.

But it is my experience prior to entering the software industry that has given me the best vantage to describe the strange practice of software QA. Prior to joining the software industry I spent my time making semiconductors. Like many industries, semiconductors have extreme and exacting quality requirements that have to be carefully managed and validated all along the process of manufacturing them. In semiconductor manufacturing, we test the equipment daily, we test the processes that we plan to use far in advance of putting them to practice in a fab. We even test the circuits while they are still just ideas by simulating them on a computer long before the first silicon dye is ever cut. Entire manufacturing lifecycles are modeled and tested to forecast the expected output so that we know precisely the results of our efforts. In each of these cases measurements that are simply unconceivable to most people, and involving distances and temperatures that can only be registered with microscopes can make all the difference between a profitable product and a disaster. Once they are completed those semiconductors are going to be put in all sorts of equipment that drive mind boggling reliability rates.

I got voicemail from Gary McGraw last week. As usual, he got right to the point:

"Hey Brian, send me an e-mail with the 5 best things that happened in software security lately. You know, five good things. Thanks." Click.

"Good things"? Hmm…. It seems like I spend all of my time thinking about bad things. Finding vulnerabilities, weighing risks, and always scrambling to keep up with all of the new security dilemmas that are looming. I could have rattled off a list of a dozen software security disasters and near disasters without stopping to take a breath. But good things? Gary had thrown out a most excellent challenge. (Tip: don't give Gary your phone number if you don't like such challenges.) Okay Gary, here's my list: