• United States



Avoiding the pitfalls of operating a honeypot

Nov 25, 20196 mins

Businesses should think very carefully before moving forward with any honeypot project.

honey jar dripper
Credit: Thinkstock

So, you’ve had enough. You are fed up with hackers and have decided to go “active” in identifying and taking them down. While the sentiment is certainly justifiable in these difficult times, the old adage of “look before you leap” could not apply more than in this context.

Any type of active cyber defense, such as creating and operating a honeypot, can create potential liability and open a business up to action by one or more regulators. At its foundation, the honeypot is designed to mislead and misrepresent its nature to entice a hacker into engaging with it.  To accomplish that, the honeypot must be constructed to appear to be a legitimate entity (e.g., a bank, a consumer products business, etc.).

It’s one thing to do that in the context of a third-party hacker intending to do harm. It is quite another when the third party has no harmful intent, but merely stumbles upon the honeypot thinking it to be a valid website. Even if the third-party is a hacker, deploying active measures like collecting information about the attacker or, worse yet, attempting to place phone-home or other technologies onto the attacker’s own systems may violate applicable privacy laws and may, themselves, result in the operator of the honeypot violating state and federal anti-hacking laws.

While there have been various attempts to enact legislation in support of active cyber defense tactics, such as honeypots, none have yet to become actual laws. The operation of a honeypot is never without inherent risk. These risks can, however, be mitigated to a certain extent by following these guidelines:

Minimize misleading material and data collected    

  • Ensure the domain name for the honeypot and the name of the associated fictitious business are not identical to or confusingly similar to real businesses, which could violate state and federal laws relating to trademarks and business names. This can be done through internet searches and queries to trademark databases.
  • In most instances, the honeypot will have an associated web site designed to depict the target business. As with any web site, ensure you have all rights necessary to display the content on the site (e.g., if there are photos of individuals, appropriate consents and releases should be obtained).
  • Avoid use of terms describing the business that may be the subject of state or federal regulation (e.g., stating the business is a savings and loan company, credit union, or a bank).
  • Include standard terms and conditions on the site, strictly limiting liability and making clear that interactions with the site may be recorded and used for the creation of reports and statistics (i.e., that the visitor interacting with the site has no expectation of privacy with regard to those interactions). Essentially, these terms are used to obtain “consent” from the hacker to track their movements and actions. The effectiveness of such a consent in this context has yet to be validated by any court, but, at least, it provides a potential defense in the event the hacker brings a claim against you.
  • Include a privacy policy, as required by some states, specifically tailored to permit broad uses of data collected about visitors to the site. Again, these terms are intended to serve as “consent,” but, as noted above, this approach has not been validated by any court.
  • Construct the site such that an innocent visitor is not prompted to reveal personally identifiable information (other than the IP address from which they are communicating) or misled to their detriment (e.g., provided information that they may act upon and incur a loss). Sites that are purely “brochureware” are the least likely to create liability. While those permitting extensive interactions (e.g., completion of site registration and other activities), have higher likelihood of liability.
  • With regard to data collected about a hacker’s activities on the site, never disseminate personally identifiable information to any third party, other than law enforcement. Uses of aggregated or de-identified data are described below.
  • Bear in mind that, while remote, a hacker could, theoretically, sue for fraud and other causes of action as a result of being misled as to the content and purpose of the site.

Don’t become a hacker yourself

Operators of honeypots sometimes desire to trick the hacker into downloading phone-home and other technologies for purposes of identifying the hacker and/or better tracking their movements. Understand that downloading programming and other technology onto someone’s systems or attempting to access their systems without their knowledge or consent almost certainly violates state and federal anti-hacking laws (e.g., the federal Computer Fraud and Abuse Act) – even if done in the context of cyber security. Penalties for these activities can be substantial and harsh. Never engage in such activities without the involvement and direction of law enforcement.

Don’t violate privacy/electronic communication laws

As noted above, be very careful about the information collected in connection with the honeypot. Privacy laws, particularly the General Data Protection Regulation (GDPR) and federal Electronic Communications Privacy Act (ECPA), have very broad application and extend to IP addresses and, even, business contact information. Using this information may be strictly limited and present the potential for enforcement actions and liability. Except for interactions with law enforcement, uses of personally identifiable information should be strictly avoided. Only aggregated or de-identified information should be used, particularly in the context of any published reports or statistics regarding operation of the honeypot.


The law regarding entrapment is complicated, but if someone creates a situation intended solely to snare a wrongdoer, there is the potential for an argument this constitutes entrapment. In such a case, law enforcement may decline to take action on information gained from the honeypot.

While most businesses create honeypots for the very beneficial reason of identifying and, potentially, having hackers prosecuted. There are very real dangers in doing so. The business may open itself up to potential claims from the hacker, subject itself to regulatory action, or, even, find itself prosecuted for hacking. Think carefully before moving forward with any honeypot project. Involve legal counsel and, potentially, consult with law enforcement.


Michael R. Overly is a partner and intellectual property lawyer with Foley & Lardner LLP where he focuses on drafting and negotiating technology related agreements, software licenses, hardware acquisition, development, disaster recovery, outsourcing agreements, information security agreements, e-commerce agreements, and technology use policies. He counsels clients in the areas of technology acquisition, information security, electronic commerce, and on-line law.

Mr. Overly is a member of the Technology Transactions & Outsourcing and Privacy, Security & Information Management Practices. Mr. Overly is one of the few practicing lawyers who has satisfied the rigorous requirements necessary to obtain the Certified Information System Auditor (CISA), Certified Information Privacy Professional (CIPP), Certified Information Systems Security Professional (CISSP), Information Systems Security Management Professional (ISSMP), Certified Risk and Information System Controls (CRISC) and Certified Outsourcing Professional (COP) certifications.

The opinions expressed in this blog are those of Michael R. Overly and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author