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?

As we posted to WatchDog last week, more and more attacks against FTP implementations are likely in the coming weeks. We noticed the release of a new GUI FTP fuzzer and so far it appears to be getting heavy use to find new vulnerabilities in several FTP servers, both commercial and shareware/freeware/open source. New FTP vulnerabilities and exploits are starting to emerge and are very likely to continue.

Admins of FTP servers should pay careful attention to their logs and their vendor information sources for new vulnerabilities and patches. It might also be a good time to make sure you have proper IDS/IPS coverage for all of your FTP servers and network drops.

As new fuzzers get developed and released, we think this might be an interesting precursor to vulnerability patterns. Let us know if you see anything interesting!

For some time now Bots have been growing in importance. They have truly become the most serious infosec threat to networks today. They are insidious, common and borne by some of the easiest to exploit vulnerabilities in many client side applications.

In many cases, organizations have rampant Bot activity inside their networks, though more often than not, they have no idea it is happening until a serious event like a DDoS attack or the like rises to their radar levels. The sad thing is, this is often too late. The attackers may have already gathered tons of data from network scans, sniffing and keyboard logging. They may already have access to the most critical data on the corporate network.

Now it seems that Bot masters have even begun to implement cryptography to better secure the connections between their programs. This helps protect the Bot traffic from discovery, analysis and reverse engineering attempts. It also makes signature matching and other IDS/IPS techniques much more difficult.

As before, the best defense against Bot attacks remains a two fold process. Organizations must implement proper egress filtering, including port blocking, traffic monitoring and analysis and proxy use. User systems simply can not be permitted to directly access the Internet in an unfettered manner in most networks. It is simply too risky.

Secondly, organizations must employ awareness to combat Bot infections. They must teach users of the associated dangers with open surfing, email attachments, instant messaging and peer to peer networks. All of these technologies and behaviors pose significant risk to the network environment – be it small, mid-size or enterprise.

Of course, all of this assumes the basic steps of patching, network firewalling and typical anti-virus/anti-spyware are already in place and functioning. You are doing that, right?