Log collection, SIEM and security monitoring are the journey not the destination.  Unfortunately, the destination is often a false positive.  This is because we’ve gotten very good at collecting logs and other information from production systems, then filtering that data and presenting it on a dashboard.  But we haven’t gotten that good at distinguishing events triggered by bad guys from those triggered by normal everyday activity.

A honeynet changes that completely.

At the risk of perpetuating a bad analogy, I’m going to refer to the signal-to-noise ratio often thrown around when you talk about security monitoring.  If you like that noise/signal concept then the difference is like putting an egg timer in the middle of Times Square at rush hour.  Trying to hear it is like trying to pick out bad guy activity in logs collected from production systems.  Now put that egg timer in a quiet room.  That’s the sound of a bad guy hitting an internal honeynet.

Honeynets on your internal network are normally very quiet.  The only legitimate stuff that’s going to hit them are things like vulnerability scanners, network mapping tools and… what else?  What else on your network routinely goes out and touches IP addresses that it’s not specifically configured to communicate with?

So you either configure those few scanners to skip your honeynet IP ranges, or else you leverage them as positive confirmation that your honeynet is working and reporting when it’s touched.  You just de-prioritize that expected traffic to an “honorable mention” pane on your dashboard.

On the other hand, (unless someone foolishly publishes it) the bad guy isn’t going to know the existence of your honeynet or its coordinates.  So as he routinely scans your network, he’s inevitably going to trip over your honeynet — if you’ve done it right.  But let’s talk about some of these points.

First, how would a bad guy find out about your honeynet?

• Once he gets control of IT admin user accounts and reads their email, has access to your network and security documentation, etc. But if you have good privileged access controls this should be fairly late stage.  Honeynets are intended to catch intrusions at early to mid-stage.
• By lurking on support forums and searching the Internet (e.g. Stackoverflow, honeynet vendor support sites). It goes without saying — don’t reveal your name, company or company email address in your postings.
• By scanning your network. It’s pretty easy to identity honeynets when you come across them – especially low-interaction honeynets, which are most common.  But guess what?  Who cares?  They’ve already set off the alarm.  So this one doesn’t count.

So, honeynets are definitely a matter of security through obscurity.  But you know what?  We rely on security through obscurity a lot more than we think.  Encryption keys are fundamentally security through obscurity.  Just really, really, really, good obscurity.  And security through obscurity is only a problem when you are relying on it as a preventive control – like using a “secret” port number instead of requiring an authenticated connection.  Honeynets are detective controls.

But what if you are up against not just a persistent threat actor but a patient, professional and cautious one who assumes you have a honeynet and you’re listening to it?  He’s going to tiptoe around much more carefully.  If I were him, I would only touch systems out there that I had reason to believe were legitimate production servers.  Where would I collect such information?  Places like DNS, browser history, netstat output, links on intranet pages and so on.

At this time, most attackers aren’t bothering to do that.  It really slows them down and they know it just isn’t necessary in most environments.  But this is a constant arms race, so it’s good to think about the future.  First, a bad guy who assumes you have a honeynet is a good thing because of what I just mentioned.  It slows them down, giving more time for your other layers of defense to do their job.

But are there ways you to optimize your honeynet implementation for catching the honeynet-conscious, patient attacker?   One thing you can do is go through the extra effort and coordination with your network team to reserve more and smaller sub-ranges of IP addresses for your honeynet so that it’s widely and granularly dispersed throughout address space.  This makes it harder to make a move without hitting your honeynet, and further reduces the assumption that attackers usually find it safe to make — that all your servers are in range for static addresses, workstations in another discreet range for DHCP, and then another big block devoted to your honeynet.

The bottom line though is honeynets are awesome.  You get very high detection with a comparatively small investment.  Checkout my recent webinar on Honeynets sponsored by EventTracker, who now offers Honeynet-as-a-Service that is fully integrated with your SIEM.  Deploying a honeynet and keeping it running is one thing, but integrating it with your SIEM is another.  EventTracker nails both.