E-Pro: Quenching the IM Thirst with Sametime-Ade
Tags :E-Pro Articles
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
blog comments powered by Disqus
On Thursday, May 1st, 2003 by Chris Miller