For those readers who like to go straight to the conclusion of an article, I'll just cut to the chase here. Are you running a honeypot network in your infrastructure and if not, why not?
I'm going to assume that many people will need some convincing however: honeypots are a misunderstood and mistrusted tool in the security arsenal, with all manner of reservations being raised as to why they aren't more widely used.
I'm confident however that in the following paragraphs I may convince you to look at this simple, effective technology in a new way, bereft of many of the misplaced assumptions about what values and risks a honeypot network carries with it.
The simple honeypot - a machine designed to present a tempting target for your attackers to victimise has an undeserved reputation in enterprise security; perceptions run narrow as to what defines a honeypot and what it is capable of. The honeypot is by no means a new technology in the security world; one of the most infamous stories of an on-the-fly honeypot being used to track an intruder is the venerable tale of ‘An Evening With Berferd' by Bill Cheswick.
Dating back to 1991, this is a factual account of the discovery of an intruder on the network and the creation of a 'honeypot' computer that would get the intruder's attention as a tempting target - not knowing that the machine was configured to be a trap to trace his origins and uncover his identity.
When reading the story of Berferd, some factors of this tale stick in the mind of the modern infosec professional. Berferd (the eponymous intruder) was allowed to attack other systems during their observation of him - something that would make any legal council cringe at the thought of it today. This perception of honeypots being a quagmire of risk and liability still remains today.
This is not an unfair resistance to the concept of the honeypot system - the idea of willingly allowing an attacker to gain control of a system under your control is a minefield of liability. A honeypot comes in many forms though; in the face of today's evolving threat environment and our need for more decisive information from our infrastructure security, there are many roles that only a honeypot can truly fulfil.
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. Building a fully-functional, fully-interactive honeypot that resembles a real production system (both inside and outside) can be a daunting task, replete with risk (you would be, after all, presenting 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 efforts at almost any level of program maturity.
Firstly, there are 'low-interaction' honeypots. These are systems that are designed to present a minimal network presence and can be thought of as 'tripwires'. They are more than the classical interpretation of a honeypot but they all fall into the honeypot's goal of providing rapid, reliable notification of unwanted activity on the infrastructure. A honeypot can aid your security posture in several ways:
#1 - The Armoured 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 and it appears absolutely ordinary and serves no purpose at all, 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, however every last connection log from this system 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 under utilised) features of the modern security incident and event management (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 prioritisation of correlated alerts from many systems across the enterprise by crosschecking against the honeypot system. If the same source host in the alert you are analysing has also been seen connecting to a honeypot system, then there presents good reason to consider the alert valid.
#3 - The Virtual Weather Vane: The virtual infrastructure is everywhere these days and deploying one additional machine template amongst many is an effortless task. Virtualisation also provides a valuable tool to the honeypotter - rapid rollback to a snapshot of prior machine state.
Placing an extra, minimally configured (except for logging remotely) virtual machine onto each hypervisor (configured for the absolute minimum of resource usage) that only accepts connections from other machines on the same hypervisor can provide a simple way of gaining more visibility into events that never leave the server.
With many security controls still requiring to be deployed inline on physical networks, activities inside the hypervisor that never leave the virtual switch can go unnoticed for some time. A honeypot system that merely reports what happens to it, and then is rolled back to a default state every hour or so, can provide easy early-warning on attempts by intruders to migrate from systems to system within the same hypervisor.
Systems such as these are also excellent candidates for some of the low-interaction malware-capturing honeypot software, such as Dionaea (http://dionaea.carnivore.it/) the successor to the Nepenthes system. Designed to present fake versions of commonly vulnerable services, honeypot software such as this mimics the vulnerable service just long enough to encourage the attacker to deliver the attack payload, which is then recorded by the software for later analysis. For worms and remote exploits, these systems provide an excellent way to perform early detection on attacks that do not yet have common detection signatures available.
#4 - The Imaginary Administrator: Spear phishing requires information about who to target for maximum effect at malware delivery. To a spear phisher, obtaining the contact details of someone with elevated network access (and additional information with which to social engineer them into clicking links) is the prime goal in any campaign.
Creating a non-existent person on the internet is easy these days. Perhaps in the recesses of your public website you can make mention of a fictional administrator of your two-factor authentication system, provide contact details for them and set up an email inbox, then take a close look at everything coming in to that account and cross-reference with who else in the organisation receives email with the same content, originating host, etc.
Doing this effectively is an art in itself however, but there are many organisations that are high profile targets for spear phishing attacks using methods such as this to rapidly identify when and where their employees are being targeted.
#5 - The Ghost Page: A honeypot does not have to be an entire system, sometimes content itself can perform the job, especially if it is content that a normal user would never discover. Most web vulnerability scanning tools will access a list of common locations for forms in known-vulnerable web applications.
While common intrusion detection systems will detect these (and a good SIEM correlation rule set can look for these URI's in the logs from the web servers themselves), there is a missing piece of the puzzle here. The web server will report '404 not found' to these pages and the scanner moves on to the next system, but what if the web server reported with Error 500 indicating that the page is present, but a server-side error has occurred?
Our attacker may stay focused on this one system (wasting their time and effort) and providing us with much more information (a technique often referred to in other contexts as 'tarpitting'). Setting this up requires some configuration of the web server and may not be acceptable for some production systems.
There are many variations on this theme; the people at Project Honeypot have an excellent distributed model where they crowd source the placing of these honeypot pages to the general public, each filled with bogus email addresses so spammers scan web servers for contact information, find the hidden pages and then send spam to the generated addresses, revealing their systems in the process and helping identify incoming spam for all.
Now these honeypot methods, while all cheap to build and deploy and requiring little additional analysis to make the intelligence they generate useful, are merely the tip of the iceberg of the art and science of building effective honeypot systems. There are few organisations making extensive use of honeypot deployments, and those that do are mature enough that they tend toward the more complex installations.
Honeypotting (like almost everything in information security) is undergoing constant evolution in sophistication and discovery. It has great potential as a truly valid technique for ‘bringing the fight to our attackers' by wasting their time and resources, misdirecting them away from their true targets and forcing them to reveal themselves to us.
Ongoing collaborative projects such as the HoneyNet Project continue to develop new software to capture both directed and automated attacks and integrate honeypots directly into malware analysis sandboxes. Sinkholes and tarpits to redirect and trap command and control channels for botnets are a cousin to the honeypot that is proving to be an effective active countermeasure against malicious software networks.
Conrad Constantine, research team engineer at AlienVault