There is no Onion - The Painful Reality of Defense in Depth

Since I have been working in a security function (that’s roughly since 1998), the analogy of the “onion” has existed. The idea that security is a series of layers is somewhat of a given, and even today no one really questions its validity. Well, almost no one. There are some smart folks over at NSS Labs that recently did some testing. Dr. Stefan Frei published “Correlation of Detection Failures: The Challenge of Layered Security,” a report that you absolutely need to read. It may change the way you think about security, and if it doesn’t … why?


Imagine if you woke up tomorrow morning and it was conclusively proven that the layered onion model was proven to fail in several circumstances commonly deployed and used in today’s enterprise. That would sure explain much of the failure we’ve seen across enterprise breaches, wouldn’t it? As it turns out, when NSS labs tested 37 different security devices none of them detected the entire breath of the exploits executed across them, and only 3 percent of the 606 total combinations yielded full detection. This means that the odds of you guessing the correct combination to protect you against the exploits being crafted against you are slim to none.


This brings me to a scary realization. Is the onion concept a complete lie? Is the notion of Defense in Depth a total failure?


Luckily, the answer is no. Defense in Depth is still helpful in circumstances where the enterprise security organization understands the defensive technologies being put into play, their capabilities and limitations as well as their true effectiveness. Reading this you’re probably thinking the same thing I am — you’re depending on luck, largely, to save your bacon. The odds aren’t good.


From where I sit, the entire analyst brief comes to a pointy head with this fact:


The number of exploits that were able to bypass multiple security devices, as well as the number of security devices that were bypassed by these exploits, is significantly higher than is the prediction for risk models that ignore correlation.


In other words — things are worse than we feared.


So without spoiling the excellent brief — which you should go read right now — here’s my conclusion: Don’t just haphazardly deploy multiple layers of defense; thinking that simply stacking technologies somehow makes them more effective. It doesn’t. Architecting a smart, layered security solution (with true Defense-in-Depth potential) means understanding the capabilities of your solutions;  the nature of your network traffic; the types of traffic endpoints, and even use-cases. This is not a game for the novice. The title of “Security Architect” carries tremendous responsibility. And I wonder how many architects of security solutions actually could reach a reasonable level of detection with their Defense in Depth strategies. Makes you wonder, what’s really getting through your defenses?


Maybe there should be a certification for security architects that involves a practical, hands-on exam where you’re asked to build a Defense-in-Depth strategy and then attacks are launched against your setup to see your detection/stop rate … I’m willing to bet the majority of us would fail.


Go grab the NSS report. Read it, think about it, and then rethink how you do defense. The real world is ugly, are you building defensible infrastructures?

MichaelHyatt_(anon) | ‎06-05-2013 03:16 PM

I think the problem is a general failure to differentiate between Prevention and Detection.  You need to deploy sufficient tools to prevent the known attacks and exploits - there's just no option, but it's a stratightforward approach to solving the easy 90% of the problem.  After that comes the hard realization that there can, and likely WILL, be successful attacks that utilize advanced Malware and targeted social engineering that will allow attackers to gain access using legitimate authentication credentials. At that point it becomes a race to identify and stop them before they do serious harm.  


Effective detection requires collection, integration and analysis of all available data sources in real time.  Intelligence is how you complete the security stack.

Matt Presson(anon) | ‎06-05-2013 04:04 PM

I have to agree with Michael. If an organization is going to be effective at stopping breaches, they must get serious about detective controls and monitoring what is going on as it relates to their critical business data. While I am not saying that the NSS Labs report is not useful, I am saying that its conclusion that defense in depth does not work is unfounded given that they were only trying to circumvent preventive controls (which they were obviously able to do).


To be truly effective organizations must move beyond implementing preventive-only controls, and begin focusing on detective controls and monitoring. By having a baseline for your most critical systems of 1) what users should have access to the data, 2) where should they access the data from, and 3) when do they normally access the data an organization then has a (very basic) baseline that they can monitor against for anomalous activity. For instance, if you notice that an application service account is accessing your production system from the user LAN segment instead of the production application server, this should set off alarm bells. This is just one example, but the point is that we, as security professionals, must start focusing on what the "bad guys" are after, and that is the data itself.


No amount of preventive blinky-light boxes will save you. You have to know what is "normal", what is going on, and if those two do not align. THAT is how you shut down breaches.


Screamingbyte(anon) | ‎06-05-2013 05:16 PM

I don't think that Defense In Depth is really so intentional.  After all, if we define a network perimeter and we have core, distro, and access layers in our network, don't the security controls naturally flow with that based on the requirements and, in some sense, form the layers out of necessity?  Is it form following function?  Is it reasoned best-practiced based on the science of how we form computer networks?

We already know that a targeted attack can be very difficult to defend against, which is why we need people who can do threat, traffic, and data analysis and perform audits.  I have to wonder how much of that is lacking due to organizations that may not want to allocate budget for the people and tools, especially if they don't see the value from it.  The most dangerous part of that vicious cycle, is that without these capabilities, organizations may not even realize their security umbrella has been compromised.  I image it is similar to how a home can appear to be perfectly fine, but by the time that you can see the termites eating through the wood, it's too late.  If you can't see them or detect them, you may not realize you need to spray, or see the return value in spraying, until after the damage has already been done.

James_(anon) | ‎06-07-2013 11:11 AM

"Enterprises should focus on the effectiveness of specific combinations of devices at blocking specific
exploits rather than simply layering randomly in the hope that multiple devices equal higher protection."


Sounds like defense in depth to me...

Marco Tietz(anon) | ‎06-13-2013 05:54 PM

I have always looked at 'defense in depth' as more of a philosophical than technical concept. Sure, your technology and fancy applicances help you implement it. But my overall  approach has been to combine different technologies with processes and standards to create DiD. Somehone who simply stacks different tools and claims to have achieved DiD is probably loved by his vendors but I wouldnt call him a security architect ...

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation