Diversity of defense is closely related to depth of defense but takes matters a bit further; it's the idea that you need not only multiple layers of defense, but different kinds of defense. Having a door lock and an ignition lock on a car is depth of defense; adding an alarm system creates not only depth but also diversity, by adding a completely different kind of defense. Now, you are not only trying to keep people from being able to use the vehicle, you're also trying to attract attention to people who're attacking it.
Properly implemented, diversity of defense makes a significant difference to the security of a system. However, many attempts to create diversity of defense are not particularly effective. A popular theory is to use different types of systems—for instance, in an architecture that has two packet filtering systems, you can increase diversity of defense by using systems from different vendors. After all, if all of your systems are the same, somebody who knows how to break into one of them probably knows how to break into all of them.
Using security systems from different vendors may reduce the chances of a common bug or configuration error that compromises them all. There is a trade-off in terms of complexity and cost, however. Procuring and installing multiple different systems is going to be more difficult, take longer, and be more expensive than procuring and installing a single system (or even several identical systems). You're going to have to buy the multiple systems (at reduced discounts from each vendor because you're buying less from them) and multiple support contracts to cover them. It's also going to take additional time and effort for your staff to learn how to deal with these different systems.
If you're not careful, you can create diversity of weakness instead of diversity of defense. If you have two different packet filters, one of them in front of the other, then using different products will help protect you from weaknesses in either one. If you have two different packet filters, each separately allowing traffic to come in, then using different products will merely make you vulnerable to two different sets of problems instead of one.
Worse yet, all these problems caused by differences may not have bought you true diversity. Beware of illusionary diversity. Two systems with different company's names on the front may have more in common than you think:
Systems of the same type (for instance, packet filters) share the inherent weaknesses of the technology.
Systems configured by the same people are probably configured with the same weaknesses.
Many different systems share the same code lineage—code for things like TCP/IP protocol stacks is rarely written from scratch.
It's not unusual for companies to simply resell other people's technology under their nameplates.
We'll look at each of these issues in the following sections.
If an attack gets through your packet filters because it relies on subverting a theoretically safe protocol, it will go through any number of packet filters, regardless of who they're made by. In this case, true diversity of defense is backing up a packet filter with a proxy system, which has some hope of recognizing protocol problems.
Diverse systems configured by the same person (or group of people) may share common problems if the problems stem from conceptual rather than technological roots. If the problem is a misunderstanding about how a particular protocol works, for example, your diverse systems may all be configured incorrectly in the same way according to that misunderstanding.
Simply using different vendors' Unix systems probably won't buy you diversity, because most Unix systems are derived from either the BSD or System V source code. Further, most common Unix networking applications (such as Sendmail, telnet/telnetd, ftp/ftpd, and so on) are derived from the BSD sources, regardless of the platform. Any number of bugs and security problems in the original releases were propagated into most of the various vendor-specific versions of these operating systems; many vendor-specific versions of Unix still have bugs and security problems that were first discovered years ago in other versions from other vendors, and have not yet been fixed. Linux, which has an independently developed kernel, uses many applications derived from the same Unix heritage.
Similarly, Windows NT-based systems inherit any Windows NT weaknesses. Some versions of Windows NT-based firewalls replace Windows NT's IP stack, which removes one major source of common holes but may introduce others.
"Black-box" systems are based on something—usually a version of Unix or a Microsoft operating system—and they inherit weaknesses the same way any other system does.
A number of vendors remarket other people's products. This is particularly true in the firewall market, where a number of companies that basically write applications software are trying to provide entire solutions. They do this by buying the underlying computer and operating system from somebody else and doing a more or less subtle job of relabeling it. There usually isn't any desire to mislead people; it's simply a marketing plus to have something that looks unified. In addition, relabeled machines may be acceptable when the originals wouldn't be—a manager who won't have Unix, or a company that won't buy a machine from a direct competitor, may find a "black box" with an innocuous name on the front acceptable. However, this candy-coating may unexpectedly reduce your diversity of defense to diversity of decor if you're not careful.
Although many sites acknowledge that using multiple types of systems could potentially increase their security, they often conclude that diversity of defense is more trouble than it's worth, and that the potential gains and security improvements aren't worth the costs. We don't dispute this; each site needs to make its own evaluation and decision concerning this issue.