Log collection, SIEM and security monitoring are the journey
not the destination. Unfortunately, the
destination is usually a false positive. This is because we’ve gotten very good at collecting logs and other
information from production systems, 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 every day 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 time square at rush hour. Trying to hear it is like trying to pickout 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 for 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 users 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 honey nets 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 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 to the extra
effort and coordination with your network team to reserve more and smaller
sub-ranges of IP addresses for your honeynet so that its widely and granularly
dispersed throughout address space. This
makes it harder to make a move without hitting your honey net and further
reduces the assumptions that attackers usually find it safe to make such as
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
comparatively small investment. Checkout
my recent webinar on Honeynets sponsored by EventTracker who now offers a
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.
“This article by Randy Smith was originally published by EventTracker” https://www.eventtracker.com/newsletters/internal-honeynet/