Security Advisor

Users: The Weakest Link

Bad things can happen when administrators don't put their users first.

• By Joern Wettern
• 11/01/2007

The instructor of my first networking class gave us a lesson completely unrelated to technology. He stressed that a network administrator is the king of his network and that a user's proper role was to act as a serf who has to bow to the king and beg for needed services.

You can still find such attitudes today, but networks in well-run organizations revolve around the employees' needs and on admins who place users at the center of their thinking. There are good business reasons for doing this, but making users a top priority in both your planning and day-to-day administration also helps make your network more secure.

There's no better way to illustrate this than with the following examples. Each of the tales I'm recounting here actually happened to a family member or close friend (the names have been changed to protect the innocent -- or guilty, as the case may be). Each of them illustrates how ignoring users can be detrimental to network security.

Communication Breakdown
It all started with a phone call from Fred's office. Fred and his co-workers suspected that a virus was spreading around their network, but they couldn't reach the network support team because they were offsite for training. Would I be able to give them some advice?

Sure enough, the company was badly affected by a fast-spreading virus. The best advice I could give was to turn off all computers and wait until the support staff got back to the office.

Early the next day, the network administrators and support personnel got together for an emergency meeting. After some immediate damage control (which included blaming the virus infection on an outside vendor), they came up with a plan to get everything working again. By the end of the day, they were ready to implement this plan and mentally prepared themselves for a long night at the office. After most employees had left for the night, the IT staff started moving from computer to computer and re-imaged each and every hard disk.

By the morning the virus had been eradicated and their problem apparently solved -- at least as far as the IT department was concerned. However, everybody else's problems had just started. Many in the company naturally had stored documents on their hard drives. As they started work that morning, they discovered that all of those files had been permanently deleted when the hard disks were re-imaged. The help desk got some angry phone calls, but they simply pointed to a year-old memo that had advised users to store important data on a server.

It's fairly obvious that the problem here was the lack of communication. Network staff assumed that sending out a memo would magically ensure that users stored data only on servers. Some on the IT staff were probably happy to have taught users a lesson about complying with policies.

Talking to users and finding out what they really did would have alerted the IT department to where data was actually being stored. With this knowledge, they would have known to warn everyone about the re-imaging or made a plan for backing up user data.

This entire episode has serious security implications. After the incident, most users didn't trust network admins with their data. Instead of storing important files on servers or local hard drives, many now copy these files to flash drives that they take home at night. This raises the risk of confidential data getting lost or falling into the wrong hands. Even worse, the mistrust created by this episode will make it difficult in the future to get employees to comply with any security policy, no matter how important.

Beware of Britney and Paris
When Laura opened her e-mail, the first item was an urgent message from the mail administrator who had detected a sudden increase in incoming virus-infected e-mail. Some of these messages had subject lines relating to Britney Spears or Paris Hilton. The mail administrator urged users to be extra careful and to not open any suspicious e-mails.

This e-mail is a classic example of how IT staffs often communicate with the rest of the company and why it's ineffective. First, the memo was really about a problem experienced by the mail administrators -- not the users. The flood of infected e-mail was causing problems on the mail server, but all these messages were being stopped by anti-virus software. The memo caused employees to worry about something that wasn't actually affecting them.

At the same time, the memo didn't contain enough information to be useful. There were no guidelines for helping users determine whether or not an e-mail was "suspicious." Based on the memo, the one thing to watch out for was a subject line referring to Paris or Britney. The logical conclusion was that it was safe to open messages with different subject lines.

Unfortunately, user education about network security is often not relevant to the audience. It doesn't give them the information they really need. A better approach here would have been an ongoing effort to educate users on how to detect and react to potentially dangerous e-mail messages.

Secure Yourself
Susan just attended a training session on e-mail security. Because the government agency she works for requires that client communications remain confidential, her agency implemented a new solution for sending encrypted e-mail. Now, whenever Susan sends a message that contains any confidential information, she needs to add **secure to the subject line. The mail server then encrypts all messages with that subject line before sending them out.

This mode of encryption has some basic security flaws. It depends entirely on users to decide what's confidential. It also doesn't work when a user mistypes **secure. A good encryption solution doesn't rely on user judgment. Instead, good e-mail encryption implementations use an automated process on the server to decide whether or not to encrypt a message. You can configure the server to make this decision based on message content or intended recipient.

While there's nothing wrong with empowering employees to encrypt data they consider important, this should only be used to augment a process that enforces encryption when it's required.

Next month, we'll look at more security considerations that revolve around the most variable factor in your network -- the users.