nCircle.com >> 360 Security >> Patterns

Main | February 2007 »

January 2007 Archives

January 30, 2007

Welcome to Patterns

Aloha,
welcome to patterns. It might sound like an odd name for a blog but I think it is perfect. You should know by now that I spend all my waking hours looking for patterns and the patterns of patterns. I blame this obsession on the works of D. Hofstadter, A. Toffler, G. Bateson, and all the great minds who saw patterns in everything they observed. In the end, it is all about patterns.

Over the coming weeks, I'm will draw upon patterns in anthropology, information technology, biology, cybernetics, autopoiesis, music, game theory, and explore the patterns that connect us all. The patterns of patterns that connect the techno-social sphere we call the Enterprise.

This is not a place where you bring your questions to be answered, it is a place where you bring your answers to be questioned. I hope you find value this blog.

--tk

January 31, 2007

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

About January 2007

This page contains all entries posted to Patterns in January 2007. They are listed from oldest to newest.

February 2007 is the next archive.

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