Problem solve Get help with specific problems with your technologies, process and projects.

Take instant messaging security seriously, part 1

Instant messengers can allow hackers to destroy a network. These fears can be put to rest by implementing enterprise IMs.

Instant messaging, that increasingly popular peer-to-peer technology, could be the Trojan Horse that allows hackers to destroy a network. That's the fear expressed by SearchWindowsManageability (SWM) users, who say that IM is a top security issue. Their concerns are well founded, said IM expert Jeremy Dies. They can also be put to rest, he said, by implementing enterprise IM systems rather than publicly downloadable ones, such as AOL Instant Messenger.

Dies explained why enterprise IM systems are more secure than public IM systems in a recent SWM article, "Instant messaging insecurity gains momentum." SWM received many user responses to this article, so we invited Dies back to answer their questions. In part one of this series, Dies discusses chat logging and IM security. In part two, he details blocking IM ports and Web-based IM systems. Dies is an offerings manager for advanced collaboration at Cambridge, Mass.-based IBM Lotus Software, Corp.

SWM user: I don't understand why it is now so important to log IM sessions. This falls in the same category of monitoring phone calls/e-mails/chats. There is a big difference in logging connections versus content contained in those connections.
Dies: Logging IM sessions may not be a business need for every IM customer. For some customers, such as those in financial services, it actually is a regulatory requirement. Just like some phone conversations are recorded, you would have to do the same for chats. It's not for everyone, but it's absolutely necessary for a lot of people.

SWM user: How can someone steal information from our company or plant a Trojan horse through IM products?
Dies: I know viruses like that have been passed through public networks because they're being poked through the firewall. Again, you're not necessarily instant messaging with a trusted source. The key thing about enterprise IM systems is that you're able to make sure that you're instant messaging and sharing information with a trusted source. A Trojan horse can't be done because you have the option of having instant messaging entirely within your firewall. So no one from outside will be able to get a Trojan horse because you're already inside and secure with your employees.

SWM user: What are the specific security problems raised by the use of public IM products, such as ICQ and MSN Messenger, within the corporate network? Dies: There are several problems. The first and most obvious problem is that the messages aren't encrypted. It's like sending an e-mail over a radio. People can just tap in and be able to intercept your messages. Another security problem with public IM networks is that you're not authenticating against a known source, such as a corporate directory. With enterprise IM systems, you authenticate against your corporate directory, so people know you are who you say you are.

SWM user: Can in-house IM be done peer-to-peer, or do you need Active Directory for it to work?
Dies: It can be done peer-to-peer but that doesn't necessarily mean that you would want to. Having IM traffic flow through a centralized server actually allows you much better control over the kinds of traffic that's going on your network. From there, if you're using audio or video over IP, you're able to manage bandwidth in a more efficient way. If you control who among your community has access to what, from a logging, auditing and manageability perspective, it makes sense to be able to manage these services centrally as opposed to a peer-to-peer architecture. The basic capability is nearly the same, in that you're still connecting people from their desktops to each other. Doing so through a server has some definite advantages over doing it from a peer-to-peer standpoint.


>> WIN2000TALK - Listen to our broadcast on Win2k Security

This was last published in June 2002

Dig Deeper on Working With Servers and Desktops

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.