Report: Safer and more secure cyberspace.

Thanks to the CRA blog for a pointer to a newly-available report from the National Research Council's (NRC) Computer Science and Telecommunications Board (CSTB) and Division on Engineering and Physical Sciences (DEPS), entitled Toward a Safer and More Secure Cyberspace. (Draft form free for online viewing, but you'll have to pay for a hardcopy.)

Given the growing importance of cyberspace to nearly all aspects of national life, a secure cyberspace is vitally important to the nation but cyberspace is far from secure today...

Society ultimately expects computer systems to be trustworthy—that is, that they do what is required and expected of them despite environmental disruption, human user and operator errors, and attacks by hostile parties, and that they not do other things... This report ... focuses on security and addresses other trustworthiness issues only to the extent that they relate to security...

The potential consequences of a lack of security in cyberspace fall into three broad categories. First is the threat of catastrophe—a cyber attack, especially in conjuction with a physical attack, could result in thousands of deaths and many billions of dollars of damage in a very short time. Second is frictional drag on important economic and security-related processes... Third, concerns about insecurity may inhibit the use of IT in the future and thus lead to a self-denial of the benefits that IT brings...

THE CYBERSECURITY BILL OF RIGHTS

I. Availability of system and network resources to legitimate users.
II. Easy and convenient recovery from successful attacks.
III. Control over and knowledge of one's own computing environment.
IV. Confidentiality of stored information and information exchange.
V. Authentication and provenance.
VI. The technological capability to exercise fine-grained control over the flow of information in and through systems.
VII. Security in using computing directly or indirectly in important applications, including financial, health care, and electoral transactions and real-time remote control of devices that interact with physical processes.
VIII. The ability to access any source of information (e.g., e-mail, Web page, file) safely.
IX. Awareness of what security is actually being delivered by a system or component.
X. Justice for security problems caused by another party...

A different way of thinking about cybersecurity will be necessary regarding the ways in which secure systems are designed, developed, procured, operated, and used. In the long run, this different way of thinking will entail new directions in education, training, development practice, operational practice, oversight, liability laws, government regulation, and so on...

The nation is a long way from meeting this goal. The first reason is that much about cybersecurity technologies is known but not put into practice...

The second reason is that even assuming that all that is known today were to be immediately put into practice, the resulting cybersecurity posture ... would still be inadequate against today's threat, let alone tomorrow's. Closing this gap—a gap of knowledge—will require both traditional and unorthodox approaches to research...

Cybersecurity will be a continuing issue: threats evolve (both on their own and as defenses against them are discovered), and new vulnerabilities often emerge as innovation changes underlying system architectures, implementation, or basic assumptions...

IMPORTANT CATEGORIES OF RESEARCH FOCUS

1. Blocking and limiting the impact of compromise...

2. Enabling accountability...

3. Promoting deployment...

4. Deterring would-be attackers...

5. Crosscutting problem-focused research...

6. Speculative research...

WHY HAS CYBERSECURITY ACTION TAKEN TO DATE BEEN INSUFFICIENT?

The cybersecurity threat is ominous. Moreover, as one of the most IT-dependent nations in the world, the United States has much to lose from the materialization of this threat. But this committee is not the first committee—and this report is not the first report—to make this claim. After more than 15 years of reports pointing to an ominous threat, and in fact 15+ years in which the threat has objectively grown, why is there not a national sense of urgency about cybersecurity? Why has action not been taken to close the gap between the nation's cybersecurity posture and the cyberthreat?

The lack of adequate action in the cybersecurity space can be largely explained by three factors:

• Past reports have not provided the sufficiently compelling information needed to make the case for dramatic and urgent action...
• Even with the relevant information in hand, decision makers discount future possibilites so much that they do not see the need for present-day action. That being the case, nothing short of a highly visible and perhaps ongoing cyber-disaster will motivate actions...
• The costs of inaction are not borne by the relevant decision makers...

These factors suggest the need for putting into place mechanisms that change the calculus used to make decisions about cybersecurity...

PRIORITIES FOR ACTION TODAY

• Create a sense of urgency about the cybersecurity problem...
• Support a robust and sustained research agenda at levels which ensure that a large fraction of good ideas for cybersecurity research can be explored...
• Establish a mechanisms for continuing follow-up on a research agenda...
• Support research infrastructure...
• Sustain and grow the human resource base...

Most of these points will strike security researchers as self-evident. But they are apparently not evident to the nation's decision makers. Hopefully, this well-written high-profile report by a distinguished committee (Sy Goodman, Joel Birnbaum, David Aucsmith, Steve Bellovin, Anjan Bose, Barbara Fraser, James Gosler, William Guttman, Ruby Lee, Fred Luiz, Teresa Lunt, Peter Neumann, Stefa Savage, Bill Scherlis, Fred Schneider, Alfred Spector, John Wankmueller, and Jay Warrior) will have some success in getting these messages to those outside the security community.

Support for security: Where's it missing? At the top.

A post by Dave Ladd on the Microsoft Security Development Lifecycle blog, discusses the difference between working on security and privacy initiatives and actually working on security and privacy. One key tidbit:

More often than not, when talking to our customers an interesting social phenomenon is presented – as I talk with technical employees (developers, project managers, testers and the like) the desire to implement secure development practices extends all the way up the technical food chain, including the CSO – then it stops…cold.

I haven't done any empirical study of this behavior, nor do I plan to – however, in the process of conducting my informal probes for causality, more often than not I find that it hinges on two points:

1. lack of understanding at the CxO level about how security, privacy and reliability are contributors to corporate risk, and;
2. discomfort with the notion of redirecting resources to trustworthiness in the short term, in exchange for longer term gains in product quality and customer satisfaction.

And an illustrative analogy:

A final note to help illustrate my point – for those of you that are old enough to remember, there was an old TV commercial for Fram Oil Filters that showed a mechanic working on the tear down of some old beater. At the end of the commercial, the mechanic turns to the camera and says, "You can pay me now, or you can pay me later..."

Report slams U.K. e-voting trials

Computerworld has a report by Jeremy Kirk on the problems with e-voting in the United Kingdom.

The U.K.'s trial of e-voting and e-counting technologies during last month's local elections resulted in crashed computers and technicians scratching their heads while posing new concerns about the systems' security and reliability, a new report has concluded.

In one area of England, a manual recount performed after e-counting equipment was abandoned because of delays turned up a raft of uncounted votes, said Jason Kitcat, e-voting coordinator for the Open Rights Group, which deployed observers to polling sites in England and Scotland.

The group, which has been critical of e-voting and e-counting, has submitted its 64-page report (format) to the U.K. Electoral Commission, which will publish its own report on the trials on Aug. 3...

E-counting scanners proved finicky due to incorrect paper sizes, scanner sensitivity and trouble in handling low-quality perforations on ballots. The most curious error in e-counting occurred in a ward in Breckland, England, where voters were given two ballots: one each for district council and parish elections. Officials tried an electronic count, but came up with far fewer district ballots than parish ballots when the two counts should be roughly the same, Kitcat said. A manual recount turned up about 56% more district council ballots.

"We haven't been given an explanation by the election official or suppliers," Kitcat said.

HOPL III and a tipping point

Last Saturday and Sunday I attended ACM's third History of Programming Languages conference (part of the Federated Computing Research Conference running this week). HOPLs only come along every 15 years or so (1977, 1993, 2007).

It was a wonderful conference. It was great to meet again so many old friends and to meet and learn from so many language designers I knew of, but didn't know, and hear how their languages came into being and what had influenced them. There were clear differences in assumptions, but members of all the different camps were respectful of each other. (Perhaps the most potentially fraught session was the one consisting of Niklaus Wirth speaking on "Modula-2 and Oberon" and Bjarne Stroustrup on "Evolving a language in and for the real world: C++ 1991-2006.")

Let me mention just one other somewhat unusual aspect of the conference: When I registered, I was given the usual conference tote bag, with room for a laptop and a few 10-lb proceedings volumes. Then I was handed the conference papers--in the form of a thumb drive. It contained all the papers for HOPL III, but also, since that consumed only 11MB on a 256MB drive, they threw in as a bonus the final proceedings (including transcripts of the actual presentations and of the question and answer sessions) for both HOPL and HOPL II. Unfortunately, the drive does not contain Fran Allen's Turing Award address (which followed HOPL III), but it was carefully videotaped and I expect ACM to make it available somehow soon; there were a couple thousand people in the audience. (The HOPL II proceedings and HOPL III papers are all available in the ACM Digital Library.)

It seems to me that we have now passed a tipping point in scientific publication; it will become routine to distribute, not just conference papers, but also the previous proceedings (perhaps even all the referenced papers), to conference attendees. And pretty soon they'll stop handing out those tote bags...

Illegitimis non carborundum.

It is easy to become discouraged when you have a truly original, truly great, idea―and just can't seem to get the world to recognize its importance. But if you truly believe in your idea, you should persist.

I encountered a well-documented case last weekend at the third History of Programming Languages conference (HOPL III). David Harel discussed the difficulties he had encountered in trying to publish a paper on statecharts:

The process leading to the eventual publication of this paper is interesting in its own right. For almost two years, from early 1984 until late 1985, I repeatedly submitted it to what seemed to be the most appropriate widely read venues for such a topic. These were, in order, Communications of the ACM, IEEE Computer and IEEE Software. The paper was rejected from all three of these journals. In fact, from IEEE Computer it was rejected twice ― once when submitted to a special issue on visual languages and once when submitted as a regular paper. My files contain quite an interesting collection of referee reports and editors' rejection letters. Here are some of the comments therein:

"I find the concept of statecharts to be quite interesting, but unfortunately only to a small segment of our readership. I find the information presented to be somewhat innovative, but not wholly new. I feel that the use of the digital watch example to be useful, but somewhat simple in light of what our readership would be looking for."

"The basic problem […] is that […] the paper does not make a specific contribution in any area."

"A research contribution must contain 'new, novel, basic results'. A reviewer must certify its 'originality, significance, and accuracy'. It must contain 'all technical information required to convince other researchers in the area that the results are valid, verifiable and reproducible'. I believe that you have not satisfied these requirements."

"I think your contribution is similar to earlier contributions."

"The paper is excellent in technical content; however, it is too long and the topic is good only for a very narrow audience."

"I doubt if anyone is going to print something this long."

Indeed, the paper was quite long; it contained almost 50 figures. The main running example was my Citizen Quartz Multi-Alarm digital wristwatch, which was claimed in the rejection material by some to be too simple an example for illustrating the concepts and by others to be far too detailed for a scientific article… Some claimed that since the paper was about the much studied finite-state machine formalism it could not contain anything new or interesting…

One must understand that in the mid-1980s there was only scant support for visual languages. Visual programming in the classical sense had not really succeeded; it was very hard to find ways to visualize nontrivial algorithmic systems (as opposed to visualizing the dynamic running of certain algorithms on a particular data structure), and the only visual languages that seemed to be successful in system design were those intended to specify structure rather than behavior. Flowcharts, of course, were a failure in that most people used them to help explain the real thing, which was the computer program. There was precious little real use of flowcharts as a language that people programmed in and then actually executed. In terms of languages for structure, there were structure diagrams and structure charts, hierarchical tree-like diagrams, and so on. The issue of a visual language with precise semantics for specifying behavior was not adequately addressed at all. Petri nets were an exception, but except for some telecommunication applications they did not seem to have caught on widely in the real world. My feeling was that this had mainly to do with the lack of adequate support in Petri nets for hierarchical specification of behavior...

[T]he inability to get it published was extremely frustrating. Interestingly, during the two years of repeated rejections, new printings of the 1984 technical report had to be prepared, to address the multitude of requests for reprints. This was before the era of the internet and before papers were sent around electronically. So here was a paper that no one wanted to publish but that so many seemed to want to read... I revised the paper twice during that period, and the title changed again, to the final "Statecharts: A Visual Formalism for Complex Systems". Eventually, two and half years later, in July 1987, the paper was published in the theoretical journal Science of Computer Programming. That happened as a result of Amir Pnueli, who was one of its editors, seeing the difficulties I was having and soliciting the paper for the journal.* [pp. 9-10]

* By the way, this story of the repeated rejections of the paper would not be as interesting were it not for the fact that in the 20 years or so since its publication it has become quite popular. According to Citeseer, it has been for several years among the top handful of most widely quoted papers in computer science, measured by accumulated citations since publication (in late 2002 it was in the second place on the list).

I still remember the talk on statecharts (and the digital watch) that David gave at DEC/SRC, circa 1984-5. And I remember the number of people I urged to have a look at the method, but did not have the eloquence to convince.