nCircle.com >> 360 Security >> Patterns

« Welcome to Patterns | Main | Who do we have on the line? »

Defense in Depth is Dead! Long live Defense in Diversity

For years now, one of the principles in IT design has been Defense-in-Depth. The term is misleading and I propose we scrap it for a more accurate term: Defense-in-Diversity. As IT operations and information security principals become intermixed, the proper understanding of this term is critical. Higher levels of redundancy in the same pattern does not significantly increase a systems defenses when faced with a well motivated adversary.

The term Defense-in-Depth is a misleading term to someone who is not an expert in the security domain and centers around the interpretation of the word 'depth'. To most, this is the extent of a particular unit like the depth of water, a shelf, or a cookie jar. It is in this context that the term can be dangerous as an information security design principal.

Lets take an example from a great movie Ocean's Eleven (the original or the remake). On one hand, the casinos in this movie could afford and in fact had implemented a great deal of Defense-in-Depth. On the other hand, the casino's adversary did not see Defense-in-Depth, he saw patterns that revealed a lack of diversity that he and his team could exploit. The lack of diversity in both systems and processes raised the predictability and in turn, the certainty of the adversaries execution plan to rob the casinos. In order to raise the cost to the adversaries, the casinos should have been focused on raising the diversity of the processes and systems and not the depth.

Another pattern I'd like to call on as an example is the AI of a particular type of video game. Games like Street Fighter, Mortal Kombat, Tekken, and Soul Caliber have an AI component to the games ability to kick your butt. If your have played these games for any length of time, you know that constantly pushing something like X, X, X over and over again will get you no where fast. The AI learns your patterns and defeats you (I can hear that deep Mortal Kombat voice saying "FINISH HIM!)
On the other hand, some noob steps up and starts to mash at the buttons, and for a little while, wins a few and advances. He has raised the cost to the computer in mapping to a predictable causal model that is the dominant strategy. This gets in to other realms like possibility spaces but for this blog posting, I'm only trying to show how powerful diversity is over quantity.

Now if you are an expert in IT operations, you might be reading this and saying "this dude is nuts". "Adding higher levels of diversity to my systems means moving away from standard models that I can just iterate and manage". "Adding higher levels of diversity to the my processes means that my processes will be unmanageable". When I say that IT operations and IT security will need to unify in their design principles, this is what I mean. At this point in time, it is like watching a monk and a priest try to convince the other that they set of belief is the "right" way.

Question: How can you introduce diversity in to a system without raising its administrative costs?
(how can I raise the cost to my adversary without raising the cost to my administrators or users?) In most systems today, this cannot be done because of the tight coupling. Keep in mind, just because it cannot be implemented in your current system does not make the principle wrong.
There are many answers to this question and there is no telling what will work for you. Let me end this blog with a pattern that might get your creative juices flowing.

In order to successfully design using this Defense-in-Diversity principle, we must decouple the service from the server. In nature, we can think of it as the difference between organism and species. The two sit at different logical levels: the goal is for the species to survive, not the organism. Apply this to IT and you have systems like load balancers and server farms which abstract the service (the species) from the server (the organism). The demand side of this service will see a very consistent and available service (the species) while the cost to learn and exploit the servers (the organism) can be very diverse and under continuous change.

We should embrace Operating System virtualization as an enabler for Defense-in-Diversity. I'll be talking more about this in future blog postings. We must be able to decouple the service from the server in order to design Defense-in-Diversity systems. These systems raise the cost to any adversary just enough to where he/she has a choice: become more exposed in trying to attain intelligence of the target systems or go exploit someone else. This marginal cost is the equilibrium we seek between adversaries and target systems.

--tk

TrackBack

TrackBack URL for this entry:
http://blog.ncircle.com/cgi-bin/mt-tb.cgi/125

Comments (6)

Osama Salah:

You might have something here but your "examples" and analogies are so abstract. Can you please elaborate your "Defense-in-Diversity" with a more concrete example?
For example the typical "defense in depth" scenario is the use of two perimeter firewalls preferably of different vendors and technologies. How would you change this model to your proposed Defense-in-Depth system?

rgds
Osama Salah

WTF? :) Honestly, this just looks like semantics for me, and I think defense in depth is just fine as a term.

Of note, in nature, the species cannot survive if the organism dies. The organism is the first priority (and strongest instinct: survival to pass on genes). The species is a result of the continued ability of a series of organisms surviving.

TK:

Sure, we can call it semantics if you wish.
Who gets to decide when semantics matter and when they don't? The context determins this and the importance belongs to the situation at hand.

I don't know if you are really interested in this discussion of species and organisms but lets say that you are: You are absolutely correct in the relationship between organisms (plural) and a specie (singular). [the members and the set]

I'm drawing the analogy from the position of Gregory Bateson's view of evolution and not from a position of C. Darwin. What I was trying to show was the levels of abstraction and how the logical levels that are being represented in the naming are often misused and abused.

Maybe a better less structured example would be how a certain community would need 10 different ways to speak about snow and how another community would just have 1 or 2. Why? Because the former community has a need, a specific content where this distiction must be made or is very useful to be made. The reason why these arguments go round and round is because everyone is right and no one is wrong. :-)

I appreciate your comments because it is more often than not that people say that I make too big a deal on the words we use. No biggy, it may not matter to everyone but it really matters to me. I can't think clearly if my names and labels are in a muddle. :-)

joat:

Congratulations. You've come up with a concept that the fashion industry(1) stomped to death years ago. However, the trick is to use diversity in conjunction with defense in depth, not as a substitute for it.

Also, what's this "decouple the service from the server" nonsense? From the network side, there's no visible difference. Attack the server and the application (the service) falls offline. Attack the application, and the server can be compromised. Virtualization in the context you use is otherwise known by terms such as failover systems, load leveling, and hot standbys. Operating system virtualization provides nothing more than an easier way to perform entire system backups and/or maximize the use of available system hardware.

(1) "fashion industry" - that portion of the security industry that tends to adopt poses for the sake of vogue-ness. Can we call 'em Vogons yet?

batz:

Perhaps if you framed this as "Diversity in Depth", some useful details begin to appear. Examples of this can be found in things like introducing randomness to TCP ISN's, inode allocation in file systems, socket numbers in handshakes, windows GUID's, cookie hashes, and even file names in temp files. These all reduce the predictabililty, therefore increase the "diversity" of systems to protect them from attack.


The predictability of a target environment is a benefit to the attacker. For all you little Joe's out there, you may remember that, "Knowing is half the battle." Randomness is an obfuscating technique that we use to remove that predictabillity.


Sure, if people wrote or compiled code that had some kind of theoretical pseudononymizing proxy that used some kind of masking algorithm to manage a program's access to real stack addresses, the execution path would be sufficiently "diverse" as to prevent a payload from successfully jmp'ing to the correct address in the stack, precluding it from executing itself.


But I don't think that's the real world.


So, diversity in this context, can be implemented at any logical level from the assembler to the data centre. It's a variation of entropy. Selling solutions that increase the entropy of your data centre sounds like a really fun ad campaign, at least until people find out what entropy is anyway.

Matt Richard:

Diversity is an interesting idea and I run across the misconception of defense in depth all the time. I have seen many who think the idea of DiD means using the same AV engine on your desktops and mail server because it's in 2 places.

Doing pen tests I see the same problems in network security. Networks provide a lot of predictability when implementing network security features such as using one vendor for firewall, ips, ids, etc. This allows for quick profiling and easier exploitation since most of the architecture can be inferred.

Going back to the survival analogy there is a reason that nature provides a large amount of diversity in a species - it allows the species to survive unpredictable future events by having some with one property and some with another. This can be an argument against genetic engineering foods and organisms, you remove the diversity which allows them to survive unanticipated events.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Verification (needed to reduce spam):

About

This page contains a single entry from the blog posted on January 31, 2007 12:31 PM.

The previous post in this blog was Welcome to Patterns.

The next post in this blog is Who do we have on the line?.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.35