Users have a strong tendency to place unwarranted trust in the privacy and integrity of online communications. Users regularly e-mail sensitive information that they would never commit to paper—a problem businesses often first come to grips with when their e-mails are subpoenaed in court. Instant messaging (IM) takes that phenomenon to an even greater extreme. The technology conveys a sense of private conversation, and as a result people often use IM for informal discussions of extremely sensitive issues.
Perceptions aside, IM systems are very insecure as a rule. By default, IM servers relay messages unencrypted back to the sender, as well as on to the recipient(s). That results in the general broadcast of all sides of an IM-based conversation throughout the typical hub-based network, a target for anyone curious enough to download free packet-sniffing software off the Web. IM discussions over the public Internet are even more vulnerable. Moreover, almost every IM client will log sessions to a simple text file as a default; such log files are easy and valuable targets for snoops, intruders and subpoenas. Finally, IM systems often use rudimentary authentication protocols, making IM “spoofing” a trivial task for a determined attacker.
Luckily, there are a number of effective defensive techniques. Most in-house IM systems support message encryption via SSL. Such encryption can make a potential eavesdroppers task tremendously difficult, but it requires a full-blown PKI implementation and all the costs and hassles that go with it. Security of that technique, moreover, depends on preventing the theft or unauthorized use of SSL certificates, which can prove very difficult when attacks originate inside your organization.
Another option for encryption is an “internal VPN,” such as PGP Inc.s PGPnet. That technique encrypts all traffic between specific hosts—including IM traffic—and may provide more flexibility in administration and key management. In that case, however, ease of use may come at the expense of network performance and occasional interoperability problems.
Some IMs support client-based encryption plug-ins. Those tools provide security and performance benefits by removing the server from the encryption process, but they often lack administrative tools.
Unfortunately, theres little a system administrator can do to prevent the insecure logging of IM conversations. Unless needed, IM logging should be strongly discouraged; whenever possible, clients should be distributed with logging functions disabled. If necessary, encrypt the IM logs.
As always, use strong passwords and prevent or discourage auto-log-in features. Encryption can greatly strengthen the authentication process, but a client with stored credentials is vulnerable to anyone with physical access to its host machine—a serious problem in most office environments.
