Internet Explorer, Monoculture and Tunnel Vision

I’ve been watching as a number of security expert’s call for the companies to replace Internet Explorer (IE) and the follow-up pieces that state, with the implication that the companies must be stupid, that they aren’t following that advice. I think this reflects more on how far removed many of these experts are from IT management than it does anything else, but, given the coverage, I figured it was time to write a security primer.

There are massive dependencies on this operating system component. It is integrated in the OS, in Microsoft Office, and Web pages have been both optimized for it and tested against it for years now. Hosted applications generally depend on it being there to work properly and it is a known element of most IT shops.

To remove it would be far from simple and, assuming you were in a well-run shop, to make the decision you would need to do a cost-benefit analysis. In a large IT shop this analysis alone would take several months and, given that the recommendations I’ve seen only suggest the abandonment of IE and don’t provide any guidance about what to move to, much of that work needs to be done as well.

Now you have to consider that, given the integration, the only way to really move off of IE is to move to another platform. So, then, why isn’t the recommendation to move to Linux or the Mac OS? Probably because that would seem too extreme, and folks wouldn’t take the pieces seriously. So, I believe that for many of the writers this was a subtle way to argue once again that Linux (or the Mac OS), their favored platforms, should be yours as well.

However, you need to remember that there is a massive infrastructure that surrounds IE, from development resources, to an in increasingly robust patch process, to a massive number of third parties that would need to be considered even if you really could remove IE without replacing the OS. This would clearly not be something to be taken lightly as the cost, both collectively and individually, could be astronomic. And were the migration found to be, after the fact, either unnecessary or to the wrong platform, the repercussions would be significant as well.

Monoculture vs. Diversity

I just finished reviewing three large cases; I’ll cover one at length in a future column. In each case they saved substantially (US$3 million to $10 million) by creating a higher level of consistency than had been the case before their projects had started. The more inconsistent you are the higher the support cost. While I was at Giga Information, we issued several reports that extensively looked at cost and concluded that for each additional platform and vendor you added you squared the support cost.

That might seem extreme, but if you look at the IT costs of a highly standardized IT organization that maintains solid control over its desktops, you will see costs running at a fraction of what other organizations experience. Charter One bank, one of the cases I reviewed — which, by the way, were IBM cases, not Microsoft cases — runs 6,000 desktops with a department of six (including the manager), on Windows XP, and they have time to do other projects.

With Security there are always advantages and disadvantages to any approach. Diversity can slow or stop a virus attack but it opens you up to other types of things. When you have a high level of consistency, you can automate more things, you tend to have more people who are expert on the systems being secured (although this has been a particular problem with Windows and showcases a downside to the ease-of-use advantage this platform has traditionally enjoyed), and you have less overhead (substantially less) managing user accounts (single sign-in, and permissioning is much simpler).

Traditional Security Breaches

While virus attacks get all the news play, remember that traditionally our security exposures have come from disgruntled employees (often ex-employees), vendors, clients, thieves and competitors. These are targeted attacks; folks that want something and often know how to find it.

For them, diversity is a godsend because diversity creates system gaps that they can use to gain access to sensitive information. Not only do you have to link all of the permissions components to each other, but you have to maintain competencies in each and every platform and understand what exposures result when you put them together into the configuration you are using.

Because each company tends to put multiple platform shops together differently (different versions, different distributions, different application loads and different topology) this last consideration can be particularly painful to maintain. This is one of the reasons that companies, since the days of the mainframe, moved to internal standards, because keeping one platform up to date and secure is vastly easier than multiple platforms.

So why are people arguing diversity? Because it promotes the agenda they have — generally, pro-Linux/anti-Microsoft — and because it addresses the kinds of exploits that get press. If a company experiences a unique security breach they are unlikely to report it due to the implications it might have on the company’s stock. However, a virus hits lots of folks and gets flagged broadly, resulting in the impression that viruses are vastly more common than more traditional forms of security breaches. That probably isn’t the case, but the perception is very powerful.

Security as a ‘Real Job’

One of the problems is that, much like the U.S. recently discovered with internal security, companies don’t take the responsibility seriously enough. To be serious, someone has to own the security for the firm, or the state, as a centralized function. They have to take into account the threats that face the organization, both virtual and physical, and articulate a comprehensive plan to mitigate, for a reasonable cost, those threats. Then they need to execute a program that is secure enough for the company and easy enough for the employees to use. And they have to destroy any notion of turf wars; everyone has to own the solution or it won’t work.

This requires focus, a centralization of control and authority, and the participation of every single employee and massive executive buy in. Part of the problem, as I see it, is the general belief that a vendor, any vendor, can address the security issue. That simply is not the case. An organization has a number of ways it can be compromised, and only the vigilance of everyone has any chance of coming close to meeting the entire list of security exposures the firm is likely to experience in the current world.

Security Is Your Job

I’m appalled at the belief, for instance, that the U.S. government can protect our nation against terrorists, and I recall a speech by John F. Kennedy in which he said, “Ask not what your country can do for you, but what you can do for your country.” From a security perspective, every citizen and every employee has to be directly involved.

Recall that this latest IE exploit was actually caught, the perpetrator arrested, and the server he was using taken offline before anyone was compromised. This shows the effectiveness of a system — a system that, by the way, may not exist for the other browsers or platforms. This systems approach to security is vastly more powerful than a product approach because it has layers, and the more layers you have, the more difficult it is to breach a company’s security.

I am getting incredibly tired of “security experts” who are more like sales reps, who use a Microsoft exploit as a justification to change platforms, particularly since the one they are recommending could actually be worse. I’m also getting tired of these experts suggesting you yank out a critical application by the roots without offering a well-researched alternative, or providing any thought into whether the cost of the move will be worth the benefits.

And I’m getting incredibly tired of Microsoft being blamed for every security exposure. Microsoft isn’t your mamma. You have to own your own security and, often as not, it’s the people that make the difference, not the product. Step up to the plate, understand the entire problem, and realize that replacing a product needs to be done as a last resort and only after making damn sure that it actually makes things better, not just different.