Recently I had the opportunity to see the future of Enterprise IM systems. I’m not the only one who thinks that by the way—but we’ll look at that more later. In the past few years, a major shift in the way business is done has been slowly occurring. The shift from paper communications to electronic communications was one that was slow in coming, but once it got started, was one that could not be stopped. The first, and the popular type, of electronic communications within the organization was email. However, in the past year or two, Instant Messaging has begun to take center stage for intra-organizational communications and even inter-organizational communications.<?
Why Instant Messaging?
The speed, convenience and flexibility of Instant Messaging systems cannot be denied. However, for all of the same reasons that Instant Messaging is good, it is bad as well. Let me elaborate on this a bit. To get a better understanding what makes an IM client so powerful (and so dangerous), let’s look at a listing of the typical capabilities offered by the big three IM client packages: AOL Instant Messenger, Microsoft .NET Messenger and Yahoo! Messenger.
· Basic text mode messaging between users
· Voice over IP conversations
· Video over IP sessions
· File transfers
· Application sharing
· Group chat in ‘chat rooms’ similar to IRC
While all three of the IM clients mentioned previously have some (or all) of these features, not all of the IM clients have all of these features. For this reason, you may find that users will often make use of two or perhaps even three clients on their machines. Various independent solutions have popped up to allow users to combine their various IM clients into one convenient interface. The most popular (and feature rich of these) are Trillian for the Windows operating system and Fire for the Macintosh operating system.
We’ve always been a society of instant gratification and for many years, it’s easy to see. We moved from walking to horse-based transportation to motor vehicles to the modern marvels of air travel and high speed trains today. The same is true communications. We’ve evolved from speech only to messengers to mail to the telegraph to the telephone to the radio to the television to the computer. Email was the pinnacle of computer communications for many years, especially after the Internet explosion in the early to mid 1990’s. It’s just the natural progression of things that Instant Messaging should replace email as the instant gratification communications method of choice. After all, there’s really nothing much faster than being able to chat directly with someone in real-time using Instant Messaging. It’s not hard to see the natural attraction to Instant Messaging that users have—despite the wishes of either IT staff or management.
What’s wrong with Instant Messaging?
For many years, organizations have been struggling to find ways to secure their data while at the same time not limiting their growth and usability of the Internet. Just in recent times, perhaps the past 18 months, have we seen an increased concern over Instant Messaging in the enterprise. Typical concerns have all centered around firewall solutions aimed at keeping those on the outside from getting in. No one gave much thought to what those on the inside might be doing—and what they might be transmitting to the outside. In the wake of 9-11, many things changed in this world, including the Information Technology landscape. When you combine this sudden need for increased security with the pressure being felt on organizations because of piracy issues (see Information Week) and you as an IT implementer or decision maker have some serious issues to deal with. No longer can count on simple firewall based measures to protect your company from people—both external and internal.
Now solutions for limiting liability due to the unchecked usage of Instant Messaging are in demand. Things in the IM landscape are changing; they must change if IM is to be a viable tool for the Enterprise. The change? Organizations are now taking back control of their networks when it comes to IM traffic, just the same as they have with email and web based traffic. Ask 10 network administrators where they feel the single greatest internal security break lies and the majority of them will point straight towards Instant Messaging. But why?
Instant Messaging is the Wild Wild West of the early 21st century Internet community. It really is—it’s a free for all. When you consider that there is no viable solution in place to track and scan IM traffic you realize the problem at hand. How do we protect our sensitive internal data from being compromised to the world? How do we protect our internal network from being comprised by nefarious files that enter via Instant Messaging? Right now, we can’t—at least not an Enterprise level that is ready to roll out into a production environment. Stand by, however, the times are changing and the future is upon us.
Tomorrow is now
As I said in the introduction to this article, I truly did have the opportunity to see the future of Enterprise wide Instant Messaging. Now, before I go any further into that let me back up a step and address the current state of Enterprise wide Instant Messaging. If you want to implement Instant Messaging in your organization, you most certainly can do that right now. There are two predominant solutions you can go with, depending on your preferences:
· Exchange Sever 2000 using the Exchange Instant Messaging service
· IBM Lotus Sametime
Although both messaging systems are robust and quite capable, our focus here is on Exchange Server 2000.
The problem that network administrators would like to solve is how to control the free for all that currently exists for users making use of Instant Messaging from within the network—while still leveraging the power of Instant Messaging for good uses. Microsoft has seen the need for this, and thus the next version of Exchange Server (due out some time next year after the release of Windows .NET Server) will have some nifty new features included. Lest you think that Microsoft is the brain-child of all development, let me set you straight. This solution comes in two parts: one from you (you knew it wasn’t going to be that easy) and one from a small, but extremely forward looking start-up located in downtown Boston, Massachusetts.
IMLogic, a privately held company, is no rookie in the IM field. The founder and CEO, Francis deSouza, is a veteran of the Instant Messaging world with a history of accomplishments to his credit. Prior to founding IMlogic, Mr. deSouza ran Microsoft’s Real-time Collaboration Group where he was responsible for the Exchange 2000 IM server, the Exchange Chat Server, the Exchange Conferencing Server and NetMeeting. Before joining Microsoft, he was the co-founder and CEO of Flash Communications, which was acquired by Microsoft in 1998. So, what does IMLogic have to offer us? A solution that is both truly ingenious and easy to just drop into an existing Windows 2000/Exchange 2000 organization. Read on…
IMLogic IMLog Enterprise—the first piece in the solution
As you can see in Figure 1, the current state of Enterprise Instant Messaging a messy one indeed. You may have multiple IM clients running on your internal network, such as AOL Instant Messenger, Yahoo! Messenger or Microsoft .NET Messenger. All of these connections open rather large holes in your network and thus open you up to security breaches, viruses and loss of confidential information…all without you having any clue of what is going on.
Figure 1 – The current state of Enterprise Instant Messaging.
While in most organizations, the thought of attack from outside or infection by a hostile executable is the scariest part of this situation, there are some special cases where the compromise of sensitive data may be the primary problem at hand. Organizations such as banks, securities companies, and others conducting financially-based business can appreciate the value of being able to not only control
Instant Messaging, but also keep track of it. By moving from the chaotic system depicted in Figure 1 to a more controlled organization, as shown in Figure 2, you can take great steps towards solving your Instant Messaging woes.
Figure 2 – Instant Messaging using Exchange 2000 and IMLog Enterprise version 3.
As you can see, we have now accomplished three key feats by setting our Enterprise Instant Messaging system as shown:
· We have moved to a standardized IM client in the Exchange Server 2000 IM client
· We have now ensured SEC, NASD, and HIPAA compliance by implementing full archive, search, and retrieval tools necessary to satisfy industry regulatory requirements
· We have eliminated all third-party IM clients by blocking them at the firewall (this is where you get to get your hands dirty, see the sidebar about working with the firewall)
Figure 3 depicts how the internal IM organization functions once you insert IMLog into the picture.
Figure 3 – The Instant Messaging flow after inserting IMLog Enterprise version 3.
The major components of IMLog Enterprise version 3 (from the IMLog 2000 Users Guide):
· IMLog 2000 Filter: An IIS ISAPI filter that hooks to the IM flow capturing messages and sending them to MSMQ. This component should be installed on all Exchange IM home servers.
· IMLog 2000 Service: Transfers messages from MSMQ to a database. Must be installed on the same machine as the MSMQ it will be reading. The IMLog 2000 Filter must be configured to log message to this message queue. Both the Filter and the Service should be configured to access the same queue.
· IMLog MMC snap-in: A Microsoft Management Console (MMC)-based snap-in that is used to configure IMLog Service and Filter. Installs with both the filter and service.
· IMLog Web Interface: Provides a web interface to query for logged messages and extract statistics. Installs on a box with IIS installed. The Web interface should be configured to point to the same database to which the IMLog Service is logging messages.
· IMLogEmailReport: A statistics generation and email reporting tool. Installs on a box with IIS SMTP service installed and access to the internet if emails should be sent to recipients outside the LAN.
So, as you can see, implementing IMLog Enterprise version 3 into your organization can bring some great rewards. But what about the costs? Well…of course, there is the money spent implementing the solution, but that is relatively minor in comparison to the safety and productivity you gain out of the deal. In terms of costs, you may want to chock up the loss of outside Instant Messaging capability with your vendors, partners and customers. Never fear, however, the solution is close out at hand…enter IMLog 2000 Enterprise version 4 which will be released for beta testing later this summer.
Figure 4 – Instant Messaging using Exchange 2000 and IMLog Enterprise version 4.
Firewall Configuration
You can block Instant Messaging traffic from passing through your firewall by closing the following ports:§§
· AOL Instant Messenger
o 5190 (outbound TCP)
o login.oscar.aol.com
· Microsoft .NET Messenger
o 1863 (outbound TCP)
o 5060 for Session Initiation Protocol (SIP) (TCP) §
o 1503 for Audio/Video, File Sharing and White Board (TCP) §
o 6891-6900 for File Transfer (TCP) §
o 3389 for Remote Assistance (TCP) §
· Yahoo! Messenger
o 5050 (outbound TCP)
o 5101 (inbound TCP)
o 5100 for webcam (TCP)
o 5001 for voice (TCP)
o For voice: cs1.yahoo.com, cs2.yahoo.com, and cs3.yahoo.com
o Yahoo will search ports 5050, 80, 20, 21, 25, 37 and 119 if 5050 is blocked
§ – Windows .NET Messenger in Windows XP and later.
§§ – Of course, this could change at any time without notice from the IM vendors, so be wary and keep a watchful eye!
In the end…
With the enhancements and improvements made in IMLog Enterprise version 4, you will now be able to use multiple Instant Messaging clients internally—and still take advantage of all of the power, security and peace of mind that we’ve already discussed when looking at IMLog Enterprise version 3. However, this is not the end of the road, for there is much still to come from IMLogic and the IMLog family of products.
IMLog is currently in used by several large financial and securities organizations—and for a good reason. We’ve seen how an out of control Instant Messaging system on the internal network can wreak havoc in more than one way; organizations with money and credibility to lose are taking an interest in this technology. You may want to as well.
Contact IMLogic at:
IMlogic
Suit 800, 75 Federal St.
Boston, MA 02110
617-757-7740
Web site: http://www.imlogic.com
For Product support: [email protected]
For General inquiries: [email protected]
For Sales: [email protected]
