Defense in Depth, Reconsidered: Is Information Security Anything Like War?
Thomas Ptacek | April 21st, 2008 | Filed Under: Don't Believe The Hype
Despite repeated assertion, I am dubious about the standing of “defense in depth” as a core principle for security design. It is, for example, not one of Saltzer and Schroeder’s Principals for the Protection of Information . It does, however, feature prominently in the Common Criteria —- which should tell you something.
To help sort out the controversy, I enlisted the support of my colleagues, adding “thoughtful commentary on this post” to their quarterly MBOs. I got responses from:
Dave Goldsmith
Eric Monti
Max Caceres
Jeremy Rauch
“If it were me,” begins Dave, I’d define defense in depth so that it has some meaning.” “That’d be a first,” riffs Eric. Burned! Continues Dave, “as a core principal for security design, [depth] has always been a little odd. It’s the baker’s dozen donut of design principals. Do the other ones and you get this for free.”
Eric agrees. “I think that when your approach begins from the basis of ‘depth’, you run the risk of covering bad design problems with complexity instead of rooting them out.” But Eric also associates ‘depth’ with network security, not application security, cautioning that it may make sense to employ layered security when you don’t control the “critical design elements.” “It irks me when vendors talk about ‘defense in depth’,” he says, but “I generally take it as good sign when customers do.”
Well, as I’m thinking about it, “defense in depth” originates from military thinking. Here’s an interesting Google book search: “defense in depth” in books published between 1900 and 1980, before the term was hijacked by infosec.
In this sense, the strategy of defense in depth succeeds or fails in any computing setting only to the extent that the analogy to warfare applies to that setting. Despite its attractiveness, with clean mappings to “attackers” and “defenders”, computer security is more like a puzzle than combat. In particular, computer security challenges often lack the attributes of combat most applicable to “defense in depth”:
Attrition
Exploits are not worn down by being forced to overcome multiple defenses; the attack that hits home after an obstacle course is no weaker than that attack, unimpeded. Jeremy agrees: “Linking computer security to military strategy is a lot like using traditional military tactics against terrorism. It doesn’t work.”
“But I’ve seen experienced exploit developers get worn down and demoralized by multiple filters they need to overcome to exploit”, replies Max. “jumping off memory in the JVM to overcome DEP involves effort to bypass a deliberate security mechanism, while doing the Heap Feng Shui dance also involves effort: this time to deal with an allocation structure that’s dynamic.”
“I know when I audit code that I have seen places where a vulnerability would have existed if not for multiple defenses,” says Dave. “Unfortunately, I can’t recall a single one right now.” My point exactly. And you have to do better than that example: you have to find the one where no single well-designed defense could have worked.
“There are no winters on the Internet,” argues Jeremy. “For a hacker, there’s no drawn-out war. It’s either attacks of convenience, or a slog against a specific target, with no penalties for taking your time.”
Deterrence
The presence of a countermeasure rarely gives an attacker pause, because the failure costs the attacker little and success rewards greatly. “The price you pay for the time expended developing an incredibly complex exploit isn’t losing life or limb,” says Jeremy, “All it costs you is a normal sex life. And thats what porn is for!” No offense, Mark.
“There’s a saying,” Max notes. “You don’t need to be faster than the cheetah, only faster than the guy running next to you.” Not many people target OpenBSD or GRLinux when there are soft targets to strike instead.
“I’m not sure that’s a deterrant,” relies Dave. “The people who will stop looking are the people who can’t find things anyways.”
Delay
A typical attack —- and, in particular, most of the attacks that top enterprise threat models —- executes in milliseconds. The time costs of successive countermeasures delay the attack in sub-human timescales.
Max concedes the point. “I agree delaying an attack is meaningless. Delaying the research required to get there may be worth something, though.”
“Delaying for delay’s sake is silly,” says Dave, “but the purpose isn’t to delay. It’s to encourage the attacker to make a mistake. It’s like the old game Berzerk. Electrically charged walls. Evil robots. Time limits. All multiply the likelihood that the game will end. The more you remove, the easier the game would be. Even just sitting there as an attacker can get you caught. To maintain access to systems, you have to do something that is ultimately detectable (no matter how unlikely). Even just sitting there encourages the big boucing head of detection to roll by screaming Intruder Alert! Intruder Alert!’”
Reaction
Because they rarely buy meaningful amounts of time for the defender, countermeasures afford little opportunity for defenders to retaliate (for instance, by involving law enforcement). In fact, the grooming requirements of countermeasures often have the opposite effect, forcing defenders to chase shadows or scramble to update filters.
Max isn’t sure. “If in the process of figuring out the policies of your web app firewall I trigger 100 alerts, you may be paying more attention to me by the time I actually get the exploit right.”
Eric isn’t having any of that. “If we ever make computers HALF as smart and alert as one average armed soldier standing by a door, then defense in depth may have a chance. Until then my money is on evasion. Even with a super-smart human security expert sitting 24/7 behind an IDS today, we have no real hope of filtering and reacting in time to security events. I totally agree about the grooming requirements. I’ve seen these become obsessions that completely wash out more productive uses of time.”
Predictability
The constraints on real-world combatants are far stricter than those placed on computer attackers. Warfighters can work from a palette of reasonable assumptions, including the fact that enemies can’t teleport, stop time, shapeshift, or reverse the trajectories of bullets. Analogies can be made from each of these fantasy capabilities to real instances of real security attacks.
“That’s a stretch,” replies Max. “I do think computer attacks can be somewhat predictable, or at least, as unpredictable as an ace war pilot.”
Eric agrees, with reservations. “There are some predictable behaviors that can be useful to notice and incorporate into your defenses. But, the problem is their shelf life is so short. As soon as those defenses are known, they’re obsolete.”
“But you can do everything right in an application,” replies Jeremy, “and still find it being used for unintended outcomes.” But isn’t the infosec equivalent here “accepted risk”? “I suppose the concept of accepted risk is a lot like the military concept of acceptable collateral damage —- but at least in security, the stuff at risk isn’t 18 year old kids.”
