Hack back is a bad idea

On almost an annual basis we see policy proposing the authorization of private-sector hack back, the latest of which has been legislation from two US senators. One of the main issues with policy proposals for hack back is that they rarely address how it would work in reality and how opportunities for abuse or unintended harm would be handled.

To address this, Senators Daines and Whitehouse have proposed that the US Department of Homeland Security (DHS) "conducts a study on the potential benefits and risks of amending section 1030 of title 18, United States Code (commonly known as the 'Computer Fraud and Abuse Act') to allow private entities to take proportional actions in response to an unlawful network breach, subject to oversight and regulation by a designated Federal agency."

While I acknowledge that this legislation is attempting to examine how hack back could work in practice, the bill includes a bias towards making it work, and I believe that is fundamentally a bad idea.

I believe it’s not practical to provide sufficient oversight or accountability to make private sector hack back viable without negative consequences, and the very fact that we’re discussing the possibility of private sector hack back once again is extremely troubling.

What is hack back?

Hack back refers to non-government organizations independently taking intrusive action against a cyber attacker on technical assets or systems not owned or leased by the person taking action or their client. It is generally illegal in countries that have anti-hacking laws.

But unfortunately, hack back is appealing. Organizations are subject to frequent and costly attacks and many cybercriminals have no fear of punishment or prosecution due to safe-haven nations that either can’t or won’t crack down on their pursuits.

It’s easy to see why some businesses want to be able to take the fight back to their attackers and create a more level playing field. There are a number of justifications made for hack back, including organizations getting a better understanding of the nature of the attacks, neutralizing threats, making themselves less appealing as a target, or recapturing lost data. But empathizing with these arguments does not make the idea of hack back any more workable.

The wealth of reasons why hack back is a bad idea

Hack back can be likened to homeowners defending their property against criminals breaking in, arming themselves and standing bravely in defense. However, the reality is more akin to spraying bullets and hoping to hit the intruder, and even if you do manage to reach your attacker, you’re additionally risking terrible collateral damage. The problem is, the internet doesn’t operate in clearly or neatly defined boundaries.

Firstly, attribution is hard. In many cases, it’s essentially impossible to know for certain that we’ve accurately attributed an attack. Red herrings can be intentionally planted by the attacker to purposefully incriminate another party or move suspicion from themselves. In the digital world, pretty much anything can be spoofed or disguised with enough skill, resources, time and patience, and attackers are constantly evolving their techniques.

Secondly, attackers often leverage previously-compromised third party systems. Hack back activity aimed at an attacker is just as likely to impact these already-victimized third parties. Or a researcher conducting legitimate scans to advance our understanding of the attack landscape could be mistaken for an attacker and suffer unexpected repercussions. 

Then there is the question of liability and cost. Imagine a high-value organization such as a bank, that could partake in 100 hack backs per year and twice make an error -- a 2 percent fail rate might not sound too bad, but in this context would mean the compromise of another company or group of individuals. Where would the liability lie in this scenario? Would the bank have to pay out? Or if liability is waived, how would we then discourage intentional or careless abuses of hack back?

In all, the potential negative consequences of a hack back gone wrong could be far-reaching, catastrophic and costly, including expensive legal proceedings, reputational damage, and loss of trust. Hack back can lead to disruption to operations, damage to systems, or loss of data. In some cases, hack back could even create diplomatic implications. This should both concern lawmakers and disincentivize participation in hack back.

The difficulty of providing appropriate oversight

Previous proposals to legalize hack back have been too broad and vague as to the management and oversight required to avoid unintended harms. If we look at the Daines and Whitehouse bill, this alludes to a framework for oversight that would decide "which entities would be allowed to take such actions and under what circumstances." This suggests an approach commonly advocated by champions of hack back where special permission is granted to vetted and approved entities to take action.

However, creating a framework and system for such oversight is highly impractical and costly. The government would need to determine who would run the system and how it would be funded, as well as identify a path to address complex issues surrounding accountability and oversight to avoid exploitation.

Where would lines be drawn? Who would be authorizing the approved organizations to ensure standards are met and maintained? An authorizing agent can’t have eyes everywhere and, so it would be highly impractical to create a system for oversight that would enable the governing authority to spot and stop accidental or intentional abuses of the system in real time.

The complexity of legal liability and inequality

Another issue is that of who is responsible and liable if something goes wrong. When national governments take an action such as hack back, it tends to occur within existing international legal frameworks and under some oversight mechanism, but the same restraints and accountability may not apply in the private sector, raising concern of where liability rests.

In the case of a company hacking back and accidentally harming another organization or individual, the entity that undertook the hacking can become embroiled in complicated and expensive multi-jurisdiction legal action, even if the company has a license to hack back. While hack back undertaken by an organization or individual on behalf of a third party could mean both incur negative consequences.

The inequality of participation

There’s also the problem of participation. In the event that a viable system is developed, and hack back is authorized then participation will likely be costly and require specialist skills.

An authorization framework must be stringent, or organizations might try to participate with insufficient expertise that could lead to damaging consequences. At the same time, many organisations are already vulnerable and sit below the "cybersecurity poverty line" without enough resources or technology to protect them. This could lead to a spiral where the cybersecurity fortunate hack back and make the cost of attacking them higher, so the more vulnerable will get hit harder.

The path forward

Rather than authorizing a measure as fraught with risk as hack back, we should instead be thinking about how to better protect vulnerable organizations -- for example, by subsidizing or incentivizing better security hygiene. User awareness training, reducing an organization's attack exposure, managing supply chain risk, patching, and identity and access management (IAM) all build robust cybersecurity defenses and are crucial to implement. We should also be looking to technology providers to build more security and less vulnerability into their offerings as a baseline, rather than making their customers perpetually responsible for mitigating risk introduced into their environments through adoption of these technologies.

As organizations strive to find new ways to repel attacks the hack back debate will only continue. Any policy regarding hack back needs to thoroughly consider all these concerns. While we understand and sympathize with the desire to do more, take more control, and fight back against cybercrime, we urge policymakers to be mindful of the potential for catastrophe.

Photo Credit: napocska/Shutterstock

Jen Ellis is VP community and public affairs at Rapid7

3 Responses to Hack back is a bad idea

© 1998-2024 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.