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.
True, you may discover more broken business processes and deployed systems than actual hostile actors on the network, but no experienced security analyst would count the discovery (and rectification) of these as wasted effort; for the more silent you become the more you can hear.
2. The correlation correlator - One of the great (yet underutilized) features of the modern SIEM is the correlation engine: a good correlation implementation allows for alerting on behaviour over time or across a scope of systems. A honeypot system allows easy prioritization of correlated alerts from many systems across the enterprise by cross-checking against the honeypot system - if the same source host in the alert you are analyzing has also connected to a honeypot system, then there is good reason to consider the alert valid.