Catching bad guys running amok on your network is so much more difficult than it appears in movies don't you agree? There is no event ID named “intrusion detected”. So how to figure out if event ID 4624 or 4702 or whatever is benign, suspicious or malicious?
It's easy if that event comes from an internal honeypot.
Honey-pots are nothing new but they have been primarily used out on the Internet. Deploying honeypots on the Internet are useful to researchers and InfoSec companies but not as much to general organizations as a detection tool. Why not? An external honeypot is going to tell you that your outward facing systems are being attacked. Well, which attacks are concerning and which are only drive-bys? If you have time and resources to study the attacks hitting your organization personally – great. But now you are more of a researcher and frankly most organizations don't have personnel to dedicate to that. So unless it gets out of hand in a DDOS attack or if you have lots of time to work with the FBI and ISPs you have to basically let it go. It's like a castle under constant siege. You expect to hear arrows hitting the walls.
But put a honeypot on your internal network and it's a different story. The boundary between the Internet and your internal network is far from inviolate but it's way more quiet than the Internet. And malicious traffic on your network is something you need and want to know about and should have the resources to follow up on.
I love the concept of internal honeypots because they are very similar to the idea I periodically promote of laying bait objects throughout the actual resources of your network – such as on file shares and document libraries that normal end-users regularly access.
Both internal honeypots and my bait objects are incredibly effective ways of automatically distinguishing legitimate user activity and business from malicious agents trying to find what's “the goods” on your network.
But internal honeypots are much easier to deploy and don’t carry all the end-user training and political ramifications of my more deeply embedded tripwire concept. Adding a red herring bait document to a folder or library of legitimate documents requires support from management, out-of-band training for end users and cooperation from system administrators.
Whereas internal honeypots just require one or more IP addresses on your network. Although in this webinar we'll look at additional steps you can take to ensure bad guys find your honeypots quickly – and before they find and penetrate the real systems you are trying to protect.
We will explore the open source world of pre-built honeypots such as
- Kippo
- PhpMyAdmin
- WordPot
- HoneyD
These are applications that are simple to install but that can mimic an application exposing a known vulnerability or even an entire network of systems comprising a variety of operating systems and applications. Some are “high interaction” and others “low interaction”. I'll explain what that means and why both are useful. We'll also discuss setting up actual Windows systems as honeypots.
But then we'll talk about the critical thing you have to do in order to close the loop and get real value out of internal honeypots: you have to monitor them – in real time if at all possible. That means connecting your SIEM. And this is where our sponsor, LogRhythm comes in. In fact they suggest this as a real training for free ™ topic because they have enhanced the LogRhythm SIEM with intelligence specific to honeypots.
So please register now. Don't miss this real training for free ™ event!