While we need to monitor our employees to protect organization secrets, there's no need to turn the workplace into a bad episode of Big Brother

Rich Mogull, Analyst & CEO, Securosis, Contributor

January 15, 2012

5 Min Read

In my previous post, I talked about all of the nifty tools we have at our disposal to identify, monitor, and protect our information. But here’s a dirty secret: Every single one of these things monitors what your employees are up to. And any good data security strategy includes even more tools that I left off of my list since you probably already use them.

I realize you probably think that I think you’re an idiot for even bringing that up, but I hate to admit that I’ve worked with folks who don’t realize that when you’re monitoring data use, you’re also, sort of, monitoring employee activity. A couple of years ago, I remember talking with an organization that called for help in defining their DLP policies. The conversation went something like this:

Caller: We need help defining our DLP policies.
Me: Great, have you talked to legal and HR yet in case you need to discipline or fire someone?
Caller: Why would we do that? We just want to protect our data.
Me: Well, you understand that you’ll be monitoring employees, right?
Caller: Oh no, we don’t want to watch employees, just data leaks.
Me: Er ... you realize that computers don’t leak data, people do? Kinda like guns don’t kill people ... Caller: Me: When are you picking a product?
Caller: We already picked . It’s been running for a few weeks with all the policies turned on but we need your help defining our process before anyone looks at it.
Me: (crickets)

Our challenge is to monitor employees without having them feel like we’re sifting through their closets looking for their burn box (OK, maybe those are a guy thing).

There are really only a few verticals and companies that need or want to keep track of what every employee is doing on their computers at all time. The rest of us only want to know when someone is doing something that violates a policy and puts us at some sort of risk. Fortunately, most of the modern tools are designed to handle this.

Here is the process I recommend for implementing any kind of employee monitoring ... or updating your current monitoring even if it’s as simple as URL filtering.

The big key to providing employees privacy without increasing your security risk is to rely on event-driven policies. Investigators and managers shouldn’t be allowed to track everything an employee is doing and peek in whenever they want. This is where you open yourself up to legal risk or make your employees feel like they are living in a bad reality TV show. Create discreet policies that rely on technical triggers.

While there are some areas where you need to track more than that (database and file activity, for example), just be clear on how the data is handled and who can see it. For example, I generally advise against providing this data to business unit managers wanting to use it to measure productivity.

The first step is to figure out whether monitoring is even legal, and, if so, there are any limitations. This is mostly an international issue since some countries have various employee privacy laws (don’t worry, you can do pretty much anything you want here in the good old US of A).

Next, you need to check any employment, contractor, or union contracts. And by “you” I mean “your lawyers.” Again, this is typically not an issue in the U.S., but it’s also not the sort of thing you want to get wrong.

The next step is to determine your policies and procedures, then map them to your technology options. For example, if you are using Web filtering or DLP document, what kinds of activity are you monitoring, what activities will violate policies, and the process for handling and escalating violations. You have to map these to technologies to ensure you are actually able to follow and enforce your own policies at the product level.

Here’s a quick example. Your policy might say you monitor all outgoing network traffic for credit card numbers. If a number is detected, then your tool will collect and store the activity during an investigative period. This information is accessible only to investigative staff. If the activity is believed to be accidental, then here’s the process to work with the employee and manager to remediate. If it were malicious, here’s the criteria for involving management, HR, and legal.

In general, policies will include requirements for how data is collected, what’s collected, who can see it, how long it’s stored, and strict guidelines for handling it and escalating to management.

Once you set those up, document everything in human-readable language and notify employees what you are about to do. Better yet, have them sign the policy so you know they know there’s going to be a little brother watching. No one likes anyone sitting over their shoulder, so in that notice be VERY clear that you are only watching for things that put the business at risk, you strive to minimize what data you are collecting to respect their privacy, and you have tight controls over the data.

The rest all comes down to technology implementation and keeping things consistent and updated over time. Uses the policy and detection features of your tools rather than collecting a ton of stuff and manually looking for problems (not that I’ve seen this happen in recent years).

And remember, practically speaking, users already assume you are watching at least some of their activity on corporate networks and applications. The big focus here is when we start collecting data on their computers, email, Web browsing, and other areas that tend to see some personal use.

To review: Make sure it’s legal, set clear policies and boundaries, notify the employees, and rely on technical rules/policies for things that create a risk to the business. As much as people still might not enjoy knowing activity is being watched, at least they know you are making the greatest effort possible to balance personal privacy with business needs.

Rich Mogull is is founder of Securosis LLC and a former security industry analyst for Gartner Inc.

About the Author(s)

Rich Mogull, Analyst & CEO, Securosis

Contributor

Rich has twenty years experience in information security, physical security, and risk management. He specializes in cloud security, data security, application security, emerging security technologies, and security management. He is also the principle course designer of the Cloud Security Alliance training class and actively works on developing hands-on cloud security techniques. Prior to founding Securosis, Rich was a Research Vice President at Gartner on the security team. Prior to his seven years at Gartner, Rich worked as an independent consultant, web application developer, software development manager at the University of Colorado, and systems and network administrator. Rich is the Security Editor of TidBITS and a frequent contributor to publications ranging from Information Security Magazine to Macworld. He is a frequent industry speaker at events including the RSA Security Conference, Black Hat, and DefCon, and has spoken on every continent except Antarctica (where he's happy to speak for free -- assuming travel is covered).

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights