In a recent BankInfoSecurity article, U.S. Federal Chief Information Officer Tony Scott was quoted as saying one of the main factors behind the OPM breach was the tendency of Congress to “fund civilian agencies to maintain their information systems, not to modernize them.” This is endemic both in the public sector and in other organizations below the security poverty line, which I started writing about in 2011.
But before everyone gets out the smelling salts at the idea that organizations don’t update their systems, let’s examine the source of this reaction. In IT, we’ve come to accept the conventional wisdom that systems need to be updated all the time. And today they do: either because there are nifty new features that can be incorporated, because they need to be made compatible with another system that has new features, or because a bug or vulnerability needs to be fixed.
We’ve inflicted both complexity and an ever-increasing rate of change on ourselves, and we’ve accepted the security cost that comes with them.
This is completely different from everything else we as humans have ever created. Every item manufactured was built to last, and it certainly wasn’t expected to change, unless you got tired of the color and wanted to paint it. As things broke due to wear and tear, they were carefully repaired or refurbished, but the assumption was that you didn’t need another one as long as the first one performed its function and could be repaired. In order to maintain sales growth, auto manufacturers started introducing planned obsolescence into its models in the 1920s, but the public would not accept too high a failure rate in durability and safety.
In the early years of programming, those who wrote code took pride in creating robust and resilient code (as well as squeezing it into small amounts of memory and storage). You might argue that craftmanship included the idea of longevity, since it would have been embarrassing to discover flaws and have to rewrite the software. The Apollo moon missions didn’t plan for software updates until the missions were completed.
Organization budgets everywhere are based on the notion that you buy something once, and then only maintain it as needed; you only replace it when it clearly can’t function any longer. This is a completely reasonable notion when it comes to just about everything else in a business: facilities, furniture, office supplies, utilities, and every other kind of equipment—except the kind that is so expensive, complicated and fragile that you need to hire an army of specially educated humans to monitor and tend to it all the time. Can you imagine the budget discussions with non-IT people?
“Yes, we spent $5 million on desktops and servers last year, but we’re going to need about that much again every year.”
“You’re kidding! Why that much?”
“Well, there are going to be patches for mistakes that the vendors made the first time around, and they’re always going to find new mistakes. Then they’re going to be changing things, and we’ll have to buy more software to stay compatible with whatever they change.”
“What are they going to change?”
“We have no idea. Some kinds of new stuff. Someone will probably invent something like cloud, only different. Maybe they’ll add things to control our lightbulbs. Some kind of learning machine, I’ve heard. Or they’ll just decide to stop supporting what we just bought in a year or two.”
Nobody in their right mind with a finite budget is going to stop running what they have, as long as it’s running just fine. They’ll have to prove to their source of funding that it’s no longer functioning at an acceptable level before they’ll get permission to upgrade it. This is why civilian agencies overload their servers until they degrade to the point where citizens notice and complain. This is why IT-poor organizations shop for obsolete spare parts on eBay. And it’s why we still see Windows XP and NT (and mainframes). They’re performing their functions just fine. Longevity is a critical issue that we’ve all forgotten.
So let’s try a longevity challenge. How about designing software that does one or two things, does them very well, doesn’t care whether systems change around it, and is designed not to need updating?
Now you can reach for those smelling salts.