A good chunk of my life was spent doing security audits. In my experience, diverse environments are less secure. This is because diversity leads to bad practices and it was those practices that exposed the site. For instance, in one site, they used different door locks and therefore couldn't use a master key. The central administrator kept a ring of keys for all of the doors, and put the keys to the confidential office safe on the same ring. It was relatively simple to penetrate her desk to get this ring of keys and access virtually everything.

Because the key ring was so large it was easy to find and exploit. This is not to say the approach of having a single, master key was more secure, only that the fix actually didn't mitigate the problem at all, in fact it actually made the keys easier to find.

This is the big problem with the diversity recommendations I've seen. If they had been implemented as recommended they would have had little impact on the Swen MSBlast virus, which spread via common e-mail, and would likely increase the exposure for other types of threat. (Corrected Sunday, 10/12/2003.)

For example, if a virus targeted Microsoft Office and an enterprise deployed Apple systems running Office, for compatibility reasons, that enterprise would probably be damaged by the attacks. This would be true of any case where the same application is running across multiple platforms -- such as an enterprise running financial software on a mix of Windows, Linux and Macs -- if that code is exploited, the benefits of security would not be realized.

Interoperability between platforms helps create security exposures, but if we break interoperability, we increase the manual labor required to connect the data between the systems.

A few years ago IBM went into an account and made it as secure as they knew how, to showcase its security prowess. Then they hired an ex-spook to try to break in, with the hope he would find the task impossible. But he penetrated the site in under a day by attacking another company which had trusted links into the IBM-secured site. This example demonstrates the need for a security policy to be comprehensive; by focusing on one area IBM just caused their expert to look elsewhere. He never even tried to penetrate the primary site directly. The site was compromised despite the massive amount IBM spent to secure it.

One of the biggest problems caused by diversity is that it become very difficult for the IT staff to maintain equal competence on all platforms. The IT staff will have to focus more resources on keeping these systems interoperating and have fewer resources available to concentrate on things like securing the site. This would suggest that some of these platforms will be more secure than others and while a worm may be less successful, a security breech of another type may be more likely. Before taking this path, you want to do a full security assessment to insure you are not becoming more exposed while incurring greater costs.

Any security policy, particularly one that addresses a company's infrastructure, should only come after a thorough analysis of all of the likely threats and all of the reasonable solutions so that it is both comprehensive in nature and cost effective when deployed. No one wants to be caught either wasting corporate assets, or worse, increase the company's overall exposure to security threats.

Rob Enderle heads the Enderle Group and spends his time building PCs, exploring emerging personal technology, and helping clients avoid expensive mistakes. You can write him at renderle@enderlegroup.com.

Contact the editor at feedback@internetweek.com; if you send an e-mail, let us know if you'd rather we don't publish it.)

PREVIOUSLY BY ROB ENDERLE:
- Microsoft: Hated Because It's Misunderstood
- Reasons To Shun Open Source-ry
- Linux Is Not Ready For the Enterprise