It might seem like a strange question, but I wonder how many readers are running a honeypot network in their infrastructure? If you’re not then let me be the first to say that you really should.

This could be a slightly controversial view as, all too often, honeypots are misunderstood and mistrusted. People across the IT security space are very good at raising concerns about why they shouldn’t be used and why they’re not a good idea, but I really couldn’t disagree more I’m afraid! I firmly believe that honeypots have a key role to play in any organization’s security arsenal.

Let’s start at the beginning, what is a honeypot? Put simply, it is a machine that is designed to tempt any unknowing attacker to target it, whilst being configured to trace the origins of the attacker and identify them. However, this can lead to the perception that honeypots can be a quagmire of risk and liability, as well as raising understandable concerns about willingly allowing an attacker to access your system under your control.

However, there are many forms of honeypots, and they can be used in many different ways. The idea of the honeypot as merely a host designed to be breached; sitting on the perimeter of your network is far from the whole picture. Let's take a look over some different uses of honeypot style systems and consider their place in a well-equipped enterprise security program.


Building a fully-functional and interactive honeypot that resembles a real production system can be a daunting task, replete with risk (you would be, after all, building a machine with the intention of it falling under the control of an attacker) but there are many other levels of honeypots before this level of complexity, and all of them present value to security monitoring.

The first type are known as 'low-interaction' honeypots. They are designed to present a minimal network presence and are actually best thought of as 'tripwires' - but they still fall into the honeypot's goal of providing rapid, reliable notification of unwanted activity on the infrastructure.

1. The armored alarm bell - A single host, sitting unnoticed in the middle of the data centre - It runs a scant few basic services and the system is locked down to a minimal level. It appears absolutely ordinary in all regards but one - the machine serves no purpose at all - it doesn't exist in asset tracking or CMDB, the hostname follows the local sequencing scheme with no overtly identifying information. It just sits there inside your network, doing absolutely nothing - until someone or something connects to it.

By definition, this host should see no activity - there are few legitimate reasons this system should see a single packet on the network (apart from local broadcast traffic). In the sea of alerts produced by security controls today, veracity and priority can be a rare thing; every last connection log from this system however bears investigation.