The Washington Post has reported that the U.S. Congress will shortly take up a bill to “empower the government to set and enforce security standards for private industry for the first time.”

Today’s conventional wisdom in cybersecurity circles is that:

• we’re very much open to attack (defined lots of ways; often people mean: PCs attached to the Internet can be compromised by outsiders and then put to bad uses, turned into spies, or made to self-destruct).  Virtually no one takes cybersecurity as seriously as he or she should, in part because the costs of compromise are not always charged back to the person who should take measures.  (Many people don’t care if their PCs are sending spam in the background, so long as it doesn’t disrupt their Doom game.)
• “perimeter defense,” the basic idea behind firewalls, doesn’t cut it.  If just one bad bit of code gets past the wall dividing a PC or a network from the rest of the world, it’s all over.  (This makes Senator Rockefeller’s soundbite a bit inapt: “You have to keep making higher walls.”)
• for the first time, our defense establishment is genuinely not in a position to be able to “defend the homeland.”  That’s because much of the vulnerable infrastructure — PCs — is entirely in private hands and then connected to the world at large.  There’s no place for a fighter jet or Border Patrol agent to intercede.

Given these articles of faith, one can see how tempting it is — indeed, nicely bold — to propose a government official who can mandate certain security standards across the board.  But there are many potential problems with this approach.

First — could they realistically be made to apply to individuals?  What penalty should obtain if I fail to secure my computer?  Perhaps the thought is that operating system and software vendors could be regulated, the way that cars must have seat belts and air bags — precisely to deal with the problem of irresponsible individual drivers.  But that’s dicey: there are many clearly wrong ways to code operating systems, but that doesn’t mean there are obvious right ways to do it.  Many of the vulnerabilities we face come not from hidden exploits that take advantage of some literal bug in the way, say, Windows works, but from our own acquiscence in running new code.  We click “yes” to “are you sure you want to run this?” because we are impatient, and because so many times during the day we’re typically asked to make a snap decision like that.

Second — any standards process would quickly become the purview of security firms with something to sell.  Tens of millions of dollars or more could rise or fall on whether one’s security suite is made the obvious way to satisfy a particular regulatory requirement.  With no scale to determine how much security is enough — especially when risk aversion will vary so much from one firm or computer owner to the next — we run the risk of overregulation.  Too easily security standards will just amount to vendor selection.

So, what should we do?

Well, one fruitful point of dampening security problems is at the ISP level.  Computers that have fallen prey to an active worm or virus can frequently behave in predictable ways — sending out certain traffic patterns, or having vulnerabilities that can be detected at a distance.  ISPs know this, but are reluctant to tell their own subscriber that they have a problem, much less to quarantine them.  To do so means a customer service event — someone has to coach the user through fixing the machine.  But that incentive can be changed.  If ISPs were asked — well, required — to take more reasonable responsibility for zombie computers located on their networks, they could rise to the occasion.

Another underexplored strategy is to build our systems so that they can recover gracefully from problems.  Wikipedia isn’t designed to prevent all vandalism; instead it has technical tools that make it easy to revert a page to the state it was in before someone came along and vandalized it.  If the Wikipedia entry for Britney Spears is resilient to defacement, shouldn’t our valuable spreadsheets be the same way?  Imagine a history file automatically generated so we could see changes as they have happened and revert to an older version.  Then we need only deal with the problem of viruses that try to tamper with a document’s history — something that can be made very difficult to do.  Similarly, researchers like Butler Lampson have proposed PCs with “red” and “green” zones in them.  Stuff in the red zone can’t affect what’s going on in the green.  Trusted software ready for prime time goes in the green zone; experimental or new stuff goe sin the red.  If there’s a problem in the red zone, it’s at least confined.  None of these approaches is a cure-all, but they can help a lot.

Finally, we can work to build collective solutions, neighborhood watches in cyberspace.  Right now each PC has a metaphorically autistic experience: it surfs from one site to the next with no awareness of what other PCs are doing.  Imagine having a little software on your PC that reports its vital signs to other participating PCs.  Collectively we could generate a map of the health of cyberspace, an early warning system — and a means of answering some very useful questions.  Before running new code, you could say: How many machines in the herd are running it?  How many self-proclaimed experts run it, versus neophytes like me?  Is the code brand new, or has it been around for months or years?  These questions are not beyond the expertise of most PC users, and the answers can help them make much more informed decisions about what code to run.

There’s a lot of work to be done to secure cyberspace — work that goes beyond any one set of regulatory “best practices” that we know won’t be uniformly implemented.