Honeypots: A Security Manager's Guide to Honeypots
Eric Cole and Stephen Northcutt
The ultimate goal of security is to reduce or eliminate risks to an organization's critical assets. Ideally, we prefer to do this by preventing attacks, but one of the key mottos of information security is, "Prevention is ideal, but detection is a must."[1,2,3] We must realize that an organization's key resources will be attacked, and we have to be ready to detect the attack as early in the cycle as possible and take advantage of this when it does occur. One way of doing this is with honey-x technology, such as honeypots.
What is a honeypot?
The functionality of honeypots is so diverse that it has been a challenge to define exactly what a honeypot is: honeypots serve many different purposes for different organizations. Generally, a honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource. In fact, its value lies in its being misused. The information system resource might be:
- A dedicated server
- A simulated system or state machine like deception tool kit or KFSsensor
- A service on a selected host, like Tiny Honeypot that listens to ports not in legitimate use
- A virtual server, such as the original honeynet and most other honeypots
- A single file with special attributes which is sometimes called a honeytoken or any number of other possibilities
When most people hear the term honeypot, they think of a system that you un-patch, put on the Internet, and hope it gets broken into. Although this works well for pure research where a site does not have critical systems, it does not scale to a typical DMZ. You do not want your DMZ to be attacked or get compromised. If you have critical systems on your DMZ, you need to keep an attacker away. You do not want to draw them in with an un-patched system.
How do you use a honeypot?
In this case, you would use a honeypot to better understand what is happening on your key systems. A typical web server can get millions of hits a day. Attempting to identify the difference between legitimate connections and attackers is impossible. This is the case unless you have an easy way to discern attack traffic; thus, you have the second use of a honeypot. In this case, your honeypot is as a secure as your production web server and is put on the same network segment. Now, when worms and attackers hit, they attack both your honeypot and your legitimate web server. Because your honeypot has no legitimate uses you can quickly identify the attack traffic and use that information to build better defenses.
Liability implies you could be sued if your honeypot is used to harm others. For example, if it is used to attack other systems or resources, the owners of those may sue. Liability is not a criminal issue, but civil. The argument being that if you had taken proper precautions to keep your systems secure, the attacker would not have been able to harm my systems, so you share the fault for any damage occurred to me during the attack. Justice Department attorney Richard Salgado, speaking at the Black Hat Briefings, warned that honeypot law is "untested" and that people setting up the servers and networks designed to attract crackers could face such legal issues as liability for an attack launched from a compromised honeypot and charges of enticement from crackers"charged with illegal activities." It could also be hard to prosecute an attacker, if you have a system called a honeypot.
As with any technology, there is no perfect solution. A honeypot can provide value to an organization if it is deployed correctly. However, it can also cause a decrease in an organization's security by being more attractive to worms or attacks. Therefore, an organization must clearly define the risks it wants to reduce with a honeypot and the requirements for accomplishing this. Then, any deployment can be tested to make sure it benefits the organization.