Why Defense in Depth Will Never Be Sufficient

Wednesday, March 30, 2011

J. Oquendo


After, reading an interesting article titled: Defense in Depth is Necessary, But Not Sufficient [ISLE], I took a look at the agenda and I figured, I'd “give it a go” in answering some of the questions posted, from the engineering slash technical side.

The purpose was to point out the flawed methods of relying on Defense in Depth. This is not to say DiD fails, it is meant as an eye opener slash wake up call to those tooting the “DiD is the way to go” horn.

How do we measure the differential costs accrued by the attacker and the defender when implementing Defense-in-Depth?

Security metrics is a bit of a voodoo topic from my perspective. Defenders focused on “what does it cost an attacker” will spend time and money on a pointless question. One of the reasons this is a pointless questions is because you can never (repeat this with me, never) measure how many attackers are actively targeting you. The safest and most secure method of approaching this is to assume that you HAVE been compromised. What now?

With someone inside of your network, what are your primary objectives? Focus on defending those objectives. For example, if on an application server that sends data from point A to point B, you are better equipped and funded to configure that connection properly. Ensure that point A can ONLY talk to point B and point B can ONLY talk to point A. There should be no in between.

The costs associated with doing this is far lower than the costs of purchases towards equipment that will watch this, send alerts, throw up blinking lights on an SIEM. It is all in the design. You cannot protect against that which you cannot see. However, you can open your eyes and take caution against the steps you take.

Defense in depth is a great approach at defending from the outside in but far too many professionals and scholars are so entrenched on getting this right while attackers are effectively and increasingly “punching holes” on the way out. To that tune, Defense in Depth is not going to solve the compromise issue. To make it appealing, the “advanced persistent” issues.

It is a given that a sole attacker has a set limit of resources. Time, amount of machines capable of launching attacks. The reality is that if your infrastructure is targeted, it will be targeted by multiple attackers who collectively have an unlimited amount of resources. It can be thousands of attackers for every “worker” you have in the end bankrupting your resources. Not a practical approach.

To put this into greater more logical perspective, here is a pseudo-code explanation:


while [ $i -lt 500000 ]


hping --rand-source -c 10 -i 10 -s 80 -f -U --scan you.as.the.target



With this code I am sending you data from what you think is port 80 from a completely random source.

Why would I do this? Simple, obfuscation. There is a high likelihood this will trigger an event in either your firewall, IPS, IDS, SIEM or whatever other security mechanism you have in place. While you are focused on figuring out what is occurring, I am now a needle in the haystack.

What have you accomplished other than wasting your time? To make it more believable I can randomize incoming ports, I can select known “dirty hosts” and send you data as them. For purposes of deception, I can choose an enemy country which will lead you to believe you are under attack from the “enemy.” 

What has defense in depth accomplished here? My sole purpose was to create a cover and your defense in depth fails. Total cost to me as an attacker, nothing, total cost to you would be the resources you spend chasing this ghost of mine.

Resources include not only the cost of an individuals performing some form of incident response and analysis, it also includes the processing costs from your equipment. Something has to handle this information as it comes in. At some point in time, your defenses are wasting time. On the other hand, configuring your defenses to perform offensive actions are a better option. “Offense, you can't expect me to attack, that is absurd!”

Let me define an offense. As stated before, Point A should ONLY connect to Point B. Any event that strays from this norm should trigger an offensive action. Obviously you do not want to aim at a ghost. Does this stop you from taking offensive action on your own machine? “But I would never take an offensive approach on my own network!!!” Imagine the following pseudo-code now:

1 trust=`printf “pointA\npointB”


3 tcpdump -c 20 | awk '{print $3}' > points

4 tcpdump -c 20 | awk '{print $5}' >> points


6 grep -v "$pointA\|$pointB" points |\


8 sed 's:^:firewall block :g' | sh

In the first line we define the two hosts, pointA and pointB. We then tell the machine in three and four “go take a look at all the traffic coming to and from you.” In line six we tell the machine: “now that you see all the traffic, ignore those trusted hosts we defined” and in line 8 we tell the machine to block all traffic as we stated before: “pointA to pointB”

Something simple can be triggered as an OFFENSE from an IPS where if we see an anomaly, we are not trying to fight thousands perhaps millions of attackers. We are focused on making sure data never leaves those two machines to any other host but themselves. From the defensive posture, an engineer would have to create so many complex rules blocking attackers on the way in. Attackers whom we are not sure even exist.

This is not to say that Defense in Depth is not worth implementing it is simply to state “Defense in Depth” is not all it is cracked up to be.

How do we shift the differential costs from the attacker to the defender?

Attempting to try to shift any cost to an attacker means that you are assuming an attacker is forking out any financial costs. To understand why this would fail, we could look at the current disclosure of vulnerabilities found on McAfee's [MCAF] website by a researcher. Those vulnerabilities were passed on to others freely. Any costs associated with reconnaissance are now lowered for an attacker.

How do we measure the value add of additional mechanisms in terms of confidence in the Defense-in-Depth strategy?

Personally, I have my doubts against the reliability of most security metrics that are coming “into the house.” Those metrics – both qualitative and quantitative - are a constant hot topic for security managers even though those metrics have both been failing miserably throughout the years. Security managers sure love to twiddle with failed concepts: “The pure quantitative analysis is not possible because some aspects of information security cannot be quantified in money figures.” [ONTO]

Rather than watching how much bandwidth comes IN to your network – something you cannot control – why not shift the focus on watching what is LEAVING your network. For example, using pointA to pointB again, we can build a baseline that states: “Look throughout the course of the week, these two sites ONLY transfer 100Mb between each other. I need to see if this changes, if so, I need a real time alert as this is not normal.” Makes more sense to control what you CAN control versus the garbage traversing via the Internet.

How can we develop Defense-in-Depth mechanisms that take into account the Adversarial Threat Model?

Would this not be a waste of time? I have explained not only in this writing, but in others [DECO] as well that it is a waste of time to try and model an attacker. You are chasing a ghost.

How do we defend against a determined adversary by using Defense-in-Depth?

This has been answered above and in other documents. “You're doing it wrong” [FAIL] One can never pinpoint an adversary because unlike in typical fashion, you will not see your enemy/adversary. In law enforcement agencies, agents are trained in how to spot a potential criminal. By his looks, his actions and so on. This does not exist via computer connections. To prove this point, let's imagine the following scenario:

John Smith works at Foobar Secure Company and has a laptop which allows him to VPN into Foobar's network. John is a trusted source. John's laptop somehow was compromised, either via malware, virus or other. Using John's machine, an attacker can now access data in Foobar's network. Who is the enemy here? Obviously it is not John, but in this instance it IS John.

Because John is a trusted employee, there is no “Defense in Depth” aimed towards him. Do you see the problem here?

What new avenues for attack are introduced by implementing additional mechanisms to Defense-in-Depth?

The same avenues of attack will continue. Client side attacks will continue to target victims and Defense in Depth will do nothing to deter or minimize this. DiD is akin to building a higher wall to keep people from climbing over in order to “enter the castle.

The issue is, attackers are being strolled right into those castles because they are hiding inside of the trenchcoat of trusted users. Worry about what people are LEAVING the building with. Remember, most attackers are trying to get OUT of the building with something worthy.

Can adversaries create an Offense-in-Depth to counter our Defense-in-Depth?

They have done so all along, it even has a label: “Client Side Attack” Once inside of an infrastructure, an attacker has free reign to do whatever they would like to do. Because the foundation is flawed, the house will come crumbling down.



Possibly Related Articles:
Methodologies SIEM Network Security Defense in Depth hackers IDS/IPS
Post Rating I Like this!
David Batz Thank you for this provocative and insightful article. It does speak to the need to fundamentally change the conventional mindset of firewalls and DMZs to an even more challenging recognition that the enemy is already within the castle.
Lucian Andrei Uau! Very interesting article!
Unfortunatelly changing mentalities is one of the hardest thing to do. I am trying to do this with my managers, and I think I'll quit.
What do you think that someone has to do in order to change mentalities about security??
J. Oquendo Compromise them! ... Kidding. The easiest way to get managers to understand is to be upfront and explain it to them. Explain it in a way that makes sense to them. Financially ;)

You have to understand where I am coming from when I write, I am coming from the engineering, technical, mini-manager side of the scope. While I see the harsh reality of things because I am "in the trenches," my managers see dollars and sense. When I speak to them I offer the true costs of getting it wrong.

I also tend to be very outspoken and have an ability to make analogies to tough technical concepts and terms. Once I get past the "aha! NOW I GET IT," most of the times I am allowed to do what I need to do to defend an infrastructure.

I thought about this over and over this year, "why are people following such bad practice" and it boils down to the herding instinct all the time. "One animal moves one way, another sees it decides to follow, all of the sudden all the animals (in a herd) are moving the same direction." My point of view on the herd? Simple... Most herds end up as hamburger meat ;) No thanks I won't be following the rest to the slaughter.
Lucian Andrei Thank you J.

You are right, but in order to present it to the right people I would have to jump one level. Should I do it?

You are not the only one that sais that if a company has some juicy data, the bad guys are already inside.
Unfortunatelly most people don't believe it: "the data is in the internal network", "we have firewalls", "we never have been hacked, so why do you want me believe that we will be now". How do you deal with this kind of people when they are the ones that should tell you what to do.

Thanks again, and I really like your articles.
Robb Reck Thanks for the great follow up.

I think the issue with Defense in Depth is not the philosophy (which really isn't much of a philosophy at all), it's the way we've gone around hoping from one "latest and greatest" technology to another. We implement too many technologies, and we don't implement them well enough. Organizations need to simplify their security layers. Declutter!

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.