On Chains, Meshes, and Defense in Depth

Thomas Ptacek | March 29th, 2007 | Filed Under: Defenses, Uncategorized

Interesting discussion taking place over Nate’s most recent post, clarifying the difference between “mesh” and “chain” design.

The confusion here seems to stem from the similarity between “mesh vs. chain” to “defense in depth”. I’ll argue that the concepts are somewhat orthogonal.

Imagine any one security feature takes 1 person-week to implement, and in your release cycle you have 12 person-weeks to spend on implementing security features. The sum of these features is your security design. Imagine an attacker has to spend a person-week to beat any one of these features.

Here’s a “chain” design:

mesh.png

Obviously, if any one of these checks fails, you’re toast.

The classic example of chain designs is antivirus. A release ships with N “signatures”, each tuned to a specific type of virus (at varying levels of genericity). If you can take a virus and change it just enough to beat the signature that’s tuned for it (like Consumer Reports did), the system fails catastrophically.

This system sucks; you spent 12 person-weeks, and an attacker only has to spend one. Don’t design chain systems.

Here’s a “defense in depth” design:

chain.png

Again, you spent 12 person-weeks. Clearly, now an attacker has to spend three person-weeks to win.

A good example here is network and systems security: firewall, IPS, and patching. A missed firewall rule (one chink of the first chain), a rusty IPS signature (a chink of the second), and an unpatched network service (the third), and you’ve lost.

This system also sucks (12 defender weeks to 3 attacker weeks), but it is sometimes the best we can realistically do —- although far less often than we assume.

Here’s a “mesh” design:

depth.png

Every check depends on every other check. It takes 12 attacker-weeks to beat this design. This is the ideal we’re aiming for when we design security systems. Yeah, this isn’t really a full mesh, it’s a biconnected graph; shut up.

I’ve worked a little with Nate on systems that are transitioning from “chained” designs to “mesh” designs, and I’ll point out that the idea works outside of cryptography (though perhaps not outside of software development).

Viewing 4 Comments

    • ^
    • v
    This pretty much matches what I've been saying. I actually have some concrete examples of the mesh design model that aren't cryptography, but you'll have to wait until I finish and post them.

    More soon!
    • ^
    • v
    One can also introduce the concept of forward-security (not exactly the same as in the usual cryptographic definition) as well. A good defense in depth chain design should exhibit this property. Forward-security means that breaking an individual chain should not make it easier for an attacker to break any of the other chains. Obviously this cannot be applied to your definition of a mesh.

    Also I think there is a balance between a defense in depth design and a mesh design. Like a series of loosely coupled chains. An attacker *could* break each one separately, but the chains reinforce each other such that breaking one is much more difficult in the presence of the others. In this case forward-security would apply. Forcing an attacker to break all at once makes sense for cryptographic algorithms and protocols, but I think it’s much harder to do in software systems.

    I gave an example (not a very good one) of how this could be done for physical security on Nate’s page. I look forward to some more non-cryptographic examples.
    • ^
    • v
    I actually think Nate is talking more in terms of your "forward security" than my mesh definition.

    For 12 defender checks, my progression from chain to mesh goes 1 attacker victory, then 3, then 12. Nate's is 1, 12, 12. Nate is saying "you have to beat all the checks, but the attacker's effort decreases for each one you beat".

    The difference between "depth" and "mesh" for him is, as with "forward security", one of leverage: an attacker can concentrate efforts on one defense, like a blade concentrates force on an onion.

    There's a spectrum in both interpretations.
    • ^
    • v
    I also look forward to more examples from anyone, to better illustrate the concept. Chains, defense in depth...they've been pretty beat to death (not that they're dead, but we know what we're talking about with them). I'd love to read more about mesh or "forward security."

    Of note, I like reading not only Nate but another (your) rewording of the concept. Seeing it a couple different ways certainly helps the understanding!

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus