Work with end users -- not against them -- to improve security

In his recent blog post, "The six consumer technologies that are destroying traditional IT," Jason Hiner comments on consumer technologies that are sneaking into the workplace and causing problems for some IT departments' attempts to maintain network and information security. He also makes the point that this isn't just a problem with end users who don't want to follow the rules — often, the end users are just trying to do their jobs to the best of their abilities, using the tools they feel would best suit their needs.

The problem is, to a significant degree, with the IT department. In other words, if there's a "civil war" between the IT department and the end users, it's because the IT department is trying to fight the end users, rather than solving the problems of their business needs.

The solution to the problem at hand is really a simple one: Don't ignore the end users' needs. When you do that — when you refuse to offer solutions to the problems of the modern workplace — the end users start looking for their own solutions. When those "solutions" end up circumventing your network security policies, you need to start looking to yourself for someone to blame, because you could have helped your end users solve their problems without compromising network security, but you didn't.

Let's take a look at one of Jason's examples of consumer technology that's destroying traditional IT — instant messaging.

Instant messaging technology is an incredibly useful resource for exchanging information in "real time." IT professionals in particular are increasingly finding it useful for their jobs, conferring with one another about the knowledge needed to solve their daily work tasks. Where once a network administrator may have had to hunt through half a dozen books on his or her shelf to find a specific reference to subnetting with IPv6 that he or she saw a few months back while looking for something else, now he or she might be able to just ask a question of his or her IPv6-enthusiast friend working for another company and get an immediate answer.

I know I've done this sort of thing hundreds of times while working on Web development projects, configuring firewall/router systems, and otherwise plying my trade. Sure, I'll probably go back to the book and read up more on it later, but for right now it's nice to be able to get a quick answer from someone who knows the material better than I do, without having to put my work on hold while I search through books and Web sites or wait for a response to an e-mail that may get hung up in spam filtering at the other end (just wait until I address my pet peeves with spam filtering in a later post).

Many IT shops just treat IM as another bit of prohibited software, an attack vector they don't want to have to deal with. In many cases, the IT department workers prohibit IM use for the rest of the company but use it themselves to solve their own business problems — and they don't realize that it's not just the unique problems of the IT department that can be solved by talking to other people online in "real time."

Whereas a blanket prohibition policy may lend itself to security breaches as people circumvent IT policy so they can improve their ability to get the job done quickly and easily, a policy with exceptions for the IT department can be even worse, as IT would then probably tend to assume the its own workers know what they're doing and ignore the matter of securing IM sufficiently. We really need the additional concern of figuring out how to make IM secure for the rest of the company, or we may not be motivated to think about how to make it secure for ourselves.

Typical security concerns involve plain-text transmission of company secrets, IM-borne viruses, and an unmonitored point of access to the network.

  1. Point of access: As long as you have a policy in place that allows for use of IM but only with the IT department's knowledge and blessing, you've created a policy that will encourage workers to coordinate with IT rather than try to "get away with something." When they're trying to go behind your back, end users will be trying to hide their online activities from you, which means you're going to run the substantial risk of missing important, potentially threatening network traffic for long periods of time. Working with end users, rather than against them, will ensure that you know what's going on, and those end users will be inclined to follow the rules rather than break them if they can achieve their ends within the bounds of IT policy. It's a win-win situation, if you handle it responsibly, so start handling it responsibly right now. Just remember that the more contentious you make the relationship between IT and end users, the more they'll want to fight your policies.
  2. Malware: By instituting a clear corporate IT policy for IM, you get to set the rules for what people will use and how its use will be managed. This means, among other things, that you can institute policies that will minimize the potential malware contagion vectors of IM software. For instance, mandating specific client software choices and IM protocol limitations can help provide you with an easier time monitoring the security status of the IM software being used, allowing for better ability to respond to vulnerability discoveries via workarounds, coordinated patch rollouts, and even temporary IM use lockdowns when there's a problem so big and intractable that IM traffic needs to cease until there's a fix. If everyone in the company knows that they're normally allowed to use IM, after all, they'll be more likely to do what they're told when you want them to stop using IM for a day or two for purposes of avoiding a major security problem that could very well be their fault if they ignore IT policy.
  3. Plain text: For the most part, IM protocols transmit all communications in "plain text," also known as "clear text." Many IM clients these days provide options for encryption, however, which can be used to secure communications somewhat. This can be especially important when two employees of the same company are communicating with each other, discussing matters that should not be made available to the outside world. Many people aren't even aware that encryption is an option, and they don't realize that their communications might be subject to eavesdropping by an outsider; not everyone's areas of expertise are related to information technologies. If you simply disallow IM use company-wide, people who are inclined to use IM in violation of company policy will not be likely to get the guidance they need to do it safely — but if you provide clear policies allowing IM use within certain restrictions for security purposes, everyone will be able to benefit from your expertise.

On the subject of IM security, examine all your options for the best fit for your company. For instance, considering the above three concerns that might prompt you to allow (coordinated, managed, secured) IM use within the company, you might develop a policy with the following characteristics:

  1. Only the Pidgin client is allowed. This provides greater ability to centrally manage software updates, monitor network activity related to IM use for signs of unauthorized traffic, and support IM software on the end-users' workstations. As a feature-rich, multiprotocol client, it should keep your users happy and serve your needs regardless of what general policy choices you make.
  2. Only the AIM protocol is allowed. Again, this increases your ability to monitor network activity related to IM use, but it also provides the ability to better firewall against related, but undesired, traffic. It also keeps necessary attention focused on a narrower range of potential security issues than if you try to pretend that nobody is using IM on your network at all, by being aware of all IM protocols in use on the network.
  3. No communication without encryption is allowed. This may appear to be a bit on the paranoid side, but it will surely be necessary for some companies. If you are careful to enforce it, perhaps with monitoring of communications via IM-specific ports for signs of policy violation, end users will probably find that it's better to comply — especially since using encryption with IM is not as difficult as it might sound. For instance, Gaim comes with a built-in encryption capability — and anyone an employee wants to talk to should be able to employ encryption as well with a minimum of fuss. There may be some incompatibility issues between specific companies with differing policies, in some cases, but you have to determine the security needs of your own company and develop policies that meet those needs. If that requires use of only approved encryption technologies, end users will simply have to learn to live with that — and with a specific policy in place, it will be much easier to detect policy violations quickly enough to head off any potential security breaches.
  4. When choosing your security technologies, examine the alternatives before settling on the first thing that jumps out at you. Ask yourself questions about how secure a given encryption technology is and similar questions. For example, the built-in encryption capability of Pidgin is good, but it may not be good enough for your purposes. Perhaps you should be using the OTR plugin with Pidgin, which provides what its maintainers call "perfect forward security." OTR provides not only encryption and identification of users on the other end for greater integrity of trusted communications than with most encryption capabilities, but it also ensures that even if a given conversation's encryption key is intercepted, that won't help the unauthorized eavesdropper compromise any further conversations later on.

The same sort of approach to software policy that works for IM can be extended, in terms of the principles involved, to apply to the other classes of consumer technologies in the workplace mentioned in Jason's article. Remember that security is more a matter of how you think and how you apply policy than of following a checklist to get from point A to point S, where S stands for "secure."

One of the principles of security that you must learn to apply in your professional life is that of getting your end users to work with you rather than against you — by making the effort to work with them to solve their problems and meet their business needs.


Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

Editor's Picks