IT Is Not A Utility
It is fundamentally disingenuous to imagine the IT industry as a nascent utility waiting to fade into the background, as Bruce Schneier suggests in this article. Consider:
My power company provides 120 Volt electricty at 60 Hz.
My water company provides me a finite amount of water at a certain pressure.
My phone company provides me bidirectional speech transmission, as well as a very simple mechanism for providing routing data for that speech (touch tone).
These are commoditized, well-defined and tightly scoped resources.
My power company does not own, operate, manage, take responsibility for, or even know of what their 120 Volts at 60 Hz is powering.
My water company doesn’t even warm the water it gives me.
My phone company does not screen my calls.
Data is not Information. Utilities provide a tightly constrained service, providing a resource that’s mostly unchanging and specifically not wildly different from customer to customer. Local pieces tend to be managed by third parties — electricians, plumbers, even users. If something goes wrong with my sink, I don’t call my water company.
If my desktop doesn’t start, I do call an IT department.
Utilities and IT departments just fundamentally provide different services. IT provides a Turing Complete environment all the way to the user. Water companies provide water to the user’s building. The latter is still an accomplishment — moving parts, rusting pipes, etc — but it’s a rather more constrained field. One of my old friends (and new coworkers! w00t!), Jason Larsen, spent years dealing with the utilities. He has an interesting observation about IT:
IT used to be about making people more productive — custom apps, custom tools, etc. Now, too often it’s about making sure people don’t get way less productive — block this, ban that, control, control, control.
Anything, and I mean anything, to keep the E-Mail running.
If there’s anything, in all of IT, that’s going down the utility path, it’s E-Mail. This is because, in no uncertain terms, every minute mail is down is a minute the company is down. Providers are driven by complaints, and the only thing that spawns complaints similar to power or telephone going down is email. But unlike power and telephone, keeping email up in all circumstances inevitably requires restricting everything else that might deign to get in the way.
Bruce thinks IT-as-utility is some sort of utopian future. Jason and I have seen the reality of this situation: There’s the computer that lives on corpnet. It provides email. It’s very reliable. Then there’s the other computer, possibly living on EVDO. It’s where work is actually done. It’s reliable enough.
It has never been joined to the domain.
Herein lies a basic problem in IT, which power companies simply do not need to concern themselves with: Nobody makes money sticking their tongue into a light socket; people do make money running complex parsers against untrusted input. It’s as if power companies needed to maintain their safety records with millions of suicidal users. So, ultimately, Bruce is partially right. We need to invest, as much as is feasible, in security early in the development cycle. It’s just too late, it’s just too inefficient, after the code goes gold. But the reality of complex parsers is that there will be some failure rate, and it will be noticeably higher than that which a utility can ever tolerate. The only route, then, for an IT department to see itself as a utility is for code to not get written and not to get deployed in the first place.
Nonexistent code is indeed bug free, but I don’t think any geek can call a codeless world utopic.
Bruce thinks the IT security industry is an accident. I think it’s an inevitable consequence of there being money on the table, just sitting there, and people seeking to write code to collect that money. We can block that code from being written. Or we can figure out how to do it right. Doing it right requires awareness of SQL injection, of buffer overflows, and of network attack surface. Doing it right requires threat modeling. And yes, doing it right may require bringing people not personally invested in the code, to see what could possibly go wrong. These are not things that fade into the background; these are things that you do early when it’s hopefully cheap rather than later when you’ve taken a critical dependancy on them being broken. Security requires is a completely different set of things to be aware of, above and beyond the the domain specific knowledge of how to take the money off the table and put it into your pocket. IT Security happened because of the yawning gap between making things work, and making things not fail. We can’t trivialize this gap. We can only manage it.