-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/1044/defense-in-depth-reconsidered-is-information-security-anything-like-war/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
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 ;)
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.
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?
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".
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 :) ).
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.
Defense in depth just makes things harder for the attacker and potentially that much more rewarding.
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?"
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.
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.
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/pro...)
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_1...)
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.
@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).
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.
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.
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.
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...
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.
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.
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.
If one doesn't accept DiD to some degree or other, does that mean one believes there is a perfect security measure?
* 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.
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.
> 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.
======
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.