3.7. Diversity of Defense
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.
3.7.1. Inherent Weaknesses
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.
3.7.2. Common Configuration
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.
3.7.3. Common Heritage
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.
3.7.4. Skin-Deep Differences
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.
3.7.5. Conclusion
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.
| | |
3.6. Universal Participation | | 3.8. Simplicity |