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.”
Anonymous
April 21st, 2008 7:11 pmI’m still sitting on the fence with regards to defence in depth but I think delaying an attacker has merit. Whether that is in the exploit development stage or the actual attack.
Safes these days don’t say that they’ll keep * out but rather they will keep a skilled attacker out for X amount of hours. Attacking something is all about effort. Hence why the average attacker will not go after the OpenBSD boxes.
On another note ““All it costs you is a normal sex life.”, maybe we should ask Dowd how much of his normal sex life he lost with that flash exploit
Thomas Ptacek
April 21st, 2008 7:20 pmIt’s a good point. Some security problems are best modeled as the safecracking problem — particularly DRM and software protection.
But they key insight driving that model? *The problems are believed theoretically impossible to solve.*
With regards to the price Dowd paid, you need to have a soul and a heart that pumps blood instead of ice cold synthetic coolant to care about your sex life. Dowd is reproduced in factories; he’s not concerned.
Ryan Russell
April 21st, 2008 7:32 pm“you have to find the one where no single well-designed defense could have worked.”
Who says that’s the standard? If it is, then just fix all the vulns. Problem solved.
So, you plan to stop recommending ASLR and NX and such, then?
Thomas Ptacek
April 21st, 2008 7:35 pmI don’t know about ASLR and NX. That’s an open question for me.
You’ll hear more from me on defense-in-depth, but for the time being let’s sum up my position as, “if it has no customer cost, I don’t object to it”.
Chris
April 21st, 2008 7:59 pmIt all comes down to economics IMO. And that goes for both offensive and defensive sides. An arms race kind of thing. Except in this case time can be more important than money, so the attacker usually has the upper hand. So delaying the attacker is probably the best you can do in most cases.
John Fsck
April 21st, 2008 8:30 pmI’m not sure I understand your Common Criteria reference? In my opinion as a CC evaluator the CC is rather light on defense in depth, if you’re really bored look at how a Security Target is constructed, some property of the TOE (target of evaluation) is mapped to a threat and the threat is considered mitigated (after the assessment of a considerable amount of rationale and testing). A lot of the time threats are mitigated by the physical environment, ie your network device is locked away securely, but then it is difficult to construct a security target to state that physical tampering is defended against in depth by physical mechanisms in the environment and some other feature on the product.
I could possibly understand the argument of CC being utilised in a defense in depth manner, ie stating you must have EALX level devices where X increases with perceived threat. The application of evaluated products obviously differs somewhat from the evaluation process itself though.
I’m not sure how coherent this comment has been, really i’d just like you to elaborate on the common criteria reference (without starting a flame war as to the CC’s value
).
David LeBlanc
April 21st, 2008 8:39 pmThere are two Saltzer and Schroeder principles that are included somewhat as an afterthought. The first is work factor. The obvious example is a repeated password verifier hash. You _can_ get the password, just not before the information loses value. There are other examples, especially operational, where making the attacker work results in them bothering someone else or making enough noise to set off alarms. Which leads to the second - if you cannot stop someone completely, it is often a good thing if the problem can be logged.
Mongo
April 21st, 2008 8:57 pmthe entire GRSecurity/PaX philosophy is about layering exploit mitigation techniques together to make some exploits impossible and others very low probability, as Ryan pointed out. This is combined with MAC/RBAC systems that try to make the targeted program useless for further system compromise by denying it the ability to do anything useful for an attacker that’s not required for the program to do it’s job.
these protections lose significant effectiveness when not deployed as a whole but in piecemeal - it’s a very gestalt system.
When combined with software developed by security-aware programmers that goes through a through security audit, I think this certainly qualifies as defense in depth for your (C and C++ based) software.
kowsik
April 21st, 2008 11:34 pmDefense in depth is like “layered condoms”. At some point, you just get comfortably numb and you don’t quite feel safe either.
sigsegv
April 22nd, 2008 7:58 amThe truth that everyone needs to realize is that the attackers will *always* win (one way or another).
Defense in depth just makes things harder for the attacker and potentially that much more rewarding.
Alex
April 22nd, 2008 8:12 amRE: Predictability
First, it’s worth noting that the ability to create accurate probability statements can be very different from the ability to be precise. That’s a nuance lost on many security engineers.
Second, there’s a “level of abstraction” decision that goes along with that quest for accuracy and balance with precision. For example:
“How big is Chicago?” seems to be a simple question to answer, but depending on need it can be very open ended. Two questions that come to mind immediately are “How granular does our metric need to be?” and “What do we consider “Chicago?”. We might be able to be usefully accurate at a “square mile” level for some definition of “Chicagoland”, but be unable to get solid measurement at the “square centimeter” level.
Predictability, in risk and risk management operates the same way. We may be able to get useful accuracy by sacrificing some precision.
Finally, because you are trying to predict, this means that security and risk become probability issues. This presents two significant challenges:
1.) A lack of data (so a frequentist approach suffers)
2.) An amount of uncertainty
DiD modeling can be done with some degree of pragmatism using stochastic methods, expressed as a probability. But the value of DiD is going to be particular to several factors. That value will change based on these variables (threat community, for example) and, of course, carry uncertainty in the probability statement. This probability statement also has relative value. It may or may not be able to answer “Are we secure?” depending on how we define “secure”. It sometimes can help answer “Can we justify another security trinket in our menagerie?”
ServerGuys SMB Network & Security Blog » Blog Archives » Defense in Depth Not So Deep?
April 22nd, 2008 10:02 am[…] at the Matasano Chargen blog, Thomas Ptacek challenges the conventional wisdom of Defense in Depth by taking to task the comparison of InfoSec and war strategies. Analyzing the analogies we use is […]
Interesting Bits - April 22nd, 2008 « Infosec Ramblings
April 22nd, 2008 11:08 am[…] Defense in Depth, Reconsidered: Is Information Security Anything Like War? - An interesting read about defense in depth. […]
wrc
April 22nd, 2008 12:57 pm“Even just sitting there encourages the big boucing head of detection to roll by screaming Intruder Alert! Intruder Alert!”
Evil Otto always wins!
It’s all a game of managing the attacker’s risks in relation to the value or utility of what they hope to acquire.
mdg
April 22nd, 2008 1:25 pmDiD shouldn’t be presented as an alternative to rooting out and fixing vulnerabilities. The fact is that our current development methodology virtually guarantees that vulnerabilities will always exist, not matter how many Thomas Ptaceks evaluate the code. Once you’ve dealt with the vulnerabilities that you can find, you have to begin thinking about the ones you missed— like the NULL pointer vulnerability that leads to an attack on your clever byte-code checker, etc. etc. etc. Because those vulnerabilities are still there, no matter how much attention you’ve paid to “getting things right”.
DiD is appropriate in this gray area where there really is no alternative. Maybe in the worst case it turns out to be no more effective than throwing salt over your shoulder or saying a prayer. But unlike those practices, it does actually have the ability to stop some attackers and maybe, just maybe, block those potential holes you missed. Certainly I’ve run into situations where that beautiful attack was /almost/ possible, except for some trivial additional check the designer had thrown in.
The only other point to make is that DiD shouldn’t be looked at as a one-for-one time tradeoff with other evaluation techniques. The real advantage to a good DiD strategy is that it’s often relatively inexpensive, and thus packs a lot of (potential) bang for the time buck.
Mike Tracy
April 22nd, 2008 4:24 pmThe concept of “Defense in Depth” as outlined in the
NSA paper (http://www.nsa.gov/snac/support/defenseindepth.pdf)
co-opts the name of a military strategy but applies it in a manner
unique to information assurance. The end of the first section of the
Saltzer and Schroeder paper (http://web.mit.edu/Saltzer/www/publications/protection/Basic.html)
alludes to the NSA’s take on defense in depth without actually calling
it by name and says it’s a good thing. It’s a strategy for applying
techniques and technology to securing information assets. Nothing more.
The Military’s doctrinal view of information assurance within the wider
doctrine of Information Operations (http://www.dtic.mil/doctrine/jel/new_pubs/jp3_13.pdf)
quotes the NSA paper directly.
The adulteration of the name will probably go on forever but I think the
concept as conceived is sound and useful. It requires threat modeling
as a prerequisite which is at the very least a good start.
max
April 22nd, 2008 5:03 pm@sigsegv: I’m not sure technology and/or products deployed under the DiD umbrella are always a win security-wise. I wouldn’t feel any safer running AV on my computer today.
@mdg: I’m with you, I think there are examples of smart applications of DiD that get can get you a lot for a little effort. One of the issues here is that a DiD mechanism fails once it can be defeated in a reusable form (think stack canaries, or limited address randomization), but I don’t think this is a given, there are examples where the approach works (W^X, privilege separation, automatic escaping of tainted input).
2giveup
April 22nd, 2008 5:27 pmAssumption: all civilian and most non black ops government systems are designed to have exploited flaws at all levels of design.
DID is just like a bulleye target. So why have more rings, when at each level, you have to find the flaw, and TRY to design around it, or handle the flaw somehow, or at least monitor it?
POINT: security requires simple, understood systems. Better the small problematic devil, than the SELinux heavan obscurity box on virtualized whatever, running on a “trusted BIOS” < FUNNY joke, come on.
Computer security REALLY sucks as a __fill in the blanks __. Reminds me of Al Capone days. Oh well. VAX was last full open design system to civilians, TBOMKnowledge.
Oh well. It used to be duck and cover, now its obscure and pray. GRR.
Andre Gironda
April 22nd, 2008 9:23 pmI like the cheetah-example. That’s the “weakest link” idiom that goes along with “defense-in-depth”.
Unfortunately, software security *is* the weakest link — not the network — not the systems — not the OS “exploitation countermeasures” — not the WAF — not the APIDS, RB-IDS, or network-based IPS/IDS.
If you want an accurate model for “defense-in-depth”, then you not only need IT/Ops controls, but also SDLC controls.
A software weakness (e.g. XSS, SQLi, stack-based buffer overflow) may have a workaround (e.g. NoScript, WAF, PaX/ASLR) - but the workaround only works 100% of the time when backed by a software fix that doesn’t reactivate the original (or any new) vulnerability. In other words, a bug is still considered critical priority to fix *in*the*code* if the bug can destroy, change, or conceal data.
ivan
April 23rd, 2008 2:06 amI’d look for different and more “modern” terminology to discuss the topic. I particularly like Nate Lawson’s idea of security “mesh” as opposed to a “chain”, it helped me realize that whenever I heard or read Defense in Depth I’ve actually thought of a mesh of interlocked security mechanisms that must all fail simultaneously rather than of a chained set of mechanism that can fail in sequence. The traditional defense in depth theory applied to information security may be nice to read and a sound military strategy (for a past era I’d argue) but it is a real-world failure when applied to todays networks and applications that have either one or at- most- two layers of depth and/or a steaming pile of extra security clutter stacked on top of itself.
Btw, I think that the better source for modern information security doctrine are casinos rather than military organizations. In that context, and to follow up on sigsegv’s comment: some attackers will occasionally win some may even win big, but in the long run the casino always wins unless there is a substantial amount of collusion.
Mad Irish
April 23rd, 2008 8:09 amI think it has become trendy in security circles to decry traditional paradigms like “defense in depth” or “network perimeter” but I think to do so is a mistake. Defense in depth is a perfectly acceptable practice. While defense in depth might not always be the security solution that prevents an attacker, it does offer some breathing room. Due to the complexity of systems it is likely that at any given time any system on your network (or server) might expose a vulnerability. Applying defense in depth protects these exposures. I think it’s irresponsible for people in the security community to toss aside a core principle like defense in depth. Nobody would recommend that a home user who utilizes file sharing on their network ditch their NAT device and expose their services to the internet. Because of the shifting nature of the security landscape, services that are secure now might not be in the future and only defense in depth can provide any sort of assurance given that evolution.
sigsegv
April 23rd, 2008 8:18 ammax: You’re correct; running AV shouldn’t make you feel any safer. Just like anything else, it’s another layer. It’ll stop the kids out there looking to throw an SDBot up on your box, but it won’t stop someone who’s out to own you specifically (pr0j3kt m4yh3m anyone?).
BTW, here’s a point that I think Thomas and those commenting are missing: there are more types of hackers than script kiddies and Mark-Dowdain super hackers. You also have the middle of the road attacker, who does pick out a target, does audit code (but won’t find a vulnerability in Flash or OpenSSH) and is willing to work for days/weeks/months on a target (or a set of targets).
Again, they’re not Mark Dowd, Halvar Flake or FX. By the same token they’re not xtix, mxn or twm (and that comparison probably went over a few heads), but they are competent and they do get lucky.
Oh, and Thomas, I don’t see how you can completely discount things like ASLR and W^X. IMO, they do help and make things more difficult for attackers of all skill levels.
I’m not part of the “security industry” so maybe my take on this is different than all of yours… whatever…
Jeremiah Blatz
April 23rd, 2008 11:26 amI’m going to have to call BS on this one. Maybe because I have a more convenient definition of defense in depth than you. I’m going to claim that defense in depth is an approach where the security of a system is maintained even if one defense is compromised. So, for example, you should perform both input validation and output encoding. That way, if you forget to do one, perhaps the other will save you. Or, how about not storing your passwords in cleartext. Theoretically, you don’t have to*, but what if someone compromises your password database? Properly salted, hashed password can mean the difference between full compromise and a bunch of annoying data. Anyway, the delay factor here is significant and linear to defense strength (unhashed vs rainbow table crackable vs dictionary crackable vs brute-force crackable). If the delay is long enough, the hashes are invalid by the time they’re broken.
Finally, I take issue with this: “And you have to do better than that example: you have to find the one where no single well-designed defense could have worked.” We do not live in a world where everyone has the luxury of well-designed and perfectly implemented defenses. Defense in depth, to me, is protection against mistakes, and as such, has tremendous value.
* This is a lie.
Thomas Ptacek
April 23rd, 2008 11:38 amThe defense that was compromised is, prima facie, superfluous.
As always, there’s a subtlety to this that I do a crappy job of surfacing. Because, I obviously agree that you shouldn’t store your passwords cleartext. But cases like that are the exception, not the rule, in layered defenses.
Dominic White
April 23rd, 2008 3:55 pmTo be honest, I’m failing to see a clear point here. I’ve read and re-read both the post and comments.
In my mind, defense in depth provides a clear guiding principle when designing security. I can point to examples, and I can practically use it to develop systems that are less likely to be compromised than others.
You discussion raises some interesting points, but I fail to see how any of them actually challenge the ‘practical reality’ of the term.
@Thomas, your response to Jeremiah, that his examples are exceptions may be were you need to elaborate, as to me those clearly aren’t exceptions. Off the top of my head I can suggest several more layers: segmented and ACL’ed networks in case your Wireless auth fails; chroot’ed environments in case there’s an active vuln in the app; encrypting sensitive data on your internal network in case your physical access control fails etc. These are all additional controls placed at subsequent layers of the system/data flows and interactions to ideally halt an attacker from proceeding further or at least force them into revealing themselves.
Phrased differently, successive layers of well defined defenses will decrease the likelihood that an infinitely patient deadline-less Mark Dowd will be successful and increase the likelihood that he’ll be spotted; which amounts to stopping the actual bad guys who are actually attacking you.
LonerVamp
April 23rd, 2008 5:11 pmBig props to Dave for this awesome bit: “…Even just sitting there encourages the big boucing head of detection to roll by screaming ‘Intruder Alert! Intruder Alert!’”
If one doesn’t accept DiD to some degree or other, does that mean one believes there is a perfect security measure?
Thomas Ptacek
April 23rd, 2008 5:55 pmDominic, to your examples:
* Segmentation — yes, this adds “depth” if your wireless security fails, but you do it for other, better reasons: making your network resilient against insiders.
* Chroot — chroot is a classic example of an “obstacle course” security measure (more on that later); no *known* vulnerability is better handled by chroot than by patching.
* Encrypting — you encrypt a laptop because of a constant physical threat of laptop theft. Most enterprises don’t meaningfully encrypt anything else: a domain admin account in a Windows network will get you everything at a Windows shop. Every encryption step you use just creates 100 more little obstacle course vulnerabilities an attacker will need to overcome.
There’s an argument to be made that some of these measures help against “unknown” threats. Maybe. They do, however, exert a powerful psychological (ie, narcotic) force over security people, and should be questioned all the more thoroughly as a result.
Dominic White
April 24th, 2008 2:26 am@Thomas. I think I’m beginning to see your point. Are you saying that an obstacle course just delays the attack, attackers aren’t bounded by time, and we don’t actually have appropriate methods for spotting an attacker once delayed?
I may have built a straw man, but I’ll poke it anyway by way of your responses to my quick examples, and I did mean them as quick examples, to show that Jeremiah’s weren’t exceptions; One control can mitigate multiple threats, that is a plus to DiD. Also, another principle of DiD, you shouldn’t rely on just one control (i.e. chroot AND patch). There may be ways around those controls, such as domain admin access, but that’s why you limit the number of domain admins and stick extra controls around them (increased auditing, more complex passwords, better trained users etc.) i.e. DiD. Additionally, by applying a DiD model (and its implied threat modeling as pointed out by Mike Tracy) you can spot where additional layers need to be applied, for examples PCI is driving payment applications to encrypt more sensitive cardholder stores outside the domain (well some).
All of this then comes back to your point, that most of these additional layers just increase a non-time bounded attackers time of attack. However, I’m with Dave on this one (I think), that the more meaningful and well though out layers of defense you add, the smaller the pool of attackers who could actually exploit it becomes. To rephrase that, you actually prevent (not delay) a large chunk of the threat community. The ones that remain are usually too few and too unlikely for a meaningful cost/risk reduction benefit to be gained, especially in a large organisation where it is likely the CEO just reset his password to ‘password’, i.e. there are bigger fish to fry. However, as both the organisational and vendor security maturity increases, there will be time to fry the high impact low likelihood holes.
Jeremiah Blatz
April 26th, 2008 12:10 pm@Thomas
> The defense that was compromised is, prima facie, superfluous.
> Chroot — chroot is a classic example of an “obstacle course” security measure (more on that later); no *known* vulnerability is better handled by chroot than by patching.
I’m loathe to engage in any sort of ad-hominem attacks here, but this seems like a shocking display of armchair security and theorycraft.
One may try, and fail, to perform output encoding on all parameters. This does not mean that he/she shouldn’t have tried. (It does mean that he/she should try harder.) You seem to think that one should do it perfectly or not at all; I do not see anything in the world that indicates this is a reliably achievable goal.
Regarding chroot vs patching, my mind boggles at your suggestion that patching is a reasonable defense. That would seem to imply that unpatched exploits do not exist, and that all patches are applied instantaneously. Both of these do not stand up to the most casual comparison to reality.
If what you’re trying to say is that defense in depth is not a substitute for rigorous application of the “key” defense, then I wholeheartedly agree. But in your zeal, you seem to be saying that rigorous application of the key defense is sufficient. The problem is that maintaining perfect defense is a losing proposition over any reasonable timeframe. In some cases, e.g. input validation + output encoding ( + parameter binding for databases), the defense in depth is an attempt to close the gaps over a class of attacks, such that the chance of all the mistakes lining up is close enough to zero. In others, such as patching + chroot ( + IDS in a place where you expect no attacks), the defense in depth is an attempt to prevent (or maybe just to detect) compromise due to unknown attacks. In either case, the approach has value.
Stephen Smoogen
April 27th, 2008 5:29 pmThomas, I would disagree with:
======
The defense that was compromised is, prima facie, superfluous.
As always, there’s a subtlety to this that I do a crappy job of surfacing. Because, I obviously agree that you shouldn’t store your passwords cleartext. But cases like that are the exception, not the rule, in layered defenses.
====
I quit counting the number of sites where passwords are stored in clear text in the database etc because “we have a firewall” or some such nonsense. When asked “what happens if the firewall fails” the general answer is “that can’t happen.”
The biggest reason for defense in depth in either networks or computer code is because of the human factor. The larger the organization or code base, the less you can assume that the next data bit you got is ‘clean’. Sure the company has a firewall and an anti-virus checker… but today they forgot to turn it on after a reboot or the vendor who does the anti-virus doesn’t catch that worm til 2 hours after the one on your local email server does.
The biggest area where I have seen attrition, etc work is in email arena. Box A has anti-virus software X which usually catches 90% of the viruses. Box B has anti-virus software Y which finds another 90% and C has another set. While A & B are ’superflous’ in the case where the virus got to C. most cases it is not and in some cases what A &B saw C would have let through.
The other issue where defense in depth has come in is where some previous gate is either overwhelmed or fails in some un-predicted way (the network engineer in trying to track down a problem puts a passthrough in and doesn’t tell others). The larger the organization, the more likely it will happen somewhere and by relying on a single defense model (usually someone else) you end up screwed.
Leave a reply