Instant messaging (IM) increases productivity with the
advantages of instant feedback and reduced communication costs. However, the
problems IM creates in a business environment are those of liability and
responsible use. This is particularly true in the Financial Services sector and
other regulated environments. The Financial Services Authority and similar
regulatory bodies are of the opinion that IM is no different than e-mail,
therefore the same requirements for record keeping exist. I think many users of
IM (including myself) see the conversations as ephemeral, vanishing into the
ether of time and space. Not so. All IM clients have logging facilities and
there are also packages available for network administrators which enable
logging of all conversations passing through the network. If any type of
dispute arises involving information given via an IM conversation, your
organization needs to know exactly what has been said. The same can apply
internally if disputes arise within the company due to improper use. Another
issue which must be addressed is that of increased vulnerability to security
threats. Virus writers and scammers are turning their attention to users of IM;new Trojans, worms, and phishing attacks are discovered daily.
For a business—and more specifically—its IT department,
the control of IM poses a problem. Firstly, do you have a policy on the use of IM?
If so, how do you enforce this policy and how do you ensure that you are
fulfilling the regulatory obligations imposed? If you do not have the processes
in place to log and archive records in a tamper proof and accessible format;messaging should be stopped. But how?
Two methods which I come across frequently are port and IP blocking.
Port blocking: This is very simple; find out what ports are
used by the IM clients and then block them on your firewall. The problem with
this is that the clients try to use many different ranges of ports, and these
tend to increase with every new release. "Well," you say, "my
firewall blocks all outgoing connections unless I specifically ask it to pass
them." That's good, but do you allow port 80 (http)? Most of today's IM
clients can now work perfectly well through port 80, and if you allow your
users to surf the net then they can probably IM too. I recently read that the
latest clients embed traffic data within an HTTP request, meaning that even
with advanced protocol analysis, they will be very difficult to stop! Smellslike guerilla tactics...
IP blocking: Again, very simple in theory, but with its own
problems. Using netstat along with googled resources, you can find the IP
addresses which an IM client will connect to. Block all outgoing connections to
this IP (or subnet) and eventually, once all servers have been found, the IM
client will be unable to go online. This looks like a better method than
blocking individual port ranges as it still leaves http open for web access. This
method still has limitations; in the amount of time it takes for the software
company in question to make a DNS or client update, a new server is added which
needs to be blocked. Because this can be hard to keep on top of, I keep the
major IM clients running on my desktop. In the rare event that one actually
manages to go online, a simple netstat can track down the new server, which can
be added to the block list. One of the major IM providers has started to have
their client program connect to IPs which also host their web services. This
means that if you block their IM client, you also lose access to these services.
Not much of a loss, until you realize that you can't run Windows Update! Lookslike we're heading for an all out Guerilla war!
Lets consider that we have blocked IM (don't forget to hunt
down and block services like http://www.e-messenger.net—ifyou don't, then your 'users' will use them).
The powers that be have decided that they now want to allow one
of the messenger services. Reversing the measures taken to stop that particular
IM service won't be difficult, but you have to find a way to log and archive
communications. There are many companies offering software to log IM traffic;
examples would be IMlogic
One of the previously mentioned products runs on a Windows platform, one is a
plug and play appliance. If you run on Unix/Linux/BSD then take a look in to
the dsniff set of tools.
This set of tools can log IM conversations, unencrypted password transactions,url requests, and more.
Our company has decided that public IM services should not
be used; however for internal communication, IM can be a very useful tool,
especially when you have offices spread across a large geographical area. Running
your own internal IM server is easier than you might think. Jabberd is an
implementation of the common messaging protocol, now known as XMPP (Extensible
Messaging and Presence Protocol). There are server implementations available
for various platforms including Windows and Linux; this is also true of client
applications (I personally use PSI).
The best thing about this implementation of an internal IM server is that it's
free, and there are no complex licensing schemes regardless of how many users you
want to have on the system. Logs can be archived in files or SQL format, whichever
you feel more comfortable with. If the configuration seems too complex or youwould rather use a commercial solution, take a look at Jabber Inc.
IM in the financial services sector is a very hot topic at
the moment and promises to continue as new regulations put IT policies to the
trying to push the use of MSN Messenger within a business environment—the firewall-bypassing efforts made by its
application backup this policy. New problems for IT departments to solve
I would be interested to hear reader's comments on this
topic; do you know other methods for blocking or logging IM conversations? Letme know