RealSecurity

I’m not one to shoulder ISPs with the responsibility of policing the Internet. There are very good arguments on ensuring ISPs are providing wide open, unfettered access to the Internet. This is analogous to buyer beware from the user’s perspective. However, ISPs are in a unique position in helping to sanitize the Internet from the obvious undesirable, dark side of the Internet. This is not about perfectly cleaning the Internet, but one can’t deny - as a community - they could potentially wipe out some of the most damaging threats, like botnets.

Recently, September 15, 2009, the IETF published a draft titled, “Recommendations for the Remediation of Bots in ISP Networks”, that attempts to express terminology, issues, detection of bots, user notification, and remediation of threats of this nature.

I applaud the effort, but have to confess the content appears too “soft”. While I can see why, in that people do not want to make hard-line proclamations, I can’t quite understand why it is not more detailed and specific. For example, there is good material defining the problem, which is expected and nothing really new, but good to have. There is very good guidance on detecting bot activity. The authors provide very meaningful and useful advice in the detection space.

Then it goes into user notification scenarios including such things as e-mail, IM, phone calls, and SMS. Of these two stand out as interesting. First is a walled garden, which is essentially sandboxing the user and restricting certain activity. Obviously, this can disrupt Internet use for the user and potentially impact VoIP, on-line games, and the like, but it protects others and provides and environment where the user can make corrections. Interestingly, this is in the notification section, when it looks like a meaningful remediation method. The next notification I found interesting is Web Browser Notification, which can be compared to a popup or other method. Of course, and rightly identified by the authors, this assumes the user is using a browser and how can you be certain the bot is not designed to divert such a warning. Far from perfect, but I’m not looking for perfection, just something.

Now, after these sections is where it starts to get soft. I was really looking forward to section 7, “Remediation of Compters Infected with a Bot” (Yes, including the misspelled “computers”, but that’s calling the pot calling the kettle black.). All this section covers is helping the user know what a bot is, providing information on its source location (Which system? My PC, Mac, Media server, etc.), and offering guidance on remediation. This isn’t all that helpful. But, in their defense, and to my earlier point about not shouldering the ISPs, what more could they really do? Well, the blue-sky guy in me thinks back to early days when ISPs required clients to be loaded, such as AOL or Compuserve. What’s to say that the ISP can’t have – as an option – a java app that can’t help the customer? I know, that opens a huge can of worms and starts sounding very NAC-like, I did say it was blue-sky.

However, the real disappoint was section 8, “Guided Remediation Process”, which is comprised of seven paragraphs that are basically, 1) backup your data, 2) install patches and run a virus scan, 3) explain how to configure the computer for automatic updates, 4) help to find professional assistance, 5) help determine which computer is infected (seems like this should be step 1, no?), 6) survey users for feedback, and 7) if the user is interested in reporting to law enforcement, help them do so.

This is very basic stuff and obviously directed at the customer community in remediating bots on their system(s). However, what’s the title of the draft again? “Recommendations for the Remediation of Bots in ISP Networks”. It really should be, “Recommendations for ISPs in Assisting Customers in the Remediation of Malware.” And that is the basis of the issue. This isn’t about guidance for an ISP in dealing with bots in their network, it’s about customer service. Frankly, I was really hoping that it would get into more about filtering, shunting known bad traffic, sandboxing (which it did cover, but from a notification perspective, which sorta eludes me), and other interesting things that you can do when empower with vast technology in networking.

Networks can be made very smart and things that are without a doubt bad for the Internet should be addressed, and the ISPs are in a great position to help. I need to be very clear on this point. This about managing traffic that is absolutely, and without question, malware activity. I don’t want my ISP to start blocking my PlayStation 3 online gaming… I’d have a canary. What I would like though is to stop having my Internet-facing systems hit with Hack-Me-ACME packets. There are some things that are – well – obvious. Again, I’m not looking for perfection and a lot of bots are very smart about how they communicate to avoid such controls. But not all bot are cut from the same cloth. There are bottom feeders that make up the white noise on the Internet that can be quelled.

So, my summation of the IETF draft is this:

• The definition and problem statement is good, to the point, and needed.
• The section on detecting bots is very good too. Not detailed, not extraordinary, not necessarily new, but very good, insightful, thoughtful, and makes the read well worth your time.
• The notification of users section is “ok”, but does have a couple interesting comments and ideas most will like.
• The remediation of computers portion – well, it’s pretty standard fair.
• The Guided Remediation Process was nothing more than what I would call customer service.
• Finally, I think the real problem is the title. Call it what it is – how to detect bots on your ISP network and recommendations on notifying and helping customers. Change the title and you're good to go.