Hash functions are the most commonly used cryptographic primitive, and the most poorly understood. You can think of them as fingerprint functions: They take an arbitrary long data stream and return a fixed length, and effectively unique, string. The security comes from the fact that while it's easy to generate the fingerprint from a file, it's infeasible to go the other way and generate a file given a fingerprint.

Originally created to make digital signatures more efficient, hashes are now used to secure the very fundamentals of our information infrastructure: in password logins, secure web connections, encryption key management, virus and malware scanning, and almost every cryptographic protocol in current use. Without cryptographic hash functions, the internet would simply not work. At the same time, there isn't a good theory of hash functions. Unlike encryption algorithms, there are no secret keys involved; this makes it harder to mathematically define exactly what hash functions are.

The National Institute of Standards and Technology, NIST, is holding a competition to replace the SHA family of hash functions. "SHA" stands for "Secure Hash Algorithm." It was developed by the NSA in 1993 to replace the commercial MD4 and MD5 algorithms, and has been updated several times since then. All the SHA algorithms are very similar, and have been increasingly under attack, so NIST wants to replace them.

The competition is important because, unlike other technological standards, committee design — balancing the interests of diverse constituents — isn't conducive to good security. Security is best when it's designed by expert teams and then subjected to public review. And cryptography is best when it's chosen by competition.

In 1997, NIST held a competition for a block cipher to replace DES. Fifteen candidates and three-and-a-half years later, Rijndael became the new Advanced Encryption Standard — AES. NIST is doing the same thing for what it's calling SHA-3 (not, for some unexplained reason, the Advanced Hash Standard or AHS).

The deadline was October 31, and NIST received 64 submissions. This isn't surprising — I predicted 80 — as most of the 15 AES submitters were professors, whose students at the time have become professors themselves, with their own students. (If NIST does a stream cipher competition in another ten years, they should expect about 256 submissions.) These submissions came from academia, from industry, and from hobbyists. CIO magazine recently interviewed one of the submitters, who is 15. Twenty-eight submissions have been made public by the submitters, and six of those have been broken.

NIST is going through all the submissions right now, making sure they are complete and proper. Their goal is to publish all accepted submissions by the end of November, in advance of the First Hash Function Candidate Conference, to be held in Belgium right after the Fast Software Encryption workshop in February.

The group expects to quickly make a first cut of algorithms — hopefully to about a dozen — and give the community a year of cryptanalysis before making a second cut in 2010. After another year of cryptanalysis, NIST will choose a winner in 2011. Expect a final standard by 2012.

My advice for software developers is to let the process run its course. While it's tempting to use the new cool algorithms in your designs, it's far too soon to trust any of them. This process is likely to result in all sorts of new research results in hash function security, and some real cryptanalytic surprises. Give the community a few years to figure out which ones are good and which aren't.

I've previously called this sort of thing a cryptographic demolition derby: The last one left standing wins. But that's only partially true. Certainly all the groups will spend the next few years trying to cryptanalyze each other, but in the end there will be a bunch of unbroken algorithms. NIST will select one based on performance and features.

NIST has stated that the goal of this process is not to choose the best standard but to choose a good standard. I think that's smart; in this process, the best is the enemy of the good. While there's no rush to choose a new standard — the SHA-2 algorithms will remain secure for the foreseeable future — we don't want to analyze the candidates forever.

Personally, I was part of a group of eight cryptographers that submitted Skein to the competition. A decade ago, writing Twofish and participating in the AES process was the most fun I had ever had in cryptography. These next few years promise to be even more fun.

---

Bruce Schneier is chief security technology officer of BT. His new book is Schneier on Security.

Special Session: Situation Management I

Paper: Complex Event Processing approach for strategic intelligence

Authors: Nicolas Museux, Juliette Mattioli, Claire Laudy and Helene Soubaras

Abstract: One of the key issues of strategic intelligence within a crisis situation is to build an early assessment of the situation, based on a context sensitive information interpretation and through a well constructed situation representation. Our proposal is based on the conjunction of a conceptual modelling to represent situations out of document analysis and a reactive rule-based modelling to analyse them according to a domain knowledge and a goal. This paper focuses on this Situation Analysis process. But we present our global approach and sum-up the Situation Representation and its objectives. We introduce the Complex Event Processing formalism used for the analysis and dynamic recognition of such situations. We illustrate our approach through a case study taken from what happened during the energy crisis in California in 2001.

Presenter Biography: Dr. Nicolas Museux is a research scientist in the PLATON lab, at THALES Research and Technology. He had his engineering diploma in computer science in 1998. Then he started his Ph.D. in Applied Mathematics, Computer Science Systems and Control at the Computer Science Center of e’Ecole des Mines de Paris, and THALES Research and Technology. His Ph.D. focused on the application of constraint programming in distributing low-level digital signal processing programs onto multiprocessors architectures, to optimize data management and computing duration. After he obtained his Ph.D. in 2001, he worked until the end of 2004 on several projects in the PLATON lab linked with combinatorial optimization. Since 2005, Dr. Nicolas MUSEUX works on the Situation understanding research program. Its objectives are to identify, to specify and to design tools for situation model based reasoning in order to address situation analysis, risk assessment and situation projection.

Apologies in advance, for the length of this post…

In a perfect world…
… we’d know which specific threat agent was going to act against us and know the capability of that threat agent in absolute terms (e.g., pounds per square inch), as well as know (through testing) what our resistance capabilities are in those same absolute terms. If we had this information AND assuming this information was precisely correct all of the time, vulnerability becomes a clear and simple binary consideration — we will be or we won’t be.

Stating the obvious (anyway)
Losses occur when threat events take place that we’re vulnerable to. This is true whether we’re talking about weather events, human error, or malicious acts. Obviously, we don’t experience loss with every threat event, which means we’re only vulnerable sometimes — i.e., less than 100% of the time. This means there is some probability associated with whether we’ll be vulnerable to any given threat event. The process of measuring vulnerability is intended to help us understand what that probability is likely to be.

Simplest approach
Perhaps the simplest approach is to identify the threat community you’re analyzing risk against and simply estimate your ability to resist the capabilities of that threat community. For example, we might estimate that our web application is capable of resisting all but the top 2% of the cyber-criminal threat community — i.e., two out of a hundred hackers have the skill and resources to defeat the application’s security.

This works as a quick-and-dirty solution, and in many cases is good enough. Read on if you’re interested in a somewhat more involved approach.

Uncertainty
Unfortunately, in the real world we usually don’t know:

• Which threat agent is going to act next,
• What their capabilities are, or
• What our resistance capability is going to be

Making matters even more challenging:

• We don’t have an absolute measurement scale for some threat categories (e.g., human capability)
• Our measurements are imprecise (e.g., we can’t measure force or resistance perfectly)
• One or more of the values being measured may vary over time (e.g., hurricane wind speed varies throughout the lifetime of the storm, and strength can change throughout the lifetime of a control )
• One or more of the values being measured may vary across a population (e.g., not all hurricanes have the same wind speed)

When absolute scales apply
(Warning: This is an illustration and not an engineering exercise, for those who might want to argue details.)

Some types of threat categories can be measured using absolute scales (e.g., wind speed in miles per hour), which makes things a bit more straightforward. For example, thru testing we could estimate that a structure should be capable of resisting wind forces between 150 and 200 MPH.

By using a distribution to describe this measurement, we account for the fact that under some circumstances wind speeds of less than 150 MPH might compromise the structure, while in some circumstances the structure may be able to withstand speeds greater than 200 MPH.

If we wanted to measure the structure’s vulnerability to a specific type of storm (e.g., a tornado) we could plot a similar distribution for tornado wind speeds (black curve below). This distribution reflects the fact that wind speeds vary from tornado to tornado, ranging from under 100 MPH to over 300 MPH, with most falling in the 200 MPH range. (Keep in mind this is just an illustration and isn’t intended to reflect actual tornado data.)

In order to determine the probability of being vulnerable, we’d use a Monte Carlo function to:

1. Take a random value from the tornado distribution and from the structural resistance distribution
2. Compare the values — i.e., for this iteration, determine whether wind speed was greater than resistance
3. If wind speed was greater, increment a counter that tracks the number of vulnerable instances
4. Repeat a thousand iterations (or ten thousand, a million, etc.),
5. After completing all of the iterations, the vulnerability counter divided by the number of iterations provides the probability of this structure being vulnerable to tornado winds

When an absolute scale doesn’t exist (the human threat community)
Human threat capability can be boiled down to skills and resources. Because skills and resources vary from individual to individual, we can characterize threat community capability as a distribution. At one end of the distribution are those threat agents who have the least capability, while at the other end are those who are the most capable. As seems to be the case for most things in nature (e.g., weather events), the distribution is probably pretty close to being bell-shaped (i.e., the majority of threat agents fall somewhere below those who are most capable and above those who are least capable).

A “100% secure” control (if such a thing existed) could be illustrated as existing outside of the threat community capability distribution. It would be 0% vulnerable.

More realistically, we can in most cases expect that some portion of the threat population would have the skill and resources to compromise a control (shown below).

Now, because of the uncertainties regarding threat capabilities and control strength, it would be more accurate to describe control strength as a distribution as well. For example, we expect the control is at least resistant to 90% of the general threat population, and may be resistant to as much as 99%+ of the population.

This is fine as far as it goes, but it doesn’t get us the answer we’re looking for in most circumstances. Most of the time it isn’t enough to know our vulnerability to the general threat population. In most analyses, we want to know what our vulnerability is to a particular threat community (e.g., cyber criminals, nation-state intel units, etc.). In that case, we’d have to plot the capability of the threat community in question (red distribution).

With that plotted, we can run our Monte Carlo function again, generating a probable vulnerability by taking random samples from the control distribution and the distribution of the specific threat community in question.

The key to measuring vulnerability in the absence of an absolute scale is to use the general population capability as the comparative baseline for both control strength and the capability of the threat community in question.

Considerations
Of course, because some malicious threat communities tend to share knowledge and tools, there can be an equalizing effect, which potentially narrows the width of the threat capability curve (shown below) but likely wouldn’t change its fundamental bell-shape. The good news is that this narrowing effect wouldn’t alter how we measure. The bad news is that it does affect vulnerability, which we know intuitively anyway.

Another consideration is the fact that the capability of the malicious population evolves over time — i.e., the curve shifts to the right along the continuum. For example, at one time in the past DES was considered invulnerable to brute force cracking. It isn’t any longer. In other words, we could say that the control stayed in place along the continuum, but the capability curve shifted to the right. This highlights the fact that it’s important to maintain a bead on how threat capability evolves, so that you can evolve your defenses as well. Also, this is good fodder for the importance of defense-in-depth.

Concerns
An obvious concern is the inexact nature of these estimates and the potential for the analyst to estimate badly for various reasons. We’ve covered this issue previously in other postings, so I won’t go into it in depth now. Suffice it to say that yes, this is an imprecise measurement fraught with all of the goblins that any measurement approach is subject to. That said, keep in mind a few things:

• The ability to estimate effectively can be significantly improved using calibration techniques
• There’s no such thing as a perfectly precise measurement, whether you’re using a laser or the width of your thumb to do the measuring. Therefore, the purpose of measurement is to reduce uncertainty, not eliminate it
• You can apply confidence levels to your estimates, both to describe the probability of actual values being outside of the estimated minimum and maximum, and to shape the peakedness/flatness of the curve
• Monte Carlo analysis is designed to help account for the uncertainty in measures
• You should never convey to management that these numbers are precise. In my experience management won’t have any problem with this, as the numbers they’re given from other business disciplines have precision challenges of their own.

Bottom line — If you’re trying to quantify risk, then you have to quantify vulnerability. This is one logical means of doing so. What’s more, it seems to accurately reflect how we subconsciously evaluate and quantify vulnerability anyway, only it brings the analysis to the surface. And by bringing it to the surface, it allows us to better understand and analyze risk scenarios.

If there’s interest, I can provide a couple of examples in a future post. Also, if there’s interest, I can include an example where the threat event is due to error rather than malicious intent.

I know, I know- it’s late- but better late than never, right?

I really tried my best to take photos as much as possible. A quick note on the photography- because of the size of the rooms, it didn’t make sense to have the flash on, unfortunately it slowed the shutter speed, making some images blurry (sorry).

So Day 2 already felt like day 5 somehow. I had flown in early to be a tourist for a day or so but caught up with partners and other event-goers early, making it an especially long week. Wednesday was an eventful day. I have a great  Sins of Our Fathers session to share with you, a day with the Enigmas, and the Security Bloggers Party.

The highlight of the day’s sessions had to be the ‘Sins of Our Fathers’ breakout with an amazingly hilarious geek-filled panel including Daniel Houser, Ben Jun and Hugh Thompson. (Hugh unquestionably won the Most Entertaining Geek Award for the day). I was tweeting live from the session and took some photos of the interactive polls they intertwined in the discussion. They drew some interesting correlations between current security issues, such as SQL injections an ‘previous sins’, likening it to phone whistling. There were random notes about the inherent security risk of mixing data and coding together. View photos from session.

Then they talked about using good technology in a way that made it vulnerable. Examples, the Enigma code machines from WWII. (It was actually broken by the known plain-text gathered from repetition in contact initiation, and the mis-use of one-time-pads). They drew the line from Enigma to WEP and other algorithms that were okay, but mis-implemented.

There were a variety of other anecdotes, accompanied by audience-wide snickers, snorts and laughter. One story of tape backups, encrypted, with the key dutifully stick-noted to the case. Another of the secretary who type-writered all the 5.25” floppies. The story of the unmanned Predator aircraft flying unattended for about 5 minutes during a PC reboot. They were all tied into the topic nicely, and the guys did an outstanding job interacting and playing off one another.

One a more serious note- well, sorta- Hugh showed a clip from his participation in the documentary “Hacking Democracy” about the lack of security of electronic voting.

Here was something amusing… Their crypto list of
If you hear any of these, RUN!

1. Cryptography is expensive.
2. We have this guy that’s reallllly smart…
3. Wired EQUIVALENT encryption… . 
4. It’s “proprietary” security
5. It’s revolutionary NEW cryptography technology!
6. It uses DES- so its FIPS 140 compliant 

Some of the sins from the session…

• Engineering, Development & Management sins
• Using a good technology in a bad implementation
• Lack of metrics to indicate misuse
• Feature/mission creep - using item A for solution B
• Not teaching people how to use security
• Teaching them, but teaching bad habits
• Normalization of deviancy

I’ve spent long enough on that, there’s plenty more to share, but that session was so good, I thought it deserved some special attention. I did stay for the Cyber Storm II Panel, but that left more than ‘a little’ to be desired. I would have liked more anecdotal stories and a little more personality. The panel participants were knowledgeable, and I’m sure they were doing what they had been told, but it made for a very dry session, little content of interest, and much repetition. There’s a little live Tweeting from that session too.

Playing with the Enigma
At the Sins of Our Fathers sessions, I believe it was Ben that mentioned we had at our disposal not one- but TWO Enigma machines on the expo floor here are RSA. And BOTH were for our playing! They had it set so we could set the key and encode a message at the NSA booth, then take the encrypted message to the Cryptographic Research booth and use that Enigma to decypher the message. HOLY COW!!!!!! If their session hadn’t been so great I would have left right then. The only time I’ve seen these beautiful little pieces of crypto history, they’ve been fully encased in glass, and not for the touching. They actually let you set the rotors and punch the code in yourself so my buddy Eric and I ran right over to take full geek advantage of the situation. 

YES, that’s me with an Enigma, and I have more photos of the two Engimas.

The big highlight of the evening? The Security Bloggers Party of course! You get a whole post just for this topic, so stay tuned for that. I didn’t take photos here, because I felt pretty sure someone would be walking around with a camera. I need to find @ajolly (Apneet Jolly) and see if he has any- he’s usually fully equipped with a very nice camera…

# # #

We interrupt our regular schedule of blog postings to offer this special post for “Super Tuesday” given the subject matter. Hope you enjoy…

This year is a presidential election year in the United States. Selecting a new president is perhaps the ultimate example of the importance of having a trustworthy election process. There have been some well chronicled examples of elections with extremely close results, where the winner’s margin of victory was perhaps smaller than the election system’s margin of error. The term “Hanging Chads,” from the 2000 U.S Presidential election, is now part of the American vocabulary, and locally here in Washington State our last gubernatorial election in 2004 required 3 recounts with the final winner being determined by a margin of only 129 votes, or 0.0045% of the popular vote.

The populace demands confidence that, even in close elections, the election result accurately reflects the voters’ intent. In theory, such precision can be improved by using computers and technology.

However, it seems that every recent election season brings stories in the media about security concerns regarding voting machine (and their software) security. A recent New York Times article provides a good overview of voting machine security concerns; and academic studies on voting systems last year in California, Connecticut, Florida, and Ohio  provide some interesting insights about security concerns and vulnerabilities in voting systems from several vendors.

These analyses are fascinating to us, because they offer an opportunity to see how a set of experts look at products other than ours.  Applied security researchers often analyze our products, and often share their processes and tools with us, but it’s rare to see a top-to-bottom product review released.  In California, there was both white and black box testing done by different teams, and we’ve studied these reports to see the perceptions of development practices from other vendors and results of a different type of review process.

Something my colleagues and I find very interesting is that many of the vulnerabilities noted in these reports could have been prevented by following the requirements in Microsoft’s Security Development Lifecycle. The studies performed in California (prepared at UC Berkeley but created by teams of academics from across the United States) included detailed source code analysis. I’ll select out a few examples from those studies and describe them here. (Note: I’m deliberately picking a few examples from each vendor assessed in the study. I am not attempting to criticize any specific vendor, but rather am trying to illustrate examples of areas where application of the SDL could help contribute towards society’s need for trustworthy computing in a very visible and important application.)

Let’s start with the Source Code Review of the Sequoia Voting System. Two examples from the executive summary are interesting:

“Cryptography. …Many cryptographic functions are implemented incorrectly, based on weak algorithms with known flaws, or used in an ineffective or insecure manner. Of particular concern is the fact that virtually all cryptographic key material is permanently hardcoded in the system (and is apparently identical in all Sequoia hardware shipped to different jurisdictions)…

Software Engineering. …The software suffers from numerous programming errors, many of which have a high potential to introduce or exacerbate security weaknesses. These include buffer overflows, format string vulnerabilities, and type mismatch errors….”

A deeper reading of the cryptographic concerns (page 29 in report) notes concerns (amongst others) over the use of a flawed implementation of the SHA hash algorithm and use of the Data Encryption Standard (DES) algorithm. The SDL has specific policies outlining appropriate selection of cryptographic algorithms.  For example, DES is prohibited except for backwards compatibility. SDL also requires that applications use operating system cryptographic functions and libraries. The cryptography team in the operating systems group is supported by world-class cryptographers who carefully scrutinize the implementation of crypto algorithms, and additionally these operating system functions are formally reviewed and certified by the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) who validates cryptographic modules meet Federal Information Processing Standards (FIPS). Most application developers are not cryptographers and hence are unlikely to encode crypto algorithms correctly. The SDL requires the use of standard crypto functions and outlines requirements on algorithm selection, key length and key management.

Moving to the software engineering concerns; while several common coding and design concerns are noted (e.g. input validation) I want to select one with a bit more subtlety: running code from USB sticks (page 37 in report). From the report, it appears the code present on the USB sticks is used to program a component (HAAT) of their client (WinEDS) to prepare for a specific election.  The valid concern noted by the study is that USB sticks used by WinEDS to configure the HAAT are implicitly trusted to have appropriate authorization to program the voting devices for an election, and that a formal authorization framework didn’t appear to be present. The implication being (as stated in the report): “If such a stick is used in a HAAT that has been compromised by an attacker, or an attacker can provide a maliciously modified USB stick in place of a legitimate one, the attacker could surreptitiously take complete control over the WinEDS client”. Basically, this is a potential “rootkit” for election systems. A threat model, a fundamental design requirement of the SDL, could help uncover such design issues and illustrate the need for mitigations.

Now, let’s turn to the Source Code Review of the Hart InterCivic Voting System. I’ll try to keep my commentary balanced by selecting two examples here as well:

From the executive summary:

“Unsecured network interfaces … Voters can connect to unsecured network links in a polling place to subvert eSlates, as well as to eavesdrop on cast votes and to inject new votes. Poll workers can connect to JBCs or eScans over the management interfaces and perform back-office functions such as modifying the device software. The impact of this is that a malicious voter could potentially take over one or more eSlates in a precinct and a malicious poll worker could potentially take over all the devices in a precinct. …

Failure to protect ballot secrecy Hart’s system fails to adequately protect ballot secrecy...”

The concerns about unsecured network interfaces are discussed in the context of authentication and least privilege (pages 24-25). While that is certainly a reasonable perspective, with the SDL we take a broader view and require all teams to threat model the attack surface of the software being developed. Attack surface is the enumeration of all possible entry points that an attacker could use to compromise software (code listening to network interfaces, code that accepts data from external sources, etc). The SDL requires development teams to both minimize attack surface in the software they are building and to consider attacks from each entry point on the attack surface to ensure that mitigations are present. It would appear that these examples show that the development teams didn’t adopt such a systematic approach, or failed to think about mitigations of each possible attack if they did.

Ballot secrecy is an example where security and privacy concerns intersect. Many people confuse security and privacy, and both are fundamental to trust. Privacy addresses a wide variety of concerns about many types of data (such as Personally Identifiable Data (PII), ballot data, etc.), how it’s handled (gathered, transmitted, stored, and disposed of) and what rights and expectations different stakeholders may have regarding that data. (Tina Knutson gave a great overview on these issues in a previous blog posting “Privacy is not just about data security“). Security provides the mechanisms, policies, and practices to enforce privacy requirements. Given the intertwined nature of these issues, both are addressed in the SDL.

The concerns about vote storage (section 6.8, page 58 of report) review some classic challenges in software security and privacy with weak random number generation. Randomization is important here since it controls how votes are stored in memory, and weak randomization enables someone to reverse engineer how individual voters voted by examining the aggregate tally of votes (which can be found on the Mobile Ballot Boxes “MBB”) in conjunction with the audit log. The MBB has mitigations in place to protect integrity (tampering) of votes, but doesn’t appear to protect against information disclosure. The SDL cryptographic policies also cover correct random number generation. The challenge of fully considering all ways in which data can be reverse engineered, contextualized (order of log entries providing information that can be linked to individuals’ choices), and correlated with other data sources is a growing challenge. In the SDL privacy policies, we call attention to these issues, but it’s still a challenge.

Next, let’s look at the Source Code Review of the Diebold Voting System. Again, I’ll pick two subjects.

“Vulnerability to malicious software: The Diebold software contains vulnerabilities that could allow an attacker to install malicious software on voting machines or on the election management system…

Vulnerability to malicious insiders: The Diebold system lacks adequate controls to ensure that county workers with access to the GEMS central election management system do not exceed their authority….”

Let’s look at the “Malicious Software” first: While there’s a lot of discussion of general concerns with viruses and malicious payloads, I’d like to drill down on a specific case noted in section 4.2.3 (page 29). The typical concerns around string handling in C/C++ and buffer overflows are mentioned. What is interesting is that in many places this system uses the Microsoft Foundation Classes (MFC) CString class to help mitigate such concerns. The problem noted is that this practice is not consistently followed, and in fact there is a case of one specific function making calls to both CString *and* a standard C string library, in the same function. So here it appears the engineering team had the right idea by trying to remove calls to potentially risky C string library functions (just as required in SDL), but they just weren’t able to consistently and completely apply it.

Regarding the executive summary concern about malicious insiders, I’m inclined to attribute it to what’s described in section 4.3 on page 30: “No formal threat model or security plan” and “No formal security training”. Both of these are pivotal elements in the SDL. Several comments are offered to the effect that “security measures that are in place appeared to be ad hoc”, and “When new developers arrive at the company, they do not receive any kind of security training”. We’ve blogged here in the past about the importance of both areas, so I won’t repeat that again. (See Adam’s Threat Modeling series and Dave’s “Security Education v. Security Training” posts respectively for more info).

Is the SDL enough to ensure trustworthy voting systems?

When I offered this blog post for the review of my colleagues, it generated some very interesting discussion. Some of my colleagues were worried that I would misrepresent the SDL as a panacea for creating perfectly trustworthy voting systems. Let me be clear: this is absolutely NOT the case. While the SDL could help mitigate repeating many of the problems identified in these studies, it’s worth noting that election systems have a number of unusual and unique requirements. For example, voters cannot review their voting records as they would their banking records to ensure that no fraud has been committed – since the ability to do so would typically enable vote-selling and coercion.  Alternate techniques are therefore required to allow voters to verify that their votes have been properly counted. Such requirements force the adoption of “extraordinary” techniques that go beyond those of secure software engineering.  Furthermore, the expectations of society on the trustworthiness of voting systems are much greater as compared to other types of software (for example: the latest XBOX game title). I’ll further explore differences in how different people think about “degrees of trustworthiness” (aka “assurance” or “robustness”) in a future posting.

Summary

Let me wrap by saying this, building secure software is difficult. Prior to the advent of Trustworthy Computing and the Security Development Lifecycle here at Microsoft, I’d bet that many of the issues noted in these reports would have applied to earlier Microsoft products too. Some might think I’m throwing stones while living in a glass house, but that is not my intent. While Microsoft products are not vulnerability free, we continue to systematically analyze the sources of vulnerabilities in our software. We continue to modify our engineering practices and tools to better identify potential vulnerabilities and mitigate them before software is released. With increasing awareness and concerns over the trustworthiness of computers in general, the entire industry needs to improve. Given the importance of how we choose to organize ourselves as a society and elect representatives to govern us, voting systems are a great place to step up both in the context of the computing industry, and to better serve society.

I believe many of the issues found in these voting systems would not have entered the system if the SDL was used to design and build the voting systems.