How to Write an IM Policy (part 2)
Tags :Sametime IM Policies E-pro Magazine
Administration and Strategy: How to Write an IM Policy (Part 2)
Last time we investigated an outline of the reasons an enterprise would want to invest the time and effort into creating a policy specific to instant messaging (IM). We covered the why, who, and how often of IM policies. This month, we explore implementation. Based on some of the reader feedback so far from the first one (big thanks to everyone demanding to know when this second part was coming out), I might even take all the extra loose thoughts and wrap them into a third part. I would like to point out that Christopher Byrne did write some nice blog pieces (including a follow up) on this topic.
One thing I plan to stay away from in this article is citing specific products or companies that provide these services. I know some of the products personally, some from reading about how they operate, and others from the marketing materials only. The key of this article series is the actual implementation itself and not necessarily what you choose (or if you choose) to use in terms of a third-party product. One other thing I am not touching in this issue (although maybe the next), is the legal aspect of logging and auditing. There are reasons that some enterprises are required to log all the chat traffic, while others simply want to monitor what types of information are being shared.
What Should I Tell My Users?
Well, isn't this a conundrum right off the starting blocks? Spying on the employee makes the employee feel untrusted in their work environment. When it finally comes out that you are logging, watching, or auditing chats without telling them, sit back as they stop using IM or turn to public encryption (like the new AOL can offer). If this was a controlled 'work only' system, such as Sametime, how much productivity would be lost if the users ceased sending IM messages? How much would phone expenses go back up? I know these might seem like silly things to think about. The company controls the network and resources right? The employee can't control if you want to audit and archive chats. But they can stop using it if they feel it is untrustworthy or that you don't trust them.
What is it you should offer in terms of information to the employee then? I believe this can be a simple as a one-paragraph explanation. Let everyone know what is being logged. Is it based on keyword, who starts the chat, or is it every line typed? Do you show what files got transferred in or out of the company? The more you clarify, the less surprise later. If certain behavior is not tolerated, specifically state what actions are not, such as installing unapproved IM clients (even though this falls under desktop and network policies) and what the consequences are. I had a conversation with one company following part 1 of this article that had put the beginnings of a policy in place. It stated what was acceptable plain and clear. Yet there was no mention of what actions would be taken against the employee if these guidelines were not adhered to. Without the consequence, you do not have much ground to stand when reprimanding the employee.
How Do I Control Deployment?
The worst nightmare for your technically savvy users is controlled desktops. The best fantasy for the IT group is controlled desktops. So looking for that common ground, how about Web versions of the IM client? This way there are no downloading or installation issues. Patches are instant the next time a user logs in and controls can be set centrally for many aspects of functionality. Browser version and security controls are what you would have to deal with. But I already know everyone is doing that for the security of the users already. Right? In Part 1, I mentioned that everyone is going to be affected by this policy, so everyone should be affected by the implementation as well. Letting certain groups or people not fall under the guidelines set by policy leaves the enterprise itself open for legal and internal troubles.
Suppose the product you select does not have a Web version? Packaging is a great way to control what is installed on the desktop. If you are using Sametime and have not played with the Sametime Client Packager, then you are missing out on a neat tool. It will walk through the install package letting you pick and choose the parts. You can then build a few different packages, for example, if you want one group to have file transfer ability and not the other. Notice that everyone here still falls under the same policy, you are just expanding functionality to different users, creating a totally acceptable and fairly applied IM policy.
What Choices Do I Have For Implementation?
This is where you get to have some fun as an administrator: trying out the different options. Many vendors today are pushing towards software that gets installed on the instant messaging server to log, audit, and restrict chat sessions. Others take the approach of a network device that all traffic is funneled through like a gateway.
Taking the theory of the software approach that gets installed on the IM server, you have a few considerations. One is revisions and updates. How fast will the vendor supply new versions when the IM software vendor has you upgrading and applying fixes? If the vendor cannot be as aggressive in upgrade cycles and support of newer versions, you could be left behind. How many times has this happened in your environment already where you cannot upgrade due to a software package installed? Also, unless you are funneling all type of traffic somehow through this IM server, you really aren't preventing or restricting access for the other chat products. Getting an integrated product that supports logging of multiple IM products doesn't make much sense as you are then loading your primary IM server(s) with additional load from other chat services. That will lead us into the topic of the gateway products.
The good side of an integrated product is that it all runs (mostly) on a single piece of hardware; the administration interfaces are complementary or similar to the IM software you are running, and it has good interoperability with the IM software. Also logs and audits are easily performed as the data resides on the same server.
We also have gateway products, which are separate devices that sit on the network and can be as passive or aggressive as your enterprise desires. I have mixed feelings on this type of implementation (then again, I have mixed feelings on both types). The ability to funnel all the traffic gives you a central point for logging of all types of IM, and many vendors have multiple chat product support in one device. This also gives you granular control in turning off one or more chat products and a single interface into all the logging and auditing.
One other key feature immediately comes to mind: if the gateway device supports it, you can utilize LDAP or name space mapping to your internal infrastructure to log certain users and know what internal name maps to what external name across all the product lines.
With all those positives (and there are more), I get asked what could be negative? The primary example to give is that if this device fails then all chat logging, auditing, and outside access can be lost in a single gateway implementation. Essentially this could shut down IM until a fix or repair is put into place. How detrimental would that be to your productivity? This needs to be weighed heavily. The maintenance on this additional piece of hardware may outweigh the demand for having it, for some smaller shops. But for larger implementations, it is a viable solution with many options.
Conclusion
While writing this second part, I received another e-mail asking if I had a template or standard document they could work from. Interesting as I don't think I would want to base my unique enterprise on someone else's standards. I do understand the desire to have a place start in thinking and writing your own policies. I will take that debate back and see what I come up with. Who knows, by the time this article series is done, we might have explored everything from why to write one, what gets included, legal aspects, user experience, and an actual template. Then again, maybe this is enough for you to start your own already. IM me at IdoNotes and let me know... that is if your policy allows unrestricted outside communications. :-)
blog comments powered by Disqus
On Thursday, October 14th, 2004 by Chris Miller
