During the Cold War, the United States wanted to learn more about Soviet submarine and missile technology. How fast were the Soviets progressing? What were the results from their ICBM tests? Even more important, were the Soviets working toward a first strike capability? In October of 1971, the United States sent its most advanced nuclear spy submarine, the USS Halibut, deep into Soviet territory in the Sea of Okhotsk. It’s mission? Find the undersea telephone cable that connected the Soviet submarine base at Petropavlovsk to the Soviet Pacific Fleet headquarters on the mainland at Vladivostok (Figure 5.1). The mission was a success, and you can imagine the mood of the divers as they eavesdropped on the wire with an instrument that measured electromagnetic emanations. What they heard was easily understandable Russian conversations—no encryption. The following year, the Halibut installed a permanent tap on the line to record the conversations, with a plan to return in about a month to retrieve the records. Eventually more taps were installed on Soviet lines in other parts of the world—the more advanced instruments could store a year's worth of data. All in all, the intelligence gathered from these exercises helped end the Cold War, as it gave the United States a window directly into the Soviet mind (Sontag and Drew 1998)

Figure 5.1 The Sea of Okhotsk

What does this story have to do with computer security? It demonstrates what can happen when systems are designed without redundant security measures. The Soviets assumed that their conversations were secure simply because they were being carried on phone lines that were protected by perimeter defenses (the entrance to the Sea of Okhotsk is much more narrow than my map might first indicate and could easily be defended by the Soviet Navy).

Companies rely on firewalls for perimeter security. Most developers assume that if they are behind the firewall they’re safe. But think how easy it is for an attacker to slip behind a firewall. Want some information from an internal company database? Just pick up the phone and call someone in the company and ask for it (Mitnick 2002). Or use a modem to contact someone's computer inside the company. Or park your car in the company's underground parking garage and surf onto the company intranet via an insecure wireless connection set up by the employees for convenience. Feeling cocky? Walk into the company's headquarters and ask if you can do some work in an empty conference room while you wait for an employee to meet you. Then plug into the Ethernet jack in the room and party on. You'll be surprised how far you get once you find out the names of a few employees. Don't want that much risk? Then compromise an employee's home computer and use his VPN connection to access the network.

These examples assume you are worried only about outsiders getting behind the perimeter. What about the employees who are authorized to work behind the firewall each and every day? I'm not trying to insult you or your colleagues, but you should know that your fellow employees aren't always thinking about the good of the company when they’re on the job.

Defense in depth is all about building redundant countermeasures into a system. Don't assume a perimeter defense will protect you. Don't assume someone else's code will protect you. When you write a component, validate the input assuming it can be purposely malformed. Just because your component is currently used only by other trusted components doesn't mean those other components were written by people who know how dangerous malformed input can be (WhatIsSecureCode). Besides, components are designed for reuse, so a component that's used by trusted components today might be deployed in a less trusted environment tomorrow. And never assume that because you're behind a firewall that your internal network conversations are automatically secure. Make sure internal server to server communication is protected (WhatIsCIA).

Always think about failure. Secure systems should not fail badly; rather, they should bend and flex before they break (Schneier 2000). Using a mixture of countermeasures that overlap can provide a synergy that makes the resulting system more secure than its individual parts (WhatIsACountermeasure).

PortedBy RubenBartelink