|
I just finished reading Richard Clarke and Robert Knake’s book Cyberwar. Though the book has flaws, some of them serious, the authors make some important points. They deserve to be taken seriously.
I should note that I disagree with some of my friends about whether or not “cyberwar” is a real concept. Earlier, I speculated that perhaps it might be a useful way to conduct disinformation operations, but it need not be so limited. Truthfully, we do not know for sure what can be done by cyber means. Some tests indicate that the power grid might be vulnerable. Clarke and Knake speak of disruptions to military command and control networks, damage to electrical generators, and destruction of the financial system. But we’ve never had a cyberwar, so we don’t really know.
I found the policy discussions stronger than the technical ones. Those latter had a number of errors, some amusing (the U.S. power grid runs at 60 hertz, not 60 megahertz; MCI became part of Verizon, not AT&T), others considerably more serious for the points the authors make (the Tier 1 ISPs talk to each other via many different private peering interconnections, rather than at “telecom hotels”—the latter was once true but hasn’t been for a fair number of years; consequently, there are very many link points that need protecting). Of course, I’m less qualified to assess the correctness of policy discussions; however, given that that is the authors’ background, I will give them the benefit of the doubt.
I suspect that the doomsday scenarios painted are overblown. Yes, there are risks. However, as a Rand Corporation study on cyberwarfare and cyberdeterrence pointed out, there is a great deal of uncertainty inherent in offensive cyberoperations. If everything goes just right for the attackers, the results might be as portrayed, but the cyberfog of war is even more opaque than the ordinary fog of war. The authors acknowledge the uncertainty in passing, but don’t draw the obvious conclusions.
A more serious failure in that vein occurs near the end of the book, where they quote Ed Amoroso of AT&T as saying that software is the real problem. Ed is precisely correct (and they also speak highly of him), which makes me wonder why they suggest that the Internet has to be reinvented to achieve proper security. Similarly, they advocate “Govnet”, a separated network for running the Federal government, perhaps even one that uses different operating systems and network protocols than the Internet. It can’t work. Apart from the many practical difficulties of building, deploying, and maintaining a new OS and application suite from scratch, and of keeping up with changes in hardware, the government needs many interconnections to the private sector (as they themselves point out), just to get its routine work done.
The most serious problem with the book is their “Defensive Triad” for solving the technical problem. It’s threefold: have Tier 1 ISPs scan their backbones for malware; separate the power grid (and perhaps other critical infrastructure) from the public Internet; and secure DoD’s networks. It’s hard to argue with the last one, save for the fact that it’s not clear how to do it enough better than has been done in the past. The other two are much harder to accomplish.
It isn’t clear to me that it’s even possible to do deep packet inspection (DPI) at the scale required. I don’t think Clarke and Knake appreciate just how fast the backbones run (some links run at 40G bps; even peering links are frequently 10G bps), nor how many interconnections need to be scanned. Besides, DPI can’t detect 0-day attacks (a problem the authors note elsewhere but not here), nor can it see through encryption. (Ausingly enough, the prospect of “three strikes” laws forcing disconnection from the Internet for file-sharing has the spooks worried that it may cause much more encryption to be used.)
It is also not obvious how to truly separate the power grid networks from public Internet. Yes, one can mandate disconnection. But if SIPRNET (Secret IP Router Network) and JWICS (Joint Worldwide Intelligence Communications System) can’t maintain their air gaps against “sneakernet” connections—and the authors assert that about the former and suggest it about the latter—how is a power company supposed to manage? Furthermore, some sort of sneakernet connection has to exist, or there will be no way to get system patches and new anti-virus signatures installed on the isolated machines. (The authors say that many machines on SIPRNET did not have their own layers of protection because they trusted the isolation. They very rightly decry this sort of sloppiness—but doing better requires some sort of connection.)
The discussion of a possible arms control treaty was quite nuanced and interesting. I started the book thinking that the idea was preposterous; I now think that something along the lines they suggest is probably feasible and desirable. Note that neither I nor the authors suggest that the negotiations would be easy or that full compliance would be common. I won’t try to summarize the discussion; you’ll have to read it for yourself.
Clarke and Knake make a loud call for open discussion of U.S. cyberwar policy, much as was done for nuclear policy. They even made the obvious (to me) allusion to Dr. Strangelove. Their point is depressingly obvious; I really don’t understand why the Powers That Be in Washington don’t see it that way.
The authors put too much stress on identification and authentication. I’ve said enough about that lately (blog, CircleID); I won’t rehash the arguments now.
So: given all of my complaints about the technical details, and given some lingering concern about the accuracy of the policy sections, why do I recommend the book? It’s simple: I do think there is potential danger, and this book is a clear recounting of how we got into this mess; it’s also a clarion call to fix it. Their specific prescriptions may not work, but if we don’t start we’ve never going to solve it. To quote the Mishnah, “it is not your part to finish the task, yet you are not free to desist from it.”
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byVerisign