Why A Honeypot Is Not A Comprehensive Security Solution

A core security principle and perhaps one of the most important lessons you’ll learn as a security pro is AHAT, “always have an audit trail”. Why? If you’re ever faced with a breach, you’ll at least know what, where, and when. And some laws and regulations require audit trails as well.

To assist, there’s a smorgasbord of tools to help you monitor devices, systems, apps and logs. Since these tools monitor networks on a 24×7 basis, they generate thousands of log entries daily, often flooding admins with too much data. Beyond the reams of data, there are alerts, raising red flags and flooding in-boxes with SIEM and intrusion detection notifications.

I wonder if it just might be possible to miss the forest because of the trees?

Yes, these tools did what they were told – find this and that and another thing, trigger an alert – but with a deluge of alerts, it’s hard to pinpoint and identify what was important to investigate.

If everything is important to investigate, then nothing is important.

This is why honeypots became a beloved security tool and in some ways, patch the shortcomings of your existing monitoring tools.

If you want to learn more about what honeypots are capable of, check out the Security Tools Podcast to find out how Honeypots work.

What is a Honeypot?

A honeypot is essentially bait (passwords, vulnerabilities, fake sensitive data) that’s intentionally made very tempting and accessible. The goal is to deceive and attract a hacker who attempts to gain unauthorized access to your network. The honeypot is in turn being monitored by IT security. Any one caught dipping their paws into the honeypot is often assumed to be an intruder.

Advantages of a Honeypot

Before we get into why a honeypot shouldn’t be your organization’s only security solution, let’s highlight a few reasons why they are a very effective security measure in IT– especially to learn more about who might be lurking in your environment.

With a honeypot, you can learn about how the attacker entered the system,  from where (e.g., IP addresses of where the stolen data is going to and where it’s from), what’s being deleted or added ( e.g., attacker elevates his privileges to become an admin), keystrokes of a person typing, and what malware is being used (e.g., a Trojan or rootkit was added to the system).

Alerts worth investigating – As mentioned before, IT is often bombarded with thousands of alerts a day, with little or no distinction between high- and low-level risks and threats. Whereas honeypots only log a few hundred events, making it easier for IT to manage, analyze, and act more quickly, and then to evict the intruder before further damage is done.

When it comes to honeypot alerts, beware of a different kind of false positive.

For instance, an attacker can create a diversion, spoofing your production systems that pretends to attack the honeypot. Meanwhile, your honeypot would detect these spoofed attacks, steering your IT admins to investigate the wrong attack – that your production system was attacking your honeypot.  Meanwhile, during this fake alert, an attacker could focus on a real attack. Yes, hackers are clever!

Alternative to prevent ransomware– If you don’t have an automated file monitoring system, you can instead creating a honeypot with fake files, folders and then monitor regularly as, say, an alternative to preventing ransomware. Hey, why not try our home-grown PowerShell-based file monitoring solution?

Sure, you’ll have to enable file system native auditing. Keep in mind that by doing so, it will be a significant overheard on your systems. Instead, try this: prioritize and create an accessible file share that contains files that look normal or valuable, but in reality are fake.

Since no legitimate user activity, in theory, should be associated with a honeypot file share, any activity observed is more likely to be an intruder and treated as a high-level alert. After you’ve enabled native auditing to record access activity, you then can create a script to alert IT when events are written to the security event log (e.g. using dumpel.exe).

Potentially detect insider threats – Yes, it’s often assumed that any interaction with a honeypot is considered to be evidence proving you’re a hacker. After all, there’s no reason for anyone to be there.

Depending on the setup, just because your employees are triggering the alerts, they should not be automatically guilty. In a litigious world, users may argue that the employer violated their privacy because they didn’t give them permission to cull their personal data from the honeypot.

Trust, but verify.

On the other end of the spectrum, behind the firewall, using the company’s account credentials and IP address, it can be difficult to spot malicious and/or disgruntled insiders.

Why?

An insider might never use or interact with a honeypot and so it would be of little value as a research tool. Also, honeypots won’t work if the insider is aware of a honeypot or somehow discovers it. The insider will know how to avoid the honeypot, and as a result won’t log and trigger any activity.

Decrypted data – Organizations are beginning to encrypt their data. After all, it’s suggested as a best practice and for some, a compliance requirement. But technologies that protect our data like encryption can’t tell us what’s happening on our networks. That’s when honeypots are helpful. It will capture activity because honeypots act as endpoints, where the activity is decrypted.

But, Honeypots Are Not A Panacea

Try security by design instead – Similar to penetration testing, honeypots are the opposite of security by design. In order to learn more about your organization’s environment, honeypots are often installed after the system is ready. It’s very much an educational exercise, where you bring machines in to tell you where you might be vulnerable.

A more proactive way of thinking about reducing risk and improving security is to conduct the testing before you release a product or new IT environment. Require the same of your IT environment as what you require of light bulbs, food, and buildings. That’s what security by design emphasizes – build security into every part of the IT management process, starting from very beginning of the design phase.

UBA, a better way to detect outsiders, insiders and ransomware – Once an outsider enters through legitimate public ports (email, web, login) and then gains access as users, they’ve gotten very clever at implementing an attack that won’t be easy to monitor.

In fact, to an IT admin who is just monitoring their system activity, the attackers appear as just another user.

That’s where User Behavioral Analytics (UBA) can be really useful, even more effective than a honeypot!

UBA really excels at handling the unknown. In the background, the UBA engine can baseline each user’s normal activity, and then spot variances and report in real time – in whatever form they reveal themselves – Outsider? Insider? Ransomware? – they’ll be spotted. For instance, an IT admin can configure a rule to, say, spot thousands of “file modify” actions in a short time windows.

Liable for damages if your honeypot gets hijacked – Yes, you’ll expect a honeypot to be probed and attacked, but you should also consider the potential for it to be exploited.

However some honeypots introduce very little risk, such as low interaction honeypots. They’re easy to install and isn’t really a functioning operating system that an attacker can operate on. They’re mostly idle, waiting for some kind of activity. It captures very little information, only alerting you when someone visits your honeypot and that you should go observe the activity.

Whereas a high interaction honeypot is much riskier. A real operating system, it has services, programs, emails, and operates just like a real computer. It’s also more complicated to install, deploy, and requires strategic placement. You could either increase the risk of your network as a whole or no one would see it.

However, your high risk honeypot also captures more information – the IP address, in some cases the name of the individual, type of attack, how the attack was executed, and ultimately learn how to better protect your network.

Keep in mind, instead of avoiding detection, an attacker can also feed fake information to a honeypot, leading the security community to make incorrect judgements and conclusions about the attacker.

Back to the hijack.

You will have a serious problem on your hands once a honeypot gets hijacked and used to attack, infiltrate, or harm other systems or organizations. Known as downstream liability, your organization could be held liable for damages.

You’ve been warned.

Be mindful of how you implement your honeypots and choosing your security solutions wisely. Honeypots are not a good substitute if what you really need is a system such as user behavioral analytics. Instead, honeypots add value by working with existing security solutions.