Blog

E-Pro: Quenching the IM Thirst with Sametime-Ade


Tags :


Quenching the IM Thirst with Sametime-Ade
by Chris Miller

As the manager or owner of your enterprise, you feel that business is doing well. You can hear the sounds of doors opening and closing, a doorbell ringing, and the click of your employee’s keyboards. Unfortunately, what you don’t realize is that much of that keyboard activity may actually be employees using chat clients.
In today’s computing environment it’s becoming common to see unmonitored and unrestricted chat, file transfers, and audio and video connection bandwidth utilization. This largely personal use of enterprise resources is growing and will soon become an issue that all companies have to face.
It was back in the days of talk on Unix systems that simple realtime messaging in the most basic form was introduced to computing environments. Realtime messaging today has evolved into a language that combines fonts and emoticons (see Figure 1) with text, and has seemingly become the way some teenagers spend all their waking moments. And some of your employees are following the trail blazed by youth.
       Current estimates are that 70 percent of enterprise employees are utilizing instant messaging, according to Gartner. (You can find more statistics on its findings at
http://www3.gartner.com/3_consulting_services/marketplace/instMessaging.jsp.) Unfortunately, this figure represents both authorized and unauthorized instant messaging. Osterman Research released a study (see http://www.ostermanresearch.com/results/surveyresults_im0902.htm) that shows the current mindset of enterprises in curbing or embracing the rise in instant messaging. The survey found that 30 percent of enterprises support instant messaging, 35 percent were neutral in their support stance, and 14 percent just say “OK” to its existence in the enterprise  but have no security safeguards in place as of yet. Osterman’s final estimate is that 225 million people will have instant messaging as part of their daily work lives by 2005.
Many administrators underestimate the number of chat clients and services that are available to the public. Outside of the biggest four (AOL, MSN, Yahoo, ICQ), there are numerous others. A current explosion of what I call “consolidation clients” is now being embraced by the user community. The most popular client is provided by Trillian (see figure 2). It lets the users to log into all of the abovementioned clients, plus IRC, from a single interface. All buddy lists, as well as the features of each individual chat service, are available and integrated. Some other vendors now offer the same consolidation but Trillian appears to be the leader in that space.
In my view, this proliferation encourages users to join more than one chat community. By simplifying the user interface and ability to maintain presence in numerous systems, users are amassing large groups of chat buddies.
If an Internet standard to connect these services together is ever agreed upon, the rise in usage can only grow. Currently SIP does connect messaging services together through gateway servers so communities may interact (more on that in a minute). Users that can only reach family on AOL IM because the enterprise supports it, will soon be able to reach all their friends on MSN and Yahoo through the same connectivity.

Chat Security Concerns

Aside from the concerns about company time and bandwidth being eaten alive by excessive chat, this situation raises legitimate security concerns. For example, how many of your users would you expect use the same password for the public chat services that they use to access internal systems?  Would you wager over 60 percent of your users do that? If so, according to a recently published survey, you’d lose that bet because your estimate is low. This means most chat users are sending the same password they use to access your internal e-mail and file systems in plain text across the Internet to public- and shared-chat services.
Another feature that the public instant messaging clients now offer is file transfers. Some even offer upload ability to a temporary Web server if your firewall won’t allow clients to connect. This means, for example, that you must manually configure your virus scanning software within each chat service independently or you have a vulnerability. InstantMessagingPlanet (
http://www.instantmessagingplanet.com/security/print.php/1470691) completed a survey in the fall of 2002 that included statistics on file transfers. The most surprising result I read was not the fact that 48 percent of those surveyed had accepted a file transfer within the six months previous to the survey. The surprise to me was that 15 percent of those accepted files came from unknown parties. Imagine an employee receiving a file transfer with the Klez, Nimda, or Slammer virus hitching a ride. Then imagine the subsequent effect on your internal network  maybe several times a month.
For an example, imagine a new fast spreading virus is brought into your infrastructure.  The Sapphire/Slammer virus, as an example, shows the speed at which it can take over your infrastructure much in the same way it propagated throughout the Internet. (
http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html)  This virus doubled in size every 8.5 seconds and infected most vulnerable hosts within 10 minutes.  Overlay that theory as a loose virus in your enterprise and you can see the possible results through file transfers.
Even worse, one of the biggest existing security holes is the passing of corporate data unmonitored and uncensored out of your network. After all, such file transfers can be set to automatically accept and send files upon connection. Imagine an employee placing confidential product or sales information in that essentially public folder, after which pretty much anyone can grab and download those files. The next most dangerous security hole is the users’ ability to do simple cutting and pasting of information into instant messages. Without any logging and filtering, data might be passing out of your enterprise by this means even as you read this article.

Plugging the Holes

Some corporations have set stringent firewall policies that only allow port 80 requests to access the Internet, in the hopes that this will eliminate use of public messaging clients. Unfortunately, the majority of those putting this finger in the dike also offer the capability of pushing requests over port 80 to the ISP’s servers. Some go so far as to offer SOCKS and proxy server configuration options with detailed help files.
The next preventive step some administrators take is to set the firewall to only allow requests that are generated by a browser to go through the proxy servers. But once again, the chat community has already overcome that restriction with a product designed to act like a browser request. Users even have the choice of what type of browser to use to present the chat request, to better trick the firewall into allowing the traffic (see figure 3). This product also lets the user install and run a proxy host that masks the Internet traffic and bypasses your filtering at the firewall level.
With so many dangers to allowing public IM products to operate in most environments, why don’t enterprises just lock them entirely out of the desktop environment and prevent anyone from loading them? Well, because such messaging services can be useful and productive when used responsibly in a business setting..
The Osterman Research study also examined some IM benefits and found that most companies using IM do it to maintain communication with remote employees. Improving overall corporate communications and reducing telephone use and expense were close behind in the reasons that enterprises employ IM. Other reasons for using IM are to provide quick answers to questions and the ability to share documents.
Due to the demand for IM for legitimate purposes, some enterprises’ efforts to manage it consist of simply creating Quality of Service (QOS) contracts for their users that include restrictions and requirements for presence and availability. Limiting the hours the user is available online, or restricting knowledge of IM’s presence to limited parties, is fast becoming a standard part of such contracts.
Corporations have numerous options for putting controls on use of public messaging clients. As mentioned earlier, many administrators think the most direct approach is to simply put port restrictions in the network that disallow access to the common messaging services. Although this can deter novice users, the chat companies themselves offer help files on how to reconfigure a client to bypass this restriction.
My first comment to the companies I visit is to suggest they put controls in place and possibly streamline the available client options. Basically, I’m advising the administrators of the network and systems to become even savvier about IM than their users. While a lot of administrators use IM in their daily activities, many don’t yet know all the tricks for controlling client usage  and for thwarting and client control workarounds. This means administrators need to take the time to learn details such as what ports the different clients access, when they access them, and to what host names the clients connect on the Internet.
Most commonly, the next question I hear is whether I can provide a list of these ports and hosts. As I mentioned before, there are so many clients available, you could spend quite a bit of time accumulating those options. But you can still affect the majority of users by learning about the top few services (see figure 4). A recent poll (available at
http://www.InstantMessagingPlanet.com) shows that of those surveyed, 37 percent are AOL users, 27 percent use ICQ (also owned by AOL and now integrated to talk to each other), 16 percent use MSN Messenger and 12 percent use Yahoo Messenger. The remainder used numerous other clients, such as Jabber, Bantu, EyeballChat and even NetMeeting for host to host calls. The only answer is to keep an eye on which chat clients your users access and educate yourself accordingly.
Something overlooked that I find important is the monitoring of employee chat when regulations mandate it. Because users are allowed to use online names, matching any name with a particular employee can be a time-consuming process. Some users employ more than three aliases that they use regularly depending on the chat service or time of day. Some are used for business reasons and some for personal. But such anonymity won’t protect your enterprise if some content that passes into your organization becomes the source of sexual-harassment or other inappropriate-content complaints.
Some third party vendors, such as Facetime Communications (http://www.facetimecommunications.com), are offering chat filtering software that operates via a corporate gateway. In this scenario, users can access public IM systems, but all traffic is routed out through the gateways, which provide monitoring for usage, content, and auditing, a necessity in today’s world of lawsuits and document retention.

Another Solution: Lotus Sametime

IBM/Lotus has stepped in to take the lead in business IM. More than 66 percent of corporations that have adopted any official corporate standard have made Lotus Sametime that standard. Among large organizations, more than 80 percent of the market share belongs to Sametime. IBM Lotus Software is currently rebranding Sametime.  The attempt is to make the name more recognizable in function.  The new names are Lotus Web Conferencing and Lotus Instant Messaging. (New to the enterprise market is AOL and Microsoft offering an enterprise controlled messaging environment based on their chat systems.) There have been other vendors in this space for some time, but these two are flexing their names in the public IM space as the largest providers to enter into the enterprise market. Of course, both also offer custom integration of the enterprise and public IM systems.
As I discussed earlier, You can control the security risks inherent in public IM systems by using a corporate-standard IM product. Lotus Sametime fits such situations well because it was designed with the following in mind:

Security
Directory integration
Secure chat sessions and meetings
Intranet deployment
Extranet deployment
Scaling with clustering
Chat Logging
Web services integration
Integration with other chat systems
Web meeting services

Lotus Sametime enables directory integration instead of relying strictly on self-registration. Administrators can use an existing Domino Directory or provide authentication through any LDAP server. This flexibility alone lets you integrate Sametime easily into environments that have Active Directory or any other LDAP service running but no secure chat services, without worrying about custom integration work. When you first install and configure Sametime it prompts you to choose which directory type to use. (You can always modify this later either direction.) This removes the anonymous naming capabilities of the public messaging systems.
Sametime also supports intranet and extranet deployment. Sametime behind the corporate firewall is a simple installation as long as the network infrastructure is in place. Placing a Sametime server in the DMZ is just as simple. While installing, you have the option to have Sametime tunnel requests over port 80 to reduce the effort of reconfiguring firewalls. (Note that some firewall work may be necessary to exploit all of the capabilities.) Sametime, installed with the default settings, uses numerous ports for all its capabilities. You can find a list of supported ports Technote #192384 at http://www.support.lotus.com.
You can even take this architecture one step further by connecting your extranet and intranet environments. Employees connect to the internal server while customers and partners use the external server in the DMZ. Sametime then has the ability to host a simultaneous meeting on both servers without having the users pass inside or outside of the network firewalls to share in that meeting. Presence may also be extended through both servers to enable secure IM.
Sametime 3.0 offers numerous enhancements in clustering and scalability. For example, 3.0 lets you provide a redundant infrastructure by creating Community Clusters of Domino servers. This lets chat clients connect to an alternate server if connection is lost due to server failure.
Also, for scaling purposes, you 3.0 lets you create Community Server multiplexers (MUX servers) that receive only Sametime client connections, which then connect to the actual Community Services on a Sametime server. This reduces the client connection load on the Sametime server, and lets you add additional MUX servers as demand increases. Each Sametime server then maintains only a single IP connection to each MUX, reducing the load considerably.
Sametime also enables geographic dispersion of chat services. For example, let’s suppose a national company with offices on each coast wants to deploy a corporate-standard IM service. Due to existing WAN traffic, having all users access a single point isn’t feasible. Creating Community Clusters on each coast and assigning users to the clusters by geographic region provides the necessary redundancy. Then by connecting the two communities you provide the scaling in one overall solution.
In addition, Lotus has introduced the Sametime Enterprise Messaging Server (EMS), which sits in front of Sametime clustered servers. This new server provides failover and load balancing while providing no Sametime services itself. It’s strictly used to manage large IM loads across numerous servers.
Through an API or a third-party utility, you can also log Sametime chat activity. This logging may be archived and indexed for searches if necessary. For those companies under federal requirements to maintain chat as well as e-mail records, this service is invaluable.
There are products for the public IM services available, but the user names chosen may not be easily matched to the users in your organization. (Please see “Lotus Business Partner Products with Name-Matching Capabilities” for a list products with these capabilities). You can write your own chat logging application by using some C++ programming and the API. Information on how to do this is available in Technotes at
http://www.support.lotus.com. I suggest starting with Technote #187707, which gives a very brief overview of writing your own chat logging support.
Sametime also brings secure, encrypted chat and e-meeting capabilities to further increase security of your messages between employees, or even between employees and customers through Web services on your corporate Web site.
As corporations merge and collaborate, you’ll likely begin to encounter different messaging systems from company to company. Sametime 3.0 now has the ability for Session Initiation Protocol (SIP). The SIP Gateway functionality and SIP Connector enable users in one SIP-enabled IM community to share online presence and IM services with another SIP-enabled community.
Taking that SIP connection a step further, you can then also add Transport Layer Security (TLS) to encrypt traffic between the two SIP communities. Although during a meeting you would see the open padlock in the corner of the browser (reflecting that a session was not encrypted), because the Sametime server cannot tell if the other SIP-enabled community supports encryption, the session can still be encrypted if the administrators both configure TLS. This configuration does require an additional server to handle the SIP Gateway. Sessions between the SIP Gateway and the Sametime server are also encrypted with TLS, and then a proprietary encryption is utilized between the Sametime server and Sametime Connect client (see figure 5). The SIP Gateway isn’t open to just any other community to connect to yours  you decide which other gateways are allowed to connect.
Sametime offers additional features many other consumer products don’t that may be useful to you. For example, Sametime provides Meeting Services with whiteboards, screen sharing, and audio/video capabilities, all integrated into the same server and with security wrapped around it.

It’s OK to Use IM  If It’s Secure

It’s not my intent to scare you away from IM. It has many uses and its importance will continue to grow. But what is important is that you realize that unsecured IM is a danger to the confidentiality of your enterprise information, and that solutions and compromises do exist that both support users’ IM needs while providing the security and control you need.
But in my mind, the best solution is to secure, standardize and implement a corporate standard for IM. A well-defined QOS plan that provides reliability, auditing, and filtering can deliver a business benefit and productivity enhancement for your enterprise. Lotus Sametime, in particular, has proven itself to be a valuable business solution for all of these needs.

Chris Miller is the Director of Messaging and Collaboration at Connectria in St. Louis, Missouri. A CLP in ND6, PCLP in R5 and R4, Chris has been working with Domino administration since 1994 and is just finishing his Lotus Collaboration CLP also. Some say he spends all his time behind a computer, but you can also find him on the soccer field — playing or coaching.


SIDEBAR Material:

SNAPPShot
by SNAPPS
http://www.snapps.com

Collaboration CONTROL!
By DYS Analytics
http://www.dysanalytics.com/prod_collaboration.php

IM Auditor Enterprise
By Facetime Communications
http://www.facetimecommunications.com/risk.shtm

Facet for Sametime
by Pistolstar
http://www.pistolstar.com/cmbr_st_reporting.html