redundancy and unexpected interdependency

A couple weeks ago, the office network went down. Not surprisingly, we couldn't print or get to any electronically filed documents. Maybe a bit more surprisingly, the phones also went out because we've moved to fancy new Cisco network-based phones, and they took voice mail--which is now e-mail-based--with them. And so did the fax machines, because when faxes come in they get scanned and e-mailed to us. The net result was that we were almost dead in the water. Fortunately, the Blackberries stayed up, so we could use cell phones and could still send e-mail through the Blackberry server.

These sorts of unexpected interdependencies are cropping up more and more often as we begin to link one network to another, and as traditional network technologies shift around. I've already written about how my (now former) cell phone's alarm clock stopped working when the phone couldn't reach the cell network. There was a radio discussion today about an issue with digital TV: many people put battery-powered analog TV sets in survival kits so they can get news if there's a natural disaster, but (1) the set-top converter boxes that we'll need to use once HDTV becomes standard require wall power to run, which would make those analog battery powered TVs useless, and (2) many radio stations no longer have a news department, acting more as satellite feeds for a central office, so your transistor radio may not be able to pull in anything useful, either. Oh yeah, and many folks are moving away from conventional land-lines at home and going to VOIP phones or cell phones exclusively.

The classic way to deal with system failure is through redundancy: if the TV network goes out, you still have radio, which can get you much of what you need, or maybe you still have telephone. And so forth. The problem is that redundancy only works where you can stop a failure in one system from propagating to other systems. That's one reason most software doesn't have a redundant design: it's very hard to predict how far the effects of a failure will propagate through software, so it's generally not cost-effective to make it redundant. As our networking capabilities become more sophisticated, we're getting to the point where it's becoming harder to figure out what effect a failure of one network will have on the other networked systems we use.

The right way to do this, from an engineering perspective, is to take these sorts of problems into account when designing the systems, and then to periodically test them to make sure we got it right. That's not going to happen, at least right now, for social and economic reasons. The second-best approach would be to invest time and money into developing the design and evaluation tools necessary to either constrain the effects of a failure, so they don't propagate to other systems, or to at least be able to predict the likely failure modes and how far they'll propagate. We might eventually do that, but it'll take time. What's most likely to happen is the same thing that happened in structural engineering a hundred years ago: we may well see a series of unexpected, unforecasted failures, and they'll likely continue until we implement one of the first two approaches above.

unsafe at any (clock) speed?

Bruce Schneier has posted an essay which he wrote for Wired in which he faults the IT industry for insecure products:

If the IT products we purchased were secure out of the box, we wouldn't have to spend billions every year making them secure.

Aftermarket security is actually a very inefficient way to spend our security dollars; it may compensate for insecure IT products, but doesn't help improve their security. Additionally, as long as IT security is a separate industry, there will be companies making money based on insecurity -- companies who will lose money if the internet becomes more secure.

Fold security into the underlying products, and the companies marketing those products will have an incentive to invest in security upfront, to avoid having to spend more cash obviating the problems later.

One of the comment writers points out the parallel to the automotive industry: several years ago, cars were unsafe because manufacturers didn't have an incentive to make them safe. Then came some government regulation and popular attention (including Ralph Nader's book, Unsafe at Any Speed) and one sea change later the manufacturers are now competing with each other on safety features.

The same seems likely to happen in the IT industry. Either the industry will fix the problem itself, or there's going to be a big enough security breach that there'll be government regulation and a lot of popular attention.

Could the industry fix the problem? Completely fixing it seems out of reach: a 100% provably secure computer would be somewhere up there in price with a 100% provably safe automobile. Improving the security seems doable, though.

It'd probably take a paradigm shift in the way we write software and build networks. Back in the old days, people wrote software as unstructured code (sometimes derisively called "spaghetti code" because if you tried to trace how the code worked, you wound up with paths that looked like a plate full of spaghetti.) Unstructured code is too complex for a programmer to grasp--it has too many interacting parts--so programmers would hit a "wall," a point where the program got too large and they couldn't keep it working. It might be at 30,000 lines or, in my case, a much smaller 5,000 lines, but everyone eventually hit it.

Software engineering solved that problem by developing structured programming, a way of programming that breaks the program into fairly neat bits. It's kind of like the difference between writing this blog post as one long run-on sentence, and writing it in individual paragraphs made of separate sentences: breaking it into coherent paragraphs and sentences makes it easier to understand because you don't have to try to absorb the whole thing at once.

But structured programming brought with it some major changes. People had to write new programming languages, and they had to think about programs in a whole new way in order to use this new technique. Also, programs got a bit bigger and a bit slower, because structured programming eliminates some of the shortcuts you can take with the unstructured stuff.

I think we need that same kind of shift in IT security. We need to go from unstructured security to structured security. There must be a new way, a set of patterns, to think about designing programs, operating systems, networks, and networking protocols that makes them inherently more secure. I don't know what it is, but it will probably require new programming languages, or at least libraries, new operating systems, and new patterns of building networks.

Hopefully, someone's working on it right now. And hopefully they'll finish it soon. Otherwise, there's likely to be some political scrutiny and a book on the way that'll lead to a sea change in the IT industry.

too much reliability?

I've started tuning into David Brin's blog. I've come across his views from time to time. Sometimes I agree with them, often I don't, but they almost always get me thinking. Case in point, in this entry he discusses the failure of the cell network in New Orleans and advocates an emergency packet relay mode built into cell phones:

How about a simple back-up mode for text messaging? One that could use packet-switching to bypass the cell towers when they are down, and pass messages from phone to phone -- or peer-to-peer -- at least among phones that are of the same type?

It got me thinking. Maybe the problem with the cell networks, and the power grid for that matter, is not that they're not reliable enough. Maybe the problem is that they're too reliable. You see, one of the big problems with a back-up system is that, after you get it in place, you still have to test it to make sure it'll work. You might be religious about backing up the files on your computer, for instance, but how many times have you tried to restore them?

It reminds me of the pattern with preventing forest fires. For years, fire suppression was the goal. That caused dead wood to accumulate. Now, when fires do break out, they're a lot nastier because there's all this dead wood. If we'd had small fires more often, the dead wood never would have had the chance to accumulate.

It also reminds me of Y2K planning. Someone was surveying Y2K preparations in a developing country. They asked where person X got his food. Answer: I go next door and slaughter a goat. Question: what would you do if the power went out and your refrigerator stopped working. Answer: I wouldn't slaughter the goat. In areas where service is less reliable, people not only create their own back-up systems, but they also know how to use them because the unreliable service forces them to "test" the back-ups fairly often.

Obviously, even if decreasing reliability makes the system more rugged, there's going to be a trade-off. Electricity and communication are Good Things. They make the economy work. Make them too unreliable and the economy starts to deteriorate. Perhaps there's a nice mathematical model that could estimate how much reliability is optimal. But in any case, I wonder if designing for "five 9's" reliability (99.999% reliable, or five minutes of outage per year) might actually be counterproductive in the long run.