exotic liability 70 on honeypots

I have made my opinions on honeypots known, and while I think they’re fun and useful to those who have the time or focus on analyzing attackers and their tools (I can’t stress enough that there *are* orgs that *should* be using honeypots [like F-Secure!]), they’re just not useful to most organizations (in fact, almost all, if you ask me).

So I was a little skeptical when listening to Exotic Liability #70 and Lenny Zeltser came on and the topic of his recent blog post about honeypots came up (skip to 56:30). Chris Nickerson gave excellent reasons against bothering with honeypots. That could have been me talking, almost word for word. Researchers love honeypots, but that’s part of the problem where researchers sometimes just don’t get what really gives value to an organization *right now* in their security posture when they have limited resources (not grants or research funding).

But Lenny made one interesting observation about giving your talented staff a honeypot to play with otherwise they may get bored and quit the organization for somewhere more exciting. I think that’s an interesting point, but probably not one that will matter too much. First, not many orgs have honeypots, so it’s not like a lack of a honeypot to play with is something that a staff member can go to another org that has them. Second, if sec staff is bored, something is wrong. I can’t imagine that any real security pro is ever bored. Frustrated and disheartened, yes. But truly bored? Never. Truly, never.

Lenny’s article makes a bit more sense when you dismiss the idea of putting honeypots out on the public internet, which Lizzie helped expose in the interview. Then you’re really just using honeypots as another internal tripwire (or for those with the time and talent, a way to examine attacks). Honestly, I’d still suggest putting more of other tripwires in the environment. Just like Chris says, I can’t think of any situation where I would ever suggest a company try out a honeypot in their environment. There are far, far, far too many other things that can be done.

(In economics, this is called opportunity cost.)

Next, Lenny’s article mentioned that really honeypots are just for mature security programs. But how many executives and even middle managers will *think* they have a mature security program? Then hear about honeypots and how infosec researchers said honeypots are useful, then made that a new project or outright purchase? I really don’t think anyone should think about honeypots until outside infosec professionals “certify” their programs as mature *and* they have some vested reason to analyze attackers and their tools (i.e. you research and then sell security). It’s important to make sure that an outside entity labels you as “mature.”

Lenny also mentioned the idea that an IPS could, instead of just preventing the attack, to actually pretend that the attack will work and entice more interaction with the attacker. This is also interesting, but really does break down once you analyze it with any experience in security teams in real organizations. First, the level of sophistication in that IPS/IDS or whatever tool would have to be huge in order to entice anything except very specific scripted events. Second, why bother? I would rather my IDS/IPS present me with packet captures on what it alarms on, and not bother with enticing those attacks and giving me even more captures. And so on…it’s an interesting idea, but way too sophisticated for any of these companies or boxes that try to be “turnkey” or automated. This still all comes back down to talented staff, as usual, anyway.