Posted by: David Schneier
when relevant content is
added and updated.
when relevant content is
added and updated.
The recent release of the “Securing Cyberspace for the 44th President” report spawned a flood of analysis and criticism, and much of it was positive and complimentary. I’ve written before about the idea behind this report and the fact that many, if not most, of the recommendations in it can also be found in the National Strategy to Secure Cyber Space, which was released nearly six years ago. That document has been largely ignored and we have all been paying the price in the interim. The federal government’s virtual abandonment of cybersecurity policy in the last eight years has left all of us more vulnerable, and will end up costing the government, and taxpayers, far more money in the long term.
In reading the various analyses of the report, I found that many people were commending the commission for suggestions that either have failed in the past, or have little chance of working now. I ran across Steve Bellovin’s blog post on the report and it came as no surprise that his analysis was right on the money. Bellovin’s as smart as they come, and it’s worth the time to read through his entire post on the report, but in the meanwhile, here are a few key points:
The analysis of the threat environment is, in my opinion, superb; I don’t think I’ve seen it explicated better. Briefly, the U.S. is facing threats at all levels, from individual cybercriminals to actions perpetrated by nation-states. The report pulls no punches (p. 11):
America’s failure to protect cyberspace is one of the most urgent national security problems facing the new administration that will take office in January 2009. It is, like Ultra and Engima, a battle fought mainly in the shadows. It is a battle we are losing.
That’s it exactly. In fact, it’s a battle we’re not even fighting right now.
The most important technical point in this report, in my opinion, is its realization that one cannot achieve cybersecurity solely by protecting individual components: “There is no way to determine what happens when NIAP-reviewed products are all combined into a composite IT system” (p. 58). Quite right, and too little appreciated; security is a systems property. The report also notes that “security is, in fact, part of the entire design-and-build process”.
It should be, but that hasn’t been the case in many systems for far too long. Bellovin then skewers what has been the dominant federal strategy for remedying this problem:
The discussion of using Federal market powers to “remedy the lack of demand for secure protocols” is too terse, perhaps by intent. As I read that section (p. 58), it is calling for BGP and DNS security. These are indeed important, and were called out by name in the 2002 National Strategy to Secure Cyberspace. However, I fear that simply saying that the Federal government should only buy Internet services from ISPs that support these will do too little. DNSSEC to protect .gov and .mil does not require ISP involvement; in fact, the process is already underway within the government itself. Secured BGP is another matter; that can only be done by ISPs. However, another recent Federal cybersecurity initiative — the Trusted Internet Connection program — has ironically reduced the potential for impact by limiting the government to a very small number of links to ISPs. Furthermore, given how many vital government dealings are with the consumer and private sectors, and given that secured BGP doesn’t work very well without widespread adoption, U.S. cybersecurity really needs mass adoption. This is a clear case where regulation is necessary; furthermore, it must be done in conjunction with other governments.
Bellovin also criticizes the report for calling on the Obama administration to protect online privacy without providing any guidance as to what that means or how to do it. But he leaves the best for last: the omission of any mention of software security and its cascading effect on system and network security.
The buggy software issue is also the problem with the discussion of acquisitions and regulation (p. 55). There are certainly some things that regulations can mandate, such as default secure configurations. Given how long the technical security community has called for such things, it is shameful that vendors still haven’t listened. But what else should be done to ensure that “providers of IT products and systems are accountable and … certify that they have adhered to security and configuration guidelines?” Will we end up with more meaningless checklists demanding antivirus software on machines that shouldn’t need it? Of course, I can’t propose better wording. Quite simply, we don’t know what makes a system secure unless it’s been designed for security from the start. It is quite clear to me that today’s systems are not secure and cannot be made secure.