Tech by PC

Computer and Internet policy in the workplace, Part 2: The Ideal Policy

The ideal policy must balance productivity. It has to focus on actual results of policy change, not a theoretical ideal. First, you need to identify what problem you have that you want to develop policy to solve. Policy for the sake of policy is worthless. Once the problem is identified, say your employees are spending too much time on webmail, then develop a policy to counteract it, working in small steps at first. Next, evaluate your small-step policy change. If it has accomplished what you set out to do, then do not proceed any further. If it has not, then take another small step. The goal is to rarely backtrack on policy. If you have to backtrack then people will lose respect for the policies you implement and further policies will need to be even more drastic in order to have any effect.

Identify the Problem

This is most important for an ideal policy. Each policy has to be addressed at a problem, have a goal for resolving that problem, and effective measures to determine when the problem has been adequately solved. Take the problem of web based personal email during company hours for an example. The easiest thing to do is to use Websense or similar to block all web based email. The employees immediately lose access to it and become the productive pencil pushers you want them to be, right? Not quite.

Personal email fulfills a desire for the employee that has always existed in the workplace. Communication with friends and family can happen through land based phone, cell phone, email, non-email based web communication (Facebook for example) and any number of other Internet technologies that are not web based, not to mention your official email channels. If your employee has a tendency to waste time communicating with the outside world then turning off web based email will not effectively stop that communication. In this case, policy directed at improving employee productivity needs to focus on the larger problem and not on web based email as a specific. Simply cutting off web based email will leave the employee scrambling for alternatives, many of which will be less desirable than the web based email was. Put it this way: Would you rather have your employee read an email from a spouse saying to pick up some groceries on the way home or have that employee or spouse call multiple times during the day to find out that same information and talk on the phone for much longer than it would have taken to read that email? What makes your business more efficient (email communication) also makes your employee’s personal lives more efficient.

Focus on identifying the problem more specifically. How much time do your employees spend on web based email? The answer is not necessarily as straightfoward as it may seem. You can pull a websense log, web proxy log, or browser history and you may notice at first glance that the user is using webmail from the time they get in to work until they leave in the evening. Most webmail is dynamic, AJAX, or refreshes on a regular basis. A user could open gMail or Yahoo Mail in the morning and have a continual record of activity until they close it in the evening, even if they do not spend any other time looking at the mail during the day. It would take some deeper analysis of the hits than just a surface glance in order to tell exactly how much time the user spent in webmail that day. Is web based email an exclusive activity that the user participates in, or does he multitask? This is also an important question, and not one that can necessarily be answered by looking at the logs. The user dials a phone number and clicks on their browser while the phone on the other end rings. He opens a few list mails to glance at them and then deletes them. The person on the other end answers and he goes back to 100% work mode, abandoning his browser again. Has that employee been any less efficient by looking at his email during those few seconds? Maybe you wanted him to be looking at his work email instead, but most likely the answer is that there is nothing wrong with that sort of behavior. In this particular instance we still have not determined a way to effectively monitor his inefficiency due to web based email.

Hopefully by now you will have realized that this problem, employee efficiency, is not a computer policy problem. It is an employee management issue that has nothing to do with computer policy. If you can’t trust your employee to spend time on the computer properly, then you have to evaluate how far you can trust that employee to do anything.

Let us take a real computer policy example now to identify the problem and a solution. The problem is viruses and spyware from web based email sources. One assumed vector of attack to your organization’s security is that web based emails show up on the user’s PC without first being scanned with corporate email filters and virus software. Various techniques such as SSL, or source files from a trusted web resource means that both user PC and gateway devices pay no or less attention to the data coming from these sources. Policy in this case may be as simple as limiting web based email to a few trusted providers. Yahoo! and gMail both do a good job filtering bad attachments, and both are free and able to check external email. Thus limiting all web based email but whitelisting gMail and Yahoo! allows you to have the best of both worlds. In addition to this policy should be a centrally managed virus and malware solution. There are many different vendors who provide these products. An employee complains that they can’t look at their ISP’s email, point them to the POP retrieval option on Yahoo! or gMail. With those options it is unlikely that employees will look for something else.

Identifying the problem is as much about identifying whether or not the problem is a computer policy problem or a management issue as it is to determine the correct course of action to solve it.

Small-Step Policy Change

Our example is pretty simple, but a small step approach can still be taken to ease the users into the policy. In the above example we want to turn off all web based email and whitelist gMail and Yahoo!.

Step 1 is user notification. A broadcast email about the proposed policy changes with sufficient data backing up those reasons is the first step. Attaching a document with a full argument, case studies, and methods for enforcement of the eventual policy is sure to be read by pretty much no one. The advantage of publishing this much information is that employees will be less likely to challenge something that has obviously been thoroughly evaluated. If there are solutions to their individual problems listed, then they won’t bug local IT staff or HR. Provide a cut-off date for web based email and give the users plenty of time to set up their Yahoo and gMail accounts at home.

Step 2 is enforcement. Send out another reminder email saying that you are turning on the policy. Send the document or a link to the document explaining the reason for the change and solutions around the problem. Then turn the policy on the exact second that you promised to turn it on. You can be sure there will be people waiting to test your policy in the minutes and hours immediately after enforcement. If you want to appear incompetent then wait a few more days.

Step 3 is evaluation. You will have missed something in your initial deployment of this policy. Someone has a web based email server that websense doesn’t know about. These small operations are much more dangerous than the ones it does know about because you are at the mercy of the individual running the web server. All it takes is for one employee to find that server and start spreading information about it to co-workers. It should be understood that using webmail beyond the cutoff date is not a computer policy issue but a management issue. All IT policy must be enforceable by HR just as it is enforcable through IT. “Well, you didn’t block it, so I figured it was ok” is no excuse. HR action should take place simultaneously with IT action during step 3.

Do NOT Backtrack!

It is vital that policy is not undone after it is implemented. If you followed the above steps then there would never be a reason to backtrack on a policy. Note I didn’t say that there might not be exceptions made, but there should never be a reason to reverse an entire policy. The CEO uses web based email from linuxmail.org and insists that he should still have access to it. Well, besides being a cool guy for being linux friendly, your CEO could also get an exception to the policy for his account or for the linuxmail.org domain. A complaint from the CEO should not cause the entire policy to be reversed.

Remember that document I said to send out in your notification email? Well it did not come out of thin air. You should have thorougly evaluated the policy, consequences for and against implementing it, and made a solid business case for the policy. All general issues with the policy should have come to light during this stage. Your due diligence including the inclusion of many different organizations into the development of the policy is a key to this process.

Backtracking in general has the effect of lowering user’s opinion of the IT department and its policies. The perception is that IT did not do enough research, have the knowledge or ability, or that it did not have the support of management. Any of those simply encourages users to continue to test the limits of what they can do. The best policy is the policy that you do not have to enforce. Along the same lines, make sure you have the technical ability to enforce any policy that you attempt to install. The only thing worse than the users thinking that IT is incompetent is if they are right.

Team

For the bonus section of this article, being a team is key. Individual IT workers will be approached by employees that are friends or for any other reason with the intent to pull information out of the worker. It is important that IT maintain a unified front on the legitimacy of the policy and not provide users means to go around the policy, or details about how the controls in place to enforce the policy. This is defense against a mild form of social engineering. Users will be glad to know that their favorite IT worker is on their side about a policy issue. They will see it as a weak spot where they can gain a foothold to either find ways around the policy or to interfere in policy creation in the future. Teamwork needs to be employed by management as well as the workers. Users will attempt to get around the system far less frequently if everyone they talk to feels that they should be following the policy.

Perhaps the most damaging of all team and backtracking issues is when the individual IT workers stand up to their peers only to have IT management backtrack on an issue and overrule the policy. I have seen this happen many times in different job situations where management expects the workers to run interference and keep all but the most important issues away from them, yet every time an issue makes it through, there is a policy change or an exception made. Not only does this make it more difficult for the worker to do his job, but word spreads that if you want something done in IT you have to go directly to management. IT management then has ineffective interference because people know not to bother talking to anyone but them.

Implementation techniques will be discussed in part 3.

This entry was posted on Sunday, January 4th, 2009 at 3:30 am and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.