A Better Defense in Depth Implementation

Wednesday, April 13, 2011

Robb Reck

C787d4daae33f0e155e00c614f07b0ee

For previous posts on defense in depth click here and here.

There’s been a lot of conversation lately around how effective our current implementations of defense in depth (DiD) are. There have even been some suggestions that DiD is a broken model, and needs to be replaced. But I believe in the value of DiD. It is essential to an effective security program.

Defense in depth is required, and can be used to create an effective security program that meets your organizational needs. But it can only do so if the layers are implemented carefully and appropriately to the environment. In order to receive optimal return on investment we should (1) identify which areas contain our most sensitive information and implement security measures appropriately, we must (2) design security measures that are independent of one another, so that when one fails others continue to work, and (3) ensure that we’re able to react to threats even if they successfully breach our defenses and disable our systems.

1. Be more precise. In many organizations when a security measure it applied, it is implemented across all areas. In our flat network environments it’s much easier for us to just go with the “secure everything” philosophy. But by painting with such a wide brush we cause ourselves some significant long-term issues. Optimally, we have network segmentation and can properly assign risk to each area. For those organizations who are subject to PCI-DSS, we already live in this type of a world.

By not applying defenses with more precision, we drive the price of our implementations way up. Instead of being able to purchase only the seats/volume/servers that we need to mitigate the actual risk, we are paying the additional costs to apply the defense throughout the entire enterprise. This can extend the time to receive our return on investment (or even worse, eliminate the ROI altogether). The money and time spent implementing a solution in those areas which do not need it comes at the opportunity cost of the next item on our project list.

Resources are always scarce, and by better segmenting our defenses to only the scope required, we can protect our resources, and ensure we are applying them appropriately. In the short term, we invest more time in figuring out the real scope of the defenses needed, but in the long term we save on licensing, administration and hardware costs.

2. In an effective DiD implementation different layers have unique failure modes. That means that it should not be possible to defeat multiple layers of defenses with one single attack. This is an especially big concern if the countermeasures are similar in technology, or offered as a part of an all-in-one solution.

It should not be possible to defeat multiple layers of defenses with one single attack

As an example, consider web application security. We have an IPS system, a firewall and a web application firewall (WAF) protecting the end application. At first glance these three levels will satisfy or even exceed most definitions and requirements for DiD. But if the organization implemented all three of these technologies as a part of one unified solution, all three of them are susceptible to a single attack. With all three sitting on one hardware device, if an adversary is able to gain access to that one device either, physically or logically, he can disable all three defensive measures simultaneously.

The most effective DiD will require that these systems have no interdependencies, so that when one fails we can count on the others to continue protecting. By ensuring that their failure modes are unique we not only continue to receive partial protection if one of the measures is defeated, we also should get notified and have time to work on fixing the dysfunctional system before all layers are breached.

Supporting systems such as power supplies, internet connections or cooling units should be taken into consideration as well. If all your layers of defense are on the same generator or battery backup they may all be vulnerable to the same single event. Instead we should implement wholly separate support systems as often as possible.

3. As the defenders we have the ability to deal with threats at four increasingly severe levels. Prevent > Detect > Mitigate > Recover

Preventing an attack keeps our systems clean. Detection allows us to defeat an attack when we’ve been exploited, but are still completely functional. Mitigation occurs when our systems have had functionality reduced, but are still operational. Recovery is the last step, and takes place when systems are completely knocked out.

An effective DiD model will not only contain multiple defenses to protect the network, but will include strategies for reacting to attacks at each of these levels. The program should include appropriate preventative safeguards, monitoring systems to let us know when our preventions have failed, and finally should have tools to restore functionality within an acceptable timeframe if a system is partially or completely incapacitated.

Conclusion

As malicious actors have proven time and time again, our current security programs are insufficient to provide adequate protection. Defense in depth has come under fire as a result. But it’s not the DiD model that has failed us, it’s our own incomplete implementations. The good news is we can do better. Now it’s up to us to start doing so.

Cross-posted from Enterprise InfoSec Blog from Robb Reck.

Possibly Related Articles:
12906
Network->General
Information Security
PCI DSS ROI Defense in Depth IDS/IPS Implementation Layered Defense
Post Rating I Like this!
1789975b05c7c71e14278df690cabf26
Pete Herzog Glad to see you write this! I recommend you take a look at OSSTMM 3 which demonstrates this idea as well. The problem with DiD, as you mention, is that it is not specific. How deep? Which controls? Where? All this is answered in the OSSTMM. For example, as the IPS, WAF, and FW DiD config you mention, would have also failed according to OSSTMM 3 because it's 3 Authentication controls protecting the web server. That means that a threat that defeats authentication will defeat all 3. And many many things can trump authentication since it's based on identification and authorization to be effective. OSSTMM 3 promotes DiW (Width) which states that there should be at least 2 or more DIFFERENT operational controls (of 10 types suggested) which also assures they fail differently and separately to continue protection should 1 be bypassed. Further discretion can be made by vector, trust metric, and other channels which make the attack surface. That assures the money is put in the right places to secure the right things. Do this right and you'll score a high rav which shows you've minimized your attack surface. Now if we can just get compliance to demand a set attack surface value instead of the number of products one has.
1302778677
27ef2e87221c355f517e2824b19f7ca6
Jared Carstensen Great post Robb - well written, structured and concise! A perfect "how to guide" for anyone implementing DiD.
1302779346
C787d4daae33f0e155e00c614f07b0ee
Robb Reck Thank you both for your feedback. Pete, the point you make about width is well received.
1302794198
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked