Consider this: You are the CEO of a company that has been persistently attacked by hackers. You’ve suffered damage, denial of service, loss of intellectual property, and more. Despite numerous attempts to identify and clean up malware and vulnerabilities, the hackers continue to attack. You decide something must be done. Your company cannot continue to suffer this loss and damage. You want to locate the hackers, if possible, but at a minimum you want to stop or block the attacks and try to recover stolen property. You hire a team of experts who describe the process to accomplish your goals. One of the most important steps in the process is intelligence collection. Deployment of a honeypot is one technique to begin this process and it may allow you to learn more about your attackers, their tools, and techniques. Deployment will need to be well thought-out since the attackers are likely already familiar with your network.
Very little has been written about honeypot legal issues and most of it is outdated. The most commonly addressed issues usually include entrapment and privacy. Entrapment applies primarily to law enforcement and government activity, which is not applicable to this scenario. As for privacy, I would argue that if a hacker breaks into your honeypot, he has given up any right or claim of privacy. Realistically what hacker would sue a company claiming that he broke into their network and they violated his privacy? This is not to say that privacy should be completely dismissed, and employing banners warning all that use of the network constitutes consent to monitoring may not be a bad idea.
This leaves us with the issue of perceived negligence and your level of liability if your honeypot is used for nefarious activities. You deploy a honeypot, which is breached as anticipated; it is then used to launch an attack against another company. You could potentially be sued under the theory that the honeypot was not properly secured and your actions or inaction therefore caused or allowed the breach. I use the term “perceived” because currently no clear standard exists for securing networks. As long as a company has implemented basic security, trying to prove that they were negligent in securing their network and that that negligence was the proximate cause of them being breached and then their server(s) being used to attack another company, would be difficult at best.
When deploying the honeypot, as mentioned above, a plan must be meticulously developed. You will need to convince the hackers, who have been in your network for a while, that the honeypot is a legitimate part of the network. Then, to address the perceived negligence, you want to ensure your honeypot will not be used to attack another company and/or that your honeypot is not being used as storage by the hackers. Hackers typically use compromised networks to store their ill-gotten gains.
Remember, the point of the honeypot is intelligence collection so you can identify and/or block or stop the hackers. If you are not careful, you may create a worse scenario in which you become a tool used by the hackers to attack others. You must be meticulous about watching all actions and activities you engage in to gather information. Protect against your honeypot being used for activity you do not condone. In the beginning I mentioned a team of experts. If you plan on engaging in hackback, you need people who understand the risks and issues, especially the legal issues.
Related Courses
Legal Issues in Information Security
Certified Ethical Hacker v8
EC-Council Certified Security Analyst (ECSA) v8