Mesh vs Chain

When Matasano Chargen suggested reading Nate Lawson's blog, I immediately added it to my Bloglines collection. Today I read Building a Mesh Vs a Chain and Mesh Approach vs Defense-in-Depth. Nate's basic premise is this:

When explaining the desired properties of a security system, I often use the metaphor of a mesh versus a chain. A mesh implies many interdependent checks, protection measures, and stopgaps. A chain implies a long sequence of independent checks, each assuming or relying on the results of the others.

With a mesh, it’s clear that if you cut one or more links, your security still holds. With a chain, any time a single link is cut, the whole chain fails.

He explains why mesh != defense-in-depth:

A commenter suggested by email that the mesh concept in my previous post is very similar to defense-in-depth. While they are similar, there are some critical differences that are especially important when you apply them to software protection.

Defense-in-depth comes from military history where a defender would build a series of positions and then fall back each time the enemy advanced forward through the first positions. This works in security as well. For instance, a web server may be run in a restricted chroot environment so that if the web server is compromised, damage is limited to the files in the restricted directory, not the whole system.

The mesh model, on the other hand, involves a series of interlocking checks and enforcement mechanisms. There is nothing to fall back to because all the defenses are active at the same time, mutually reinforcing each other. This concept is less common than defense-in-depth for network security use due to the difficulty of incorporating it into system designs. However, it is extremely common in cryptography.

I suggest reading both posts for more information. I found this design idea very interesting, but I agree that implementing it outside of cryptography seems difficult. It would be neat to devise more mesh-based systems.


jbmoore said…
Wouldn't a mesh defense be an all or nothing proposition? It succeeds or fails based on the whole design. Therefore, if there is design assumption made that isn't valid that's exploitable, you could lose everything. I'm reminded of John Walker the spy. He and family members obtained most of the crypo keys and codes the Navy used for 10 or more years. The Russians needed the hardware though because just the keys and codes by themselves were useless. They had the North Koreans seize the U.S.S. Pueblo to obtain the hardware part of the crytographic equations. Game over and certain key US Naval communications were compromised for 10-15 years. Same thing with the German's Enigma systems during WWII, though some Gestapo codes were never cracked. You might need some sort of hybrid defense-in-depth/mesh architecture to really succeed.
H. Carvey said…
Defense-in-depth comes from military history where a defender would build a series of positions and then fall back each time the enemy advanced forward through the first positions.

This is an overly-simplistic definition of "defense-in-depth". There are other components included, such as the use of terrain and obstacles to channelize the enemy's approach, bottleneck them, and slow them down. There is also the initial use of longer-range, more lethal weaponry to get the approaching enemy to button up, as well as to whittle their forces.

In a network sense, the "defense in depth" implementation is more than just "A chain implies a long sequence of independent checks, each assuming or relying on the results of the others". For example, on an ingress point into the network, if there is a router followed by a firewall, and then followed by an IDS, I would mirror the rulesets on each. That way, I knew I had an issue if the firewall started picking up port 139 on the external interface, as that would mean that the corresponding rule on the router had failed, or I had another issue. I would then have to escalate if the IDS started picking up port 139 traffic coming from the firewall, as that meant that both the router and the firewall rulesets had failed or been compromised somehow.

Anonymous said…
A City Is Not a Tree, Christopher Alexander, originally published in the 1960's, reprinted many times since then.
Worth a read, it's a short essay on design systems when applied to urban development, and I'd say it's one of my favorite expressions of this kind of thinking.
Thomas Ptacek said…
He's not saying "defense in depth" is the same as a chain. It is worth noting, though, that "defense in depth" designs in network and systems security so commonly devolve to "chain" designs that "defense in depth" has been largely discredited.

Mesh design is definitely not the same as "defense in depth"; the concepts are orthogonal. A "defense in depth" design for game state protection in an MMORPG could employ both serverside and clientside checks; that's depth. The clientside defenses could integrate crypto primitives, timing, and environmental probes; that's mesh.
Unknown said…
Thomas has it mostly right. The other examples make my head hurt because they're non-sequiturs.

I tried to clear this up in another post. Hope it helps.
H. Carvey said…

Good point. This is along the same lines as the statement that "prevention eventually fails"...if something isn't done properly and no effort is made to implement something correctly, then how can one claim that it doesn't work?
Anonymous said…
The thing about history is that it never ends, does it?

There always new chapters being added.

To say that based on a history of past failures that no one will ever succeed is a bit fatalistic. All that says is that the odds against success appear to high. Maybe the right guy smart enough to succeed just has not come along yet.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics