disagree with it. Vacuous propositions behave like semantic tautologies.
Such is the case with security in depth. Have you ever heard an IT professional champion the cause of “superficial security,” “shallow security,” or “myopic security?” Not likely. This is the primary reason why security in depth is so poorly understood. Its vagueness quickly gives way to vacuousness on inspection.
Figure 1. The WEP initialization vector is communicated in cleartext (for example, 0x58CDB1).
SECURITY THROUGH
OBSCURITY
I admit that a prima facie case could be made for security in depth even in the naive sense of “more is better.” When I propose adding a new vitamin to my diet, my internist tells me “At this point there is no physiological evidence that suggests that this substance is harmful to humans, so knock yourself out.” As with my vitamins, a random application of security applications and systems is unlikely to do any more harm than lure one into a false sense of security and perhaps slow things down a bit. And like the vitamins, when carefully and judiciously applied and evaluated in a controlled experimental setting, even naive security in depth can be of some value.
Such is not the case with our third model: security through obscurity (STO). No prima facie case may be made here. The general premise of STO is that invio-
lability is a consequence of the enigmatic. This is same sort of reasoning that helped the Imperial Japanese Navy and German Wehrmacht become the global powers they are today. The Japanese Purple and JN- 25 codes and the German Enigma cipher system were assumed to be inviolate precisely because of their hidden complexity. As far back as the 1880s, Auguste Kerckhoffs proposed that no cryptographic system that purports to be secure should be predicated on the assumption that no one would ever figure out how it worked— rather the emphasis should be robustness of the procedure and key strength. Both Axis powers failed to comprehend the weakness of STO. This also speaks in favor of the robustness of open source software.
Despite our intuitions, many software systems have adopted STO to their cost. To illustrate:
Windows buffer over-
flows, such as the
IDQ.DLL overflow in the
Code Red Worm, were
entirely predictable to
anyone who knew how
the Windows ISAPI
extensions worked. This
was a design defect that
produced a buffer over-
flow and ran the malware
with elevated privileges
since IDQ.DLL runs
within Inetinfo.exe as local
administrator. It was assumed no
one would notice the inadequate
bounds and error checking built
into the operating system. We’ll
place this in STO category I: fail-
ure to write secure code. Concep-
tually similar vulnerabilities, like
format string attacks (printf) in
Unix and SQL compromises in
Windows (IIS/RDS), would also
fall into our first category.
Another example is the entire suite of 802.11 security vulnerabilities. In this case, the defect was actually built into the standards. Nowhere is this more evident than with the wired equivalent privacy (WEP) protocol.
WEP has many “issues” that go beyond our current interest. However, one stands out as a paradigm case of a mistake carried through to perfection: the sloppy implementation of the RC4 symmetric, stream cipher. The faulty WEP algorithm was a part of the original IEEE 802.11 protocol
References:
Archives