Security

Basic principles of network security, part 2: Winning the hearts and minds

If you don't introduce your users to a new security policy properly, they may feel as though they're being arrested. In part two of this series, Chris Dinsmore explains how you can avoid this negative situation and prepare your users to accept your security project.

Have you ever been arrested? Do you know what that’s like?

Well, first they spin you around and push you up against the wall. Then, they handcuff you, read you your rights, and charge you. They take you down to the station and book you, during which time you are just another number. They fingerprint you, throw you in a cell with nothing to do, and generally ruin your day.

Guess what?

That’s how your users are going to feel when you introduce your new security policy. Sure, it may seem like a great idea to you—everything secure, no information going anywhere without permission, everyone authorized and identified—but to your users it’s just another thing getting in the way of their jobs, especially if your users are smart and computer literate.

Your worst nightmare
What’s the biggest nightmare for a security administrator? His or her own users—if they happen to be UNIX programmers. These people think it’s fun to take systems apart and put them back together in ways that you don’t even recognize. Believe me, I know; I’m one of them. Security admins are always trying to take away my cool stuff. Like that password-cracking utility I used one weekend to get root on all the local servers when I couldn’t be bothered to find the admin. Or that server exploit that lets me remotely control my desktop through the firewall in case I need any files while I’m at home.

Now, do you see what I mean about your worst nightmare?

Here’s a situation for you. You’ve just defined the perfect security policy. Nobody in to the network but the admin, nobody out except for e-mail and surfing. Then, over golf one day, somebody tells the CEO how great pcAnywhere is and how he should have it installed so that he can look at his files from home. The CEO thinks it’s a great idea and immediately orders all the executives to get pcAnywhere installed on all of their systems, especially their laptops. That way, anybody can get files for and from anybody, anytime, anywhere. After all, it’s encrypted, and it will make the sales force a lot more productive.

Then, your CEO’s laptop gets stolen. He kept a list of all his passwords on that laptop. (He’s always been a little absentminded.) Of course, a few months ago, he asked you to set it up so that his programs remembered all his passwords and he wouldn’t have to log in. Oh, and he didn’t tell you that the laptop was stolen for two weeks because he was in the Cayman Islands on vacation.

Now, you really see what I mean about your worst nightmare.

Both of these situations are real, and they happen in companies large and small every day. You may have seen on the news a few months ago that an intelligence agent had some top-secret government files stolen from him. He had apparently left them on the backseat of his car while he was having dinner, and some thieves smashed his window and took all of his belongings. They probably weren’t looking for the papers, but who knows? You have to remember that anything can happen. Nothing is impossible—improbable, but not impossible.

Creating a security-conscious environment
I do have a point here. I’m convinced that the only way to help prevent situations like this—and especially to prevent that “imprisoned” feeling that can accompany a major security project—is to create a security-conscious environment.

In “How to stop an intruder: Basic principles of network security, part 1 ,” we discussed developing a well-defined security policy and examined several of the important concepts in creating your defensive strategy. Now, we’ll look at what’s probably the hardest part (or at least the easiest to screw up): putting it all together and implementing your security project. You have a great security policy and a strategy of defense; now, you need to implement it, putting everything—and everyone—into place to ensure that your information remains secure.

As I said, I think the most important step, and the one that most people miss when implementing a security project, is to create a security-conscious environment first. What that involves is getting your users to think about security. We don’t want everyone to be paranoid, walking around like a bad X-Files episode; that’s just bad for business. What we want is for your users, and especially your management, to understand just how critical security is to your mission, to your business, and to your company. Intelligence agents have a term for this concept. They call it Winning the Hearts and Minds.

I’ll be the first to admit that it’s a heck of a lot easier said than done—especially here in America, where we don’t take kindly to restrictions on what we can do or say. Unfortunately, that’s a lot of what information security is all about. Americans as a whole are pretty likely to go and do exactly what you told them not to do, just to show you who’s really in charge.

Getting management buy-in
So, how do you deal with all these ideas?

What you really need to do before anything gets off the ground is to get 100 percent management buy-in. And when I say 100 percent, I mean it. If your users find out that their bosses can get e-mail from home and that they can’t, you’re going to have a riot on your hands. Your security policy has to apply equally to everyone—from the CEO to the office gopher.

But it goes a lot deeper than that. From moment one, you need to involve your company’s strategic decision-makers. Help them develop a personal interest in this project and an understanding of what it means to the company as a whole. Remember to keep everything documented in plain English and be ready to explain everything that you are planning or doing. Hold regular meetings to go over the planning and progress of the company and invite anyone who’s interested to attend. I know that massive meetings are a pain, but you can ask users to limit their input until you finish your presentation. And by all means, take whatever they have to say to heart. If you don’t, they won’t follow the policies that you have carefully planned.

And don’t forget the other IT staff. If you work for a big company, there’s nearly a 100 percent chance that everything you do as a security administrator is going to be cutting across a lot of other admin types’ territories. Trust me, these people can be your greatest allies—or your greatest enemies. You need to have them personally involved every step of the way, or you’ll never complete the project. It’s going to be difficult for you if you can’t convince the server admin to give you the machines that you need in order to set up firewalls and security analyzers. It will be even harder if the router admin won’t set up routes to your machines. Treat these people as a vital part of your team, even if “officially” they aren’t.

Involving your users
Now that your back is covered with management when something goes wrong and the executive suite isn’t going to cry in alarm when you make them remember passwords, what’s next?

(Cue scary music.)

Users.

That’s right. We mean all those people who actually do the work from which your company derives its revenue. No matter how important you think you are to the company, it’s your users who do the work, get the sales, and put the money in the bank. Don’t fall into the standard administrative traps. Every time that I hear so-called administrators call a user a “luser,” I want to smack them. (Read Tuxedo.org’s Jargon File Resources if you don’t know what I’m talking about…or even if you do. It’s hilarious.)

Security people have this annoying tendency of forgetting that there’s no point in making the network perfectly secure if it means that your users can’t get their work done. Users, on the other hand, tend to look at any inconvenience or change in the way that they work as a prime example of the electronic equivalent of bloody murder. Somewhere, somehow, you need to meet your users in the middle. Here’s how you start.

As you start planning your security project, send an e-mail to the entire company (or whatever division you are responsible for) and ask users to list all the programs that they use and which sites they visit. This list serves three purposes. First, it involves users in the process, making them feel like they have a stake in the results. Second, it helps prevent users from getting angry when you turn on the firewall because you already know what protocols and destinations they need. Third, it gives you a written record. That way, when users start screaming at you because you broke their programs, you can say to them, “But you never mentioned it when I asked what people used.” Then, piously show them the e-mail with their names and say, “I don’t need anything but e-mail and Web surfing.”

Let me tell you, folks, nothing calms angry users more than the realization that they did something slightly dumb and you have proof. This answer is usually followed by the user going away and not bothering you again. It can be a highly desirable thing—as long as the angry, embarrassed user isn’t the aforementioned CEO, of course. But seriously, it’s very important to understand the needs of your user community before you begin.

Keeping everyone informed
We’ve covered the first steps in building a security-conscious environment: getting management buy-in and getting the users involved. The next step is keeping everyone informed.

Sticking to this policy helps to keep the users involved, giving them an ongoing interest in the project. Distribute, in plain English, regular status updates and a basic outline of the configuration. It helps the users visualize how their information moves from one part of the network to the other. In fact, you’d really be surprised how much a little simple architecture information can reduce your other calls. It helps users figure things out on their own, and they won’t feel lost all the time.

But don’t just keep users informed about your own project; distribute security e-mails with information about how users can become more secure on their own and in their homes. Send out regular notices about patches and hot fixes. And of course, make sure that people are conscious of things like the last update on their virus scanners.

Training your users
The final and most important step of user prep is also the hardest, the most time-consuming, and usually the most expensive. If you want your project to be a success, you absolutely must train your users thoroughly.

If your users don’t know the proper use of the security facilities that you are setting up, not only will they pose a security risk, but they also will get frustrated and angry. They may not be able to get their work done at all, in which case they will a) take their aggressions out on you, b) find a way around the security (or rip a hole straight through it), or c) both—possibly at the same time, using heavy weaponry.

A colleague of mine recently implemented a token-based user authentication scheme. He set up the servers and mailed out the key fob tokens that give you your passcode, along with an instruction sheet, and he sent an e-mail the day before the changeover with what he thought were thorough instructions for how to log in to the new system. Within three hours of the cutover, about two-thirds of the company—including the CEO, CFO, and my colleague’s supervisor—had disabled their own accounts by trying to log in improperly. He forgot one of the most basic principles of learning: People don’t remember what they read; they remember what they do. If he had taken a few more weeks with the project and held ten-minute classes on the new login procedure with a few employees each day, he could have avoided most of that trouble.

It’s very important to understand that people retain only about 20 percent of what they read and 30 percent of what they hear. On the other hand, studies show that people retain about 60 percent of what they do and up to 80 percent of what they do and review a few times. (It’s too bad that we can’t teach by smell because people apparently have a 90 percent retention rate for odors.)

My recommendation is to hold regular classroom-style sessions for a few employees at a time over a period of a few months. If you can, set the schedules so that people who work directly together get staggered instruction. That way, just as one person is starting to forget the material, his or her co-worker is learning and talking about it. Then, when you’re ready to go live with the project, hold short review sessions for everyone to refresh their memories. Trust me, all the time you spend training your users before the system is in place will keep you from spending three times as long fixing the issues that you could have avoided if you had provided good training in the first place.

Wrapping up
So, what have we covered? First, you need to create a security-conscious environment by getting 100 percent management buy-in and by getting your users involved. Remember that in order to keep your users happy, your security policy needs to apply equally to everyone, with no exceptions. Finally, you need to keep everyone informed and train your users thoroughly to gain their help in making this project successful.

In part 3 of this series, we’ll discuss the actual hardware, software, and wetware (people) that are involved in setting up a security project. As always, I welcome your comments and suggestions.

Chris Dinsmore is a senior network architect for the Salinas Group, a prominent network security services and consultancy organization. He’s certified in several major firewall and network management platforms, and hehas eight years of experience in the support, administration, and security fields. Prior to working with the Salinas group, he operated a successful MIS and network consulting business for seven years.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
0 comments

Editor's Picks