Work Smarter – Not Harder: Use Internal Honeynets to Detect Bad Guys Instead of Just Chasing False Positives

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.

Top three reasons SIEM solutions fail

We have been implementing Security Information and Event Management (SIEM) solutions for more than 10 years. We serve hundreds of active SIEM users and implementations. We have had many awesome, celebratory, cork-popping successes. Unfortunately, we’ve also had our share of sad, tearful, profanity-filled failures. Why? Why do some companies succeed with SIEM while others fail? Here is a secret for you: the product doesn’t matter. The size of the company doesn’t matter. It’s something else. SIEM can deliver great results but it can soak up budget, time and leave you frustrated with the outcome. Here are the (all too) common reasons why SIEM implementations fail.

Reason 1: You don’t have an administrator in charge.

We call this the RUN function. A person in charge of platform administration. A Sys Admin who:

  • Keeps the solution up-to-date with upgrades and new versions
  • Performs system health checks, storage projections and log volume/performance analysis
  • Analyzes changes in log collection for new systems and non-reporting systems
  • Adds and configures users, standardized reports, dashboards and alerts
  • Generates Weekly System Status Report
  • Confirms external/third party integration’s are functioning normally: threat intel feeds, IDS, VAS

Reason 2: The boss isn’t committed.

For the SIEM solution to deliver value, the executive in charge must be fully committed to it, providing emotional, financial and educational support to the administrator. You tell your team that this is the company’s system and everyone’s going to use it. You invest in outside help to get it up and running, and use it the right way with the proper training and service. You don’t cave in when people complain because they don’t like the color of the screen or the font, or that things take extra clicks, or that it’s not “user friendly.” For this system to work, your people will need to do more work. You provide resources to help them, but you stand firm because this is your network. You realize that using this product the right way will help you make your company safer…and more valuable. Stand firm. Commit. Or you will fail.

Reason 3: You’re not using the data.

Our best implementations have 2-3 key objectives satisfied by the SIEM systems each day. Managers read these reports and rely on the data to help them secure their network. Have a few key objectives or you will fail. We call this the WATCH function for obvious reasons.

We are a premier provider of SIEM solutions and services, but with all due respect we would advise against buying a SIEM solution if a client is not prepared to invest in an administrator or reports, or shows little interest in adopting the system into their company culture.