Defending Your Digital Domain Redux: Take 2

I've written about the idea that 'hacking back' is a bad idea, illegal, and even a little dangerous before. Interesting how topics have a way of re-surfacing from different angles. First, I'll just restart that I'm not an expert on 'cyber warfare' or a lawyer offering legal advice, in fact I'd simply rather not touch that whole angle at all. I'm much more comfortable addressing this issue as it came up today from a more sensible perspective. What follows in this post is an editorial opinion...

WHY does the topic come up?

The topic of "hacking back" or organizations having an offensive posture comes from, I believe, the frustration that many organizations out there feel as they're relentlessly and continually attacked. Playing defense is tiring, even exhausting both mentally and physically. The attackers have such an upper hand that we're left playing defense by finding where they've broken through our defenses, adapting to their attacks, and responding in near-real-time to cut their attack lines. This frustration leads to a mindset where we're easily mentally pushed to believe that it's desirable and even intelligent to go on the offensive. This isn't in reference to any 'cyber war' nonsense talk, but rather to the run-of-the-mill corporate enterprise strategy.

As a strategy for an enterprise, "going on the offensive" is, I believe, small-minded. here's why. With so many difficult factors to consider which I'll discuss in a minute, it's really hard to allocate resources to offensive strategy. Let's take even one more step backwards, first. When thinking about offensive security measures as a means of digital defense, we have to ask ourselves what the return on effort is. What is there to gain? With the precious resources of capital, people, and time all rarely in abundance is your time really best spent attacking your attackers? Even if you believe the right thing to do is find someone else to do the 'dirty work' for you, for example an organization like CrowdStrike, are you really willing to allocate the capital?

Let's look at why I believe it's difficult to take an offensive posture, and gain anything... with the exception of a few corner cases I'll bring up at the very end.

Challenge 1: Who is the 'enemy'?

Today's digital battles are very asymmetric. My friend Will Gragido, who has put his 10k hours into researching adversaries, likes to point out that while it's certainly possible to identify the source of the attack against you, finding the 'attacker' or 'enemy' is extremely difficult and costly. This type of research is also very difficult to do because unlike in the physical world, a digital asset such as a server build and maintained for legitimate purposes, may not actually be the 'attacker', but rather another compromised asset. Let me give you a for example here to make it clear. You're experiencing a menacing attack against one of your systems from IP address 10.1.2.3. With even a light amount of due diligence you find that this machine is also serving up some encrypted traffic between what appears to be financial firms. Legitimately, this machine is a compromised host, performing legitimate financial transactions between banks, but also now being used to attack you. In the absence of finding someone to complain to - you decide to attack it and 'make the attack stop'. In the process, you take down a crucial financial service which is traced to your enterprise... guess where the FBI comes knocking?

Look, attackers don't always use their home computers directly to attack you. The intelligent attacker, which I hope is who we're talking about here, will compromise multiple layers of assets to come after you. They're likely to pop a box (as Dave Kennedy of TrustedSec says), then another, then another, then another until they're far enough away from their 'home' to start launching attacks. When you see an attack coming from China (our favorite country to blame) how do you know it's sponsored by the nation-state, and not your competitor who has compromised a host in China and is using it to attack you? It takes lots of research, often times research we have no access to, to determine attribution correctly. Attackers often hide themselves inside the borders of nation-states that don't cooperate with the United States because that foreign government will likely block your legal attempts to go find the source of the attack, and trace the actual attacker - so you're left making best-guesses. These are not good enough to make a judgment call.

Finally - this whole topic makes little sense to me because as a corporate entity who is the 'enemy' I'm going to go pre-emptively strike at? I fully understand the notion of adaptive defense but to attempt pre-emptive strikes is just silly, period. When do you make the decision to become 'offensive'? When does a port scan turn into an attempted intrusion, turn into a level of attack that you're going to go on the offensive? I believe this is something that would need to be defined within some legal and standards framework somewhere first - and we're ridiculously far away from the maturity it takes as an industry to be ready for that.

Challenge 2: Offensive, so now what?

When I hear people talk about being offensive it's largely all very theoretical. I haven't seen anyone discuss the framework they would use to actually determine source of attack, successfully attribute, identify an attack strategy and execute the task, and then monitor for collateral damage. It's nice theoretically, but who's really willing to do this as a business model, or open their organization/enterprise up to this kind of liability?! I think you'd have to be out of your mind...or have an endless bucket of capital.

Robert Westervelt made an interesting point that attribution and liability are key issues when deciding to 'strike back', with reference to motivations. If you know your data was stolen and is now sitting on a server somewhere, what are the legal and ethical guideposts to help you decide whether you should go get your data back or wipe it as Robert puts it. Obviously in the digital world there is no such thing as 'taking your data back' because everything is just copied from point to point...you never actually lose it unless it was destroyed in the process of exfiltration. Even if you know for certain your data is on that server, are you sure you can safely go destroy it without harming someone else's system (which is presumably the host, since you can't know for sure)? I believe you have an obligation not to cause more damage, in the very least, and since you simply don't know the parameters of this foreign system you can't safely do anything against it.

Wait... step back... how do you even know your data is sitting on that box? Unless it's obvious such as being available for public view, you can't! What about when someone pastes your corporate database to, say, pastebin? Are you seriously going to try and go attack pastebin (you wouldn't since they'd likely take it down, but there are plenty who don't care) or another host like it to try to eradicate your data?! Think of the collateral damage! The minute you attack another system, meaning the second you have to act like an attacker you've now become just that - an attacker - and are subject to the same legal issues. This leads down some uncomfortable rabbitholes, but we largely seem to be ignoring that in public discussions. Is it because 'striking back' is cool?

More realistically - active or adaptive defense

I'd like us as a community to start to talk more about active defense. Active defense, in my opinion, does not involve this 'strike back' nonsense that's being discussed. While I believe we in the enterprise space will always be on the defensive, there are methods we can use to our advantage to make defense more effective, rather than just running from tower to tower repelling attackers scaling the castle wall.

I'd like to have a definition of 'active defense' that encompasses 'adaptive defensive strategies' which means effectively modifying defenses on-the-fly to meet your attacker's offensive moves. Yes, this means you will continue to play the chess game where you're going to be a step behind, and your method of 'winning' is to make the attacker fail, and go away, even if for a short time. If you're being attacked on your web server infrastructure and application-level attacks are the arrow of choice then you can deploy counter-measures such as tarpits, honey-pots and other methods to keep your attacker busy or frustrate them. If your applications are hardened and not susceptible to obvious forms of SQL Injection, yet someone is attempting to SQL Inject your databases... perhaps you could use a method like slowing down their server response time to 60-seconds... that'll serve to slow them down and give you a heads-up to carefully monitor that potential attack. I'm not saying I have all the answers here, just a better one than going shooting arrows into the unknown and potentially creating more damage along the way.

Summarizing...

No, I don't believe in 'hacking back' or 'preemptive hacking' or many of the other methods we're discussing. They're illegal and the potential for causing more collateral damage is too great. Think how you would feel if one of your critical systems was compromised and used in the commission of an attack and then was 'hacked back' and disabled by some other enterprise! You'd likely go after them for creating a disruption of your services (which the stealthy attacker, the real one, likely won't do... keep that in mind).

This is a tricky, messy, and business fraught with pitfalls. Paying someone else to do it doesn't make it better, and doesn't absolve you of your legal and ethical responsibilities. As @DrHaxs summarizes nicely "If the box you disable is used for FDA, FAA, PCI, Etc, that is crime. You are the aggressor."

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.