I have been hinting that something big was coming for a few weeks now, and it is finally time to talk about it.

The big news is the release of MSI’s first enterprise security product – HoneyPoint.

HoneyPoint is designed as a direct response to the pain that I have been hearing about from network security folks for several years now. That pain is the general failure of network-based Intrusion Detection and Intrusion Prevention systems (IDS/IPS) to live up to the hype that surrounds them. Over the years, the idea of IDS has grown from a simple system of matching packets against a few signatures to a much larger beast.

Today’s IDS and IPS systems are broken. Most depend on signatures (be that against network packets or system & application logs). They compare the current traffic or events against that signature base and make a decision about the malicious intent of the traffic or events they are seeing. This was a great idea, to be sure, but it has largely failed to reach the promises vendors have been making for nearly a decade. There are simply too many signatures, too many nuances of traffic, networks have become too complex for effective IDS management and there is too much noise on modern networks for the signature-based approach to remain fully viable.

Now, before every IDS/IPS vendor in the world calls to tell me about their latest technology or technique to auto-tune, establish relevant baselines or use traffic patterns instead of signatures, I want to simply say this. Great! Good for you. But, I am not interested in hearing much about it. The current idea of IDS/IPS simply does not work. It is broken. Period.

Another reason why I say that is this – I have spent the last year talking directly with IDS/IPS users and hearing about their pain. They are spending way too much time tuning, updating and managing their IDS/IPS solutions. Even those that outsource their management, say they still spend way too much time working on false positive events or tracing issues that turn out to be nothing or worst of all, fighting against bot-nets, client side exploits, zero-day issues and other items that their detection systems failed to identify or stop. To put it simply, as one person did for me, they are “spending more time on managing the IDS than they are on responding to the 10K and more alerts it gives them each day.” To add insult to injury, of these 10K alerts – the majority of them turn out to be false positives.

Since threats are evolving and pushing into the organization at a much deeper level than the perimeter, and every trade magazine and security visionary is telling security teams to switch to enclave computing and begin to take an asset-centric approach to security, that is exactly what security professionals are doing. The problem is, they are finding that traditional IDS/IPS solutions are really not meeting the needs of securing the internal network in a meaningful way.

Thus, the paradigm shift that is HoneyPoint. The idea is an old one. The implementation is new. The idea of honeypots goes back a long way. They are essentially based upon the idea that if you create artifical systems or services on your network, an attacker will not know if what they see is real. The idea is that in order to determine what is real, they will have to probe and attack all of the visible targets. In doing so, they will, in more cases than not, probe a honeypot – thus alerting security folks to their presence. Obviously, the more honeypots, the higher the likelihood of their being probed instead of a real system.

This is the basis for HoneyPoint. We use it to make our systems offer services across the network that appear to be vanilla and homogenous. Imagine a big 10×10 grid of light sockets. If you had a light bulb and were asked to screw it into some of the sockets in the board, but some of the sockets were real and would light the bulb, while others would set off an alarm – how would you go about identifying which ones were real and which were alarms? You might carefully examine them, but if they all look similiar, the only way to know would be to try them.

That is exactly what we do with HoneyPoint. We dialate ports across our systems with similiar appearing services, and then wait for attackers to try and figure out which ones are real and which ones are HoneyPoints. Just by doing what attackers do – that is, probing the network and services they find – they fall into our trap and alert us to their presence. Once identified, they can be quickly isolated and shut down by network security staff.

The most beautiful part of all of this is the lack of false positives and signatures. Since the services offered by the HoneyPoints are not real, there is absolutely no reason at all for anyone to be using them. That means that ALL TRANSACTIONS WITH A HONEYPOINT ARE REAL EVENTS. Since the HoneyPoints key in on the idea that a transaction has occurred, and not what it was; they have no need for signatures (thus, no need to update and tune them). They simply capture the traffic they see, identify the source and alert the console of the event. Simple. Easy. No muss, no fuss – no additional management. The alerts from the console system can then be handled by the security team as an incident.

Alerts can be delivered via email, SMS (with a gateway), syslog or Windows Event logs. The console and HoneyPoints run on Win32, Linux/UNIX and OS X. Given their flexability, they can emulate thousands of services ranging from complex HTTP applications to RFC compliant implementations of your chosen mail platform. The variations are as flexible and endless as your imagination.

The HoneyPoint solution is built upon the idea of “deploy and forget.” HoneyPoints need only be installed and configured one time (leaving more time for vacations). They then operate as services or daemons (depending on OS) and simply wait for attackers to probe them. They have miniscule file sizes and memory demands, meaning you can run thousands on an average workstation size system with little impact, should you so desire. We suggest that you deploy them across your enterprise on your existing systems. No new hardware is needed.

Take a few minutes and visit the HoneyPoint web site at: http://www.microsolved.com/honeypoint for more information. Take it for a spin by filling out the form and get your FREE 90 day trial.

I think you will quickly come to understand why we are so excited and why security teams from many of our customers are telling us we have changed the way they think about securing thier environments!

Thanks for reading and for being patient while we brought HoneyPoint to life. I think once you use it, you’ll agree – it was well worth it!

MSI is pleased to annouce that we will be moving soon to our new offices. We intend to do so in the next couple of weeks. The new building is located on the West side of Columbus and is a major upgrade for us in terms of space and useability.

Stay tuned for announcements on the new address, but the phone numbers and web presence will remain the same – of course.

Thanks for your patience the last few weeks and in the coming days while we prepare for and execute the transition. Blog entries have been and will likely be slower while we pursue the move.

Thanks to everyone who has helped make this possible and who has worked with us to prepare!

I have been getting a few emails asking why I have been so quiet and where the podcast is.

The podcast has been delayed a bit, sorry for that. I am working on it. Maybe within a week or two I will have it ready and then can get an idea on how often we will do them.

In the meantime, I have been so quiet because I am working on a pretty major project. Stay tuned in the coming weeks for a large announcement from us about a very cool new software product we are about to release. I am very excited, and I think you will be too.

In the meantime, Neil and Troy have been carrying the blog traffic, and I have been continuing to write over at security.itworld.com. Check out my article this week for some insight into why I think IDS/IPS solutions are failing us.

Stay tuned, I promise it will be very interesting…

Stay tuned for an upcoming podcast that reviews Unified Threat Management and gives some ideas on how it can help your organization. I also identify some things to look for in choosing a UTM solution and some of the changes we can expect in the UTM market. I am working on it now, and should have it posted next week.

In the meantime, keep working on getting the patches from MS yesterday applied. It looks like exploits are already making the rounds for some of these, so stay vigiliant. WatchDog is yellow now due to the issues and exploits.

Also, I had a pretty good discussion yesterday with some Cisco folks. They had some good feedback and such on where they are going with the “Self Defending Network”. I would love to get some client feedback about how people the view the Cisco mission and the products since they have embraced this idea.

For the last week or so, DShield and SANS have been showing a spike in Telnet (port 23) traffic for scans and attacks. However, the scans truly seem to be localized to specific ISPs. To date, none of the MSI honeypots or sensors have recorded any increase in Telnet traffic. On a couple of our consumer broadband connections, we have been watching for Telnet traffic for nearly a month without a SINGLE connection to any of our systems.

This may mean that some specific malware or scanning autorooter has been created that targets specific IP blocks that are known to belong to commercial operations. What they are seeking, at this point is still unknown.

This leaves us wondering if something else is coming, or if this is simply an anomoly or noise in the Net, so to speak. The smart idea is to do some additional monitoring around hosts that provide Internet facing Telnet services. It might be a good idea to run some quick scans for open Telnet connections and begin to round up whether they are needed or not. Some perimeter firewall config changes may help hide the unneeded ones from whatever is out there crawling the net for them.

If you see any unusual traffic on Telnet, please submit logs, packet captures or let us know using email or the “Talk to ISOC” function of WatchDog.

The press is spending some attention on the Word attacks that took place recently, but we feel much of this is overblown. Sure, two forms of the attack are said to be in use, but there is little public info about them, and certainly no evidence of widespread attacks as of yet.

On WatchDog we have placed the suggestion of using the “winword /safe” command to better protect your organization, but it is likely a patch for the issue is coming in June, and until widespread exploits are available, it is pretty unlikely that most organizations will see any attacks from this.

In the meantime, we suggest treating it like the myriad of unpatched holes in Internet Explorer that occur so often, and use some caution, alert users and help desk folks to be aware of the symptoms. Then, apply the patch when it is released.

Most of all, please do not panic. The risks are not all that high compared to many of the other vulnerabilities common in most enterprises today.

We are left wondering about the Exchange vulnerability. To date, we have seen no malware exploiting this vulnerability on a mass scale. Even public exposure of exploit code has not been made. So, the question is why?

Are attackers holding this back for integration into a multi-exploit attack or did the recent VNC development distract them from the Exchange problem. Only time will tell.

We will keep our eyes open for development on this situation and let you know what we see. In the meantime, make sure you are applying the patch for Exchange and upgrading your VNC servers to the new version. We are seeing wide scans for the VNC problem, and SANS is reporting much attacker activity from this exploit.

We wanted to ask, you, our readers, the folks in the treches everyday, just what you might be wishing for. Is the answer more time, less changes in the environment, one patch to rule them all?

Use the comment link below, and give us some insight into just what you are wishing for. Heck, you never know, it might just come true.

Ahhh, the big question of tradeoffs. Do you apply the new Microsoft patch and stop Exchange from working with your Blackberry users or do you risk being compromised and worm infected when attackers release malware based on the vulnerability?

That is a HUGE question for many organizations. Right now, as I write this, several folks are contemplating that very question. Do you take the risk of a breach or keep your users happy? Both have large political fallout issues and long term impacts. Both have highly visible outcomes.

How do you make such a decision? Well, our suggestion is to evaluate the risks to your organization. But, that said, we are risk management folks, and others might not agree. We suggest you evaluate the potential of damage to your business that a compromise or worm infection could cause (perhaps based on your latest risk assessment) and compare that to the losses from having some members of your user population (the Blackberry users) partially unable to access some services in Exchange. Complete the process by converting these risks to real dollar damages to the bottom line and then decide. Of course, don’t forget to include regulatory and reputational damages in the comparison.

For some organizations, who are truly dependent on the Blackberry technology, the case may be that patching is the greater risk. For those organizations with additional controls and security mechanisms to protect their Exchange implementations, the risk may be partially mitigated and thus much less. For most, however, the answer will be to apply the patch. Then the question becomes, how can you explain to users the tradeoff you have been forced to accept?

For those organizations choosing not to patch, be very careful. It is very likely that a widely available target, such as Exchange, would make a ripe target for attackers and worms. Make sure you monitor the systems, networks and log files continually until you can apply the patch.

For those that patch and have to explain the solution to users who won’t be praying the “Blackberry prayer” for a while, be honest, open and up front. The more we explain the ideas of risk management to our users, the better decisions we empower them to make in the future. Awareness truly may be the key to a more secure future for all of us.

The ASN.1 Microsoft vulnerability is still alive and well. If you check your IIS logs you probably see this activity on a regular basis. ASN.1 seems to be the Code Red and Nimda of today – it simply just won’t die.

Patches for ASN.1 have been available for quite some time, and the malware using this mechanism to spread is easily identified by proper IDS/IPS and anti-virus rules. With so many easily available options for protecting against it, it seems to be very robust at hanging in there.

Perhaps an organized effort should be arranged through some online forum to identify systems spreading very old malware such as this and to contact the system owners to inform them. Maybe an incident response effort for “aging worms, exploits and malware” or the like.

Any volunteers to head the effort?