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.
Whether blocking IM is a prudent strategy at your organization
depends on the value of the data "messaged", the IM application,
and routing of IM packets. In common use IM does expose many
organizations to a non-trivial risk of corporate espionage.
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.
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.
In case it's not a well-known project, I'll propose something I was
recently introduced to (Hi Scott!), silc.
"SILC has secure key exchange protocol that is used to create the session
keys for each connection. SILC also provides strong authentication based
on either passwords or public key authentication. All authentication data
is always encrypted in the SILC network. Each connection has their own
session keys, all channels have channel specific keys, and all private
messages can be secured with private message specific keys."
Easy to set up and use, and if you're familiar with irc, you can figure it
out quickly.
I'm quickly finding it to be most useful.
Now back to round 500 of the peering debate.
Charles
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.
I've done just this for a small neighborhood wisp. There are users of
varying skill levels who want to be a part of the noc team. Rather than
creating on important servers, or giving access to routers, for purposes of
diagnosis, I'm using the perl Net::IRC module to build a number of small
bots with very specific functions... e.g. syslog messages and mrtg stats
sent to a noc channel.
The next level will be to write a bot some with interactive access on the
network so a request to 'traceroute x' or 'sh int' can be done by anyone
with channel ops (and everyone present gets the benefit of the ouput if
there's a problem).
Eventually I will tie this into some type of text-to-speech on the client
side, so that critical conditions can be brought to our attention even if
the window is out of focus or we're all afk.
It's not hard to use SSH tunneling / VPN as well, ensuring that the noc
console application can be used securely across untrusted networks.
Mike