eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Plenty of tools are available to make instant messaging play nice in a corporate environment. But with Yahoo and AOL recently dropping their respective enterprise IM services, its clear that companies have yet to integrate IM as seamlessly as they have e-mail.
Dont get me wrong; e-mail isnt exactly the poster child for efficient communications. But at least the dysfunctional, antiquated system described in SMTP allows you to e-mail another person with a high probability of success. IM needs a system similar to SMTP, but with standards and technologies that shore up SMTPs shortcomings.
There are many reasons why Yahoo and AOL abandoned the business IM market, with finding customers undoubtedly a major factor.
Theoretically, it isnt unreasonable to pay for the provisioning and management behind AOL Enterprise Gateway and Yahoo Business Messenger. However, paying to talk on a single network doesnt make much sense. Who would buy cell phone service from a company if customers of that service could talk only to one another?
True interoperability hinges on the adoption of a proposed Internet Engineering Task Force standard called CPIM, or Common Profile for Instant Messaging. CPIM will be supported by the two major IM and presence standards camps: SIMPLE (SIP Instant Messaging and Presence Leveraging Extensions) and XMPP (Extensible Messaging and Presence Protocol).
CPIM basically defines a protocol by which IM gateways can communicate messaging and user presence information using an e-mail in-box metaphor.
However, the abuse of SMTP should be a lesson to those building these gateways because a truly free IM system will be subject to similar attacks. As surely as we have e-mail-directory harvest attacks today, there will come a day when IM users will be subject to the same abuses.
You can set aside the notion that IM works in a realm of trusted senders, where individuals willingly exchange identity information to join one anothers buddy lists. Weve already seen IM attacks that use social engineering to tap a users buddy list to send spam. More sophisticated attacks will not be far behind.
Next Page: Are you sending “spim” to your customers?
Page 2
Indeed, without sufficient security in place, there will come a day when, for example, a customer service representatives IM client is hijacked to send spim—spam IM—to your top customers. The converse is also likely to come to pass, where the customer service IM presence information posted on a Web site will become a spim target. (Much the same way that the [email protected] in-box is the biggest recipient of spam at any company.)
Companies such as Microsoft envision a world in which presence data exists everywhere. In fact, Outlook 2003 can be configured to show presence data about message senders in the Outlook in-box.
It will not take long for an enterprising hacker to usurp presence data in desktop applications that can arbitrarily execute code to send spim to everyone who makes his or her presence known.
Companies considering IM to communicate externally and internally need to think about security in the context of how badly such an application can be exploited.
The most likely way spim and malware will spread via IM is through trusted contacts, but spim could easily take on the source characteristics of spam. For this reason, companies developing IM applications need to be thinking about ways to establish and manage access to presence information, and users have to be thinking about how they want to distribute their IM addresses. Conceptually, the way IM systems manage presence information is ready-made for attacks.
I guarantee there is a product manager out there who thinks the ability to execute scripting code in a business IM client is a good idea and a competitive advantage that must be pursued, despite the well-documented and overwhelming evidence to the contrary. That product is going to come out one of these days, and IT managers have to be prepared to put their collective feet down and say no. ´
Technical Analyst Michael Caton can be reached at [email protected].
To read more Michael Caton, subscribe to eWEEK magazine.
Check out eWEEK.coms Messaging & Collaboration Center at http://messaging.eweek.com for more on IM and other collaboration technologies.
Be sure to add our eWEEK.com messaging and collaboration news feed to your RSS newsreader or My Yahoo page