I have gotten a few inquiries about the average number of events per day that HoneyPoint Security Server deployments catch on average networks. While this question is pretty hard to answer in a general sense, since most networks differ by size, deployment security, policies and processes, we can talk about averages across multiple client networks and our own HoneyPoint sensor networks.

On average, Internet visible HoneyPoint deployments usually experience around 4 events per HoneyPoint deployed per day. This can vary depending on services emulated, but in general, adding smtp and web (the two largest receivers by far) against those deployed on rarely scanned ports yields this average over time. Those are amazing statistics when you consider that each of those is a genuine probe/scan event or attack! Many clients use Internet facing sensors as a means of populating black hole lists, web application address filters and other prevention focused mechanisms. Less often, clients use this information as means to perform risk assessment and response, meaning that they actively track this data and the sources and take a manual action. Usually clients use Internet exposed HoneyPoints as a source of threat intelligence, trend tracking for frequency and source variations and automated blocking configurations.

Internally, most clients experience 3-4 events per month on average. These events are usually treated very seriously, since any HoneyPoint traffic internally is suspicious at best and malicious at worst. Most security teams leveraging HoneyPoint use these events as triggers for true security incidents. They launch full investigations and either mitigate or minimize the discovered issues. They are able to do this and focus on these critical events due to the low number of them they experience, the lack of false positive events they see and the placement of the HoneyPoints close to the actual assets they are tasked with protecting. Many clients have moved away from using NIDS as any type of action item at all, and refer to their NIDS deployments only as forensic and correlation data for incidents triggered from HoneyPoints and log analysis/log management solutions.

While HoneyPoint Security Server is not a panacea for information security, it is a very strong addition to a security program. Clients are continually discovering new uses, new capabilities and new ways to leverage the system to further reduce their resource requirements. HPSS has proven to be a low noise, high signal, effective, traditional approach to providing threat management, security intelligence and detective capabilities for organizations of any size.

If you are interested in hearing more about the averages and what you can expect from a HoneyPoint deployment, just let us know. Give us a call or drop us a line and we will be happy to share the metrics we have with you!

Myself and a client have been playing around with a new technique that we are calling port mining. In this approach, we use HoneyPoint Security Server and HoneyPoints deployed in key locations to mess with worms, scans and tools.

The process is very very basic. We basically configure a simple HoneyPoint so that instead of sending the various text files it usually sends down the connection it sends a large binary file like an MP3, ISO or other binary data. Then we deploy the HoneyPoint and have it listen on a port for incoming traffic.

When the HoneyPoint gets a completed TCP connection, it immediately shoves the binary content down the pipe. It then waits for a response and sends either the same file again or another file. Very basic, right? Yes, indeed. However, we have seen three effects from this process:

1. In many cases, the file transfer of the first huge file completes and the connection dies with a timeout. In our lab testing, this was due to the unexpected input size and content of the data sent from the HoneyPoint, which has caused multiple forms of tools and malware to simply crash.

2. In other cases, we have seen the file transfer complete and the tool or malware respond only to get the file again down the pipe. We have watched this process act like a LaBrea scenario where the tool, scan or malware is significantly slowed by the data (of course, we are also using a lot of our own bandwidth) and in some cases we were able to cause the MS08-067 scans we were seeing to wait up to 50 mins for each 8 MB MP3 we sent and do this hundreds of times! Effectively, we slowed down that system from further scans while it kept playing with our HoneyPoint.

3. In very few cases, we see the connection terminate upon partial sending of the binary data. In about half of these cases, the connection terminates properly (so likely we had no effect) but in the other half, we see odd disconnections (unknown, but possible crash of the malware). In the lab, we have seen this happen with a few tools due to unexpected inputs causing exceptions in the code.

Now, it should be said, that we are just “playing” with this approach. We are not sure how or if this will be beneficial to anyone, but it was a fun idea to mess with scanners and such in such an easy way. Give it a try and let us know what you think!

PS – Extra points (and fun) can be had for finding the worst MP3 of the most horrible songs that have the largest effective use as a port mine defensive component. So, bust out your one hit wonders MP3 collection and see how your milage varies. 🙂