Infiltrated dot Net

Defense in Depth - Fail
Written by Jesus Oquendo   

After, reading an interesting article titled: “Defense in Depth is Necessary, But Not Sufficient” [ISLE] I took a look at the agenda posted by the Networking and Information Technology Research and Development group (NITRD) and I figured, I'd “give it a go” 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 betweens. 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 or to make it more appealing to management, 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:

i="0"

while [ $i -lt 500000 ]

do

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

i=$[$i+1]

done


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 and deception. 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”

2

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

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

5

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

7

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.


[MCAF] http://archives.neohapsis.com/archives/fulldisclosure/2011-03/0312.html
[ONTO] "An Ontological Approach Applied to Information Security and Trust" Artem Vorobiev, Nargiza Bekmamedova
[DECO] http://www.infiltrated.net/index.php?option=com_content&view=article&id=24&Itemid=30
[FAIL] http://www.infiltrated.net/index.php?option=com_content&view=article&id=22&Itemid=28
[ISLE] https://www.infosecisland.com/blogview/12728-Defense-in-Depth-is-Necessary-But-Not-Sufficient.html

 

 

Fail