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.
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.
Comments
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.
Harlan
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.
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.
I tried to clear this up in another post. Hope it helps.
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?
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.