On Thu, 27 Jun 2002, Roger Marquis wrote:
IM has been a risk since it was introduced as the Unix `talk` program. Responsible corporate security policy should at least address it. Many such policies, including some I wrote after this post, have forbidden IM for some time now.
Essentially every multi-user operating system or network had some variation of the 'talk' program. IBM had the SEND command, DEC had the PHONE command, for some reason people want to use this functionality. Of course almost all of these "risks" exist with most other types of electronic communications commonly used in corporations including e-mail, two-way pagers, html, etc. Is AIM more or less secure than Outlook 97/2000/2002? E-mail is still the largest source of malware in most organizations followed closely by the Web. But I don't hear many organizations suggesting forbidding the use of e-mail or the web. The general principal is correct. You should disable services you don't use. If you don't use Unix 'talk/ntalk' you should disable it. If your machine isn't a web server, you should disable IIS/Apache. If your machine isn't a mail server, you should disable Exchange/Sendmail. If you aren't using IM, you should disable AIM, Yahoo IM, MSN Messenger, etc. It is annoying some vendors start these products automatically when you install other products such as Netscape or MSN. Despite what security people say, if you are going to use e-mail, the web or IM, the question is how can you do it safely? Heck, I read a recent article how even the US military is starting to use a version of IM for its battlefield coordination of activity. With IRC you can set up an organizational IRC server. Local users connect to it rather than "wild servers." Set up the IRC server to implement appropriate screening for your organization. Peer-to-peer IM products are a little harder because they assume direct connectivity between users, but you could use combinations of NAT/Proxy/SOCKS/Firewall packet inspection. Encryption of IM will probably be as wide-spread as encryption of e-mail, i.e. not very. But with the existance of OpenSSL, implementing a SSL aware IM is just a small matter of code. So instead of just saying no, how about coming up with same ways to solve the how to do it securely.