Honeypots in the Enterprise - Catching Hackers with Honey(pots)

[#1]

Edited 11/30 10:37pm - It was pointed out to me that the ENISA document is aimed more at CERT organizations than the common enterprise, a fact I didn't catch in my first pass at it, so I updated my post to reflect this, thanks Brian Honan.

There is an interesting article over at H-Online titled "ENISA promotes digital hacker traps" which made me think a bit. The European Network and Information Security Agency is actually endorsing the use of honeypots to detect hacking in and around the perimeter...  this sounds interesting especially since I have a honeypot set up at my home office I sometimes bait out to the Internet but what is the applicability to the enterprise?

Let's take a look at this rationally. First, the document is a comprehensive 183 pages long, which makes it difficult to get through in one sitting ... or at all for that matter for slow readers like myself. A few people pointed out to me that this paper is geared primarily towards the CERT-type organizations... which I missed in my first reading, but my concern for the enterprise use-case persists. What disturbs me after starting to read this document is that it seems to advocate a universal use of honeypots which I think is dangerous for a number of reasons including the obvious legal complications of inviting an attacker in and entrapping them. I can already see some company who can't figure out how to defend itself with the few Information Security resources it has saying "here's an idea to find and stop hackers, let's stand up a honeypot!" without really understanding what this means and the complexities and dangers of doing so. I think the honeypots should be left up to organizations who already understand information security posture and defense well, and who have the great resources to maintain honeypots ... more on the maintain point in a bit.

There are obviously benefits of having a honeypot in place, including the fact that attackers will likely trip over it first, either on accident or because you want them to, and spend some time cracking the honeypot and essentially wasting time. While you want the attacker to go after a non-critical system that you've set out there as bait, let's keep in mind that a good attacker may be silently in that system and now you've given them yet another way into your network. The hopes of 'catching an attacker' in the honeypot is best left to the experts and I unfortunately do not believe, from experience, that there are enough experts out there in the average enterprise to make a honeypot a good idea. I suggest organizations first focus on understanding their threat landscape and defending themselves, and as an advanced measure of defense to then set up a honeypot or a series of them for environmental and situational awareness.

But what if your organization just drops a honeypot in place to 'catch an attacker'? How will you know whether someone has started attacking or is stuck in the trap? Do you have enough resources to not only understand the attacks that could take place, but to also what to do with the attacker to 'stop' them from digging into the rest of your organization? You can't just segment off a honeypot because then it doesn't blend in and loses much of its value, but if a database honeypot is breached and triggers alarms amidst the database cluster - what do you do? These are the dangers of giving attackers some place as an easy target in your organization. This isn't just as simple as dropping a honeypot, I hope that's clear.

If you're going to put in a honeypot, there are a certain few things you must make sure you're doing, or at least have in place already ... here are some simple suggestions:

1. Ensure you've got automated monitoring hyper-tuned on the honeypot through a central intelligence platform such as an SIEM or something more advanced such as a comprehensive operational analytics platform
2. Ensure you've got the right tools in place to give you more than just alerts, but actionable intelligence from the honeypot
3. Ensure you have the resources to investigate Honeypot activity 24x7x365
4. Ensure you're not giving an attacker an easy way into your network or system by putting a honeypot in a strategically poor position (for example, bridging secure/insecure network space)
5. Make sure you tune your honeypot to simulate an actual system in your environment, so it doesn't stick out as an obvious trap

While honeypots may sound like a great way of finding attackers, it often turns into IT Security's new shiny toy that quickly falls to the wayside and create more additional risk to the enterprise. There is no reason that a honeypot has to be present on your network, but if you've got the right resources in place to monitor, maintain and perform action based on intelligence gathered from the honeypot - it could be a very valuable asset.

Check out the full ENISA report titled "Proactive detection of security incidents II - honeypots" for the full release direct from ENISA.

[#2]

I agree that people need to know what they are doing before they consider implementation.  For me, it seems that what we are really trying to mitigate wtih the honeypot is the targeted and sophisticated attack.  If the honeypot isn't believable, it's only going to do one of two things:

1 - Scare them off completely without giving you enough information regarding the attack vector to write new definitions to prevent future attacks against the production network.

2 - Alert them to the fact that it's a honeypot and allow them the chance to then pivot and possibly exploit the production network.

So, it really is a case of being able to pull it off correctly or end up shooting yourself in the foot. 

Also, I just want to add that I really don't think that we can hit on "entrapment" anymore as legal reasons against this.  What it really boils down to is "enticement" which isn't illegal.  If I display a $5,000 watch in my bedroom window and someone breaks in and steals it but gets caught because I had cameras on it, that's enticement and not illegal.  If I did the same, but then went outside and found someone on the street who looked hard up for cash and said, "hey man, I saw an expensive watch sitting in the window there at that house", then that would be entrapment and is quite illegal.

I think the biggest issue we need to consider with the legality of the honeypot is privacy and knowing what specific legal boundaries one will face when capturing traffic from the attacker in an attempt to analyze their behavior and attack vector.

[#3]

Actually, even your second example doesn't constitute entrapment.

"Entrapment" is a defense to a criminal act where there were actions by a government agent to induce the perpetrator to commit the act, and where the perpetrator had no predisposition to commit the crime; it doesn't apply here.

[#4]

Jim,

You are indeed correct, but could this be muddled?  For example, what if a contractor set this up and this organization who did this is also contracted to provide the same service for law enforcement or the DoD?  I think common sense tells us the answer, but we know that often, common sense doesn't always seem to prevail in the legal system.  I'm just stating that I wouldn't take the chance and entrapment really doesn't apply.

But that was in response to the actual discussion of the honeypot.  My personal feelings are that honeypots are generally a waste of time and money anyway.  The problem is that a honeypot should really only benefit a larger organization with a decent sized enterprise infrastructure, and so for the honeypot to be believable, it would need to be more and more complex as the size and complexity of the organization scales, which can be far more of a pain than I would think would be worth it.

So the "sweet spot" where a honeypot might actually be worth it seems to be a moving target where we are examining the cost benefit and value of mitigation.  As others have stated elsewhere, I think there are far more cost efficient and productive things we can do other than to waste time and money on a honeypot that most intelligent targeted attackers will recognize and avoid or exploit anyway.

Good post, Jim, and well stated.