4

I have lots of links to information on the topic that I've gathered published since the mid-2000s and this SANS document has always been my goto:

http://www.sans.org/reading-room/whitepapers/legal/cyberlaw-101-primer-laws-related-honeypot-deployments-1746

However, I was wondering if there are more recent changes to the laws and/or a site that is more thorough in treatment of how private parties (contractors) factor into any legal issues that might arise from use of a honeypot deployment.

In other words, what are the references that folks experienced with the topic and/or deployment of honeypots rely of for updates and practical legal knowledge?

Ian Bryant
  • 49
  • 5

1 Answers1

4

I'm not sure this question is answerable on this website (however IMHO it remains a good question and I thank you for this document which highlights the legal impact that using a honeypot may have).

In fact, the document you are linking explains that legal rules surrounding honeypots will deeply vary depending:

  • On the exact type of honeypot you setup,
  • The kind of monitoring you use,
  • The type of advertisement you make regarding the honeypot existence,
  • The exact usage you intend for this honeypot.

Due to all these factors, the document acknowledges that such question goes beyond the competences of IT Security engineers and requires the intervention of a specialized lawyer.

Sadly on this site there is mostly IT Security engineers, and very few lawyers...

However, this document has the merit to draw the gray line allowing to distinguish what could be considered safe. Other users may want to contribute to it according to their own experience, but as per my understanding this would be:

  • Do not expect to use any data collected by the honeypot as evidence in a legal affair. These data might be useful for education or statistic purposes, but they will have nearly no legal value when trying to sue a potential attacker. (Such usage remains possible, but will need legal expertise to setup things correctly in advance.)

  • Do not store any illegal content on the honeypot. Storing child pornography (example taken from your linked document) in order to trick people downloading them is a bad idea. It will be useless (see the point above) and you could actually be sued for owning these images in the first place, no matter the goal.

  • Ensure that the honeypot cannot be used as a relay for further attacks. Having a poorly isolated honeypot usable as a source for further attacks against third party systems may also bring you into legal trouble. You are meant to be responsible of the security of your own system. Since the honeypot will most likely deliberately show blatant weaknesses, handling it properly to avoid unexpected side-effects will require a special care.

  • Do not encourage any illegal activity. Do not advertize the honeypot in a dubious way. Either do not advertize it at all, letting automated scanners discovering it, or advertize it officially as some kind of "hackme" educational system. For instance, spreading pseudo "leak" information on the Internet regarding the server to encourage attacker to exploit it can lead you to trouble.

  • Present the honeypot system as a private monitored system. Honeypots are heavily monitored systems, and there are laws defining the data you may or may not collect regarding other people's, how long you are allowed to keep them and what processing you may do with them. Present the honeypot as much as possible (since some service do not have any banner...) as a private system whose usage imply user's consent to be monitored. This will limit any potential threat regarding this data collection and analysis activity.

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • That's what I was afraid of. I'm a GNU/Linux build/release engineer and an opportunity to build a system that is essentially a honeypot came up. However, after researching this specific activity I see more red flags than I'm comfortable dealing with. Perhaps this really is a question for a lawyer with digital crime experience, or it's a response of "no, thanks"... – Ian Bryant May 09 '15 at 17:21
  • I think it remains possible to avoid the "no, thanks" by ensuring that you remain out of the gray zone and that you do not have wrong expectation. I've edited my answer in order to draw this "gray line" as explicitly as possible. Maybe some other members will be willing to share their own experience on the subject, even if this will always remain specific cases not necessarily generalizable. – WhiteWinterWolf May 09 '15 at 20:29
  • I appreciate the edit. I'm drawing a correlation in my assessment between a Tor server project I'm working on (though that project is more passive than active) and some of the points you've made in drawing the gray line. I think I'm almost where I want to be, but I'd be curious to hear other perspectives and perhaps have some other example document links. Thanks, again! – Ian Bryant May 09 '15 at 22:07