Summary: A healthy dose of paranoia is good for the soul, not to mention your IT infrastructure's security position, but overdosing can make the system less usable for you and your users.

Being paranoid about security is a good thing. For example, requiring strong passwords, locking down the services on your machines, removing all shared accounts, and disabling cleartext protocols make it more difficult for a cracker to gain access to your machines and data. Unfortunately, it also makes working on the systems less convenient for you and your users. Implementing good security measures makes the system harder to use; it's an unfortunate fact of life.

When you make security-conscious changes on your personal machine, the only one impacted is you. However, if you are an administrator of machines for many users, things get trickier. People do not like change, any change. They want their password to be 'bunny' from now until they retire. They want to stick with telnet because they know it, rather than moving to ssh.

So when you determine that security changes need to be effected, how do you get folks who will resist changes to go along with them? I find that there are usually two methods that work well.

The first I call the carrot and stick approach. Say you want to eliminate telnet, ftp, rcp, and rsh from your network and move to ssh instead. You essentially start a marketing campaign, extolling their virtues. For example, efficiency: 'ssh' requires three less keystrokes than 'telnet', and 'ssh' replaces both telnet and rsh -- one less command to remember. Unfortunately, if folks are used to the status quo, it won't work. They'll probably counter that 'sftp' is longer than 'ftp'. You need to come up with other benefits of the system.

In the case of ssh, you can teach them how to leverage SSH identity files and ssh-agent to allow them passwordless login access. They'll see that they can ssh/scp/sftp from their desktop without typing a password at all, and have a secure encryption connection to boot. You can sell them on the increased speed when using compression over slower lines. X11 forwarding will 'just work' finally. Make sure to show all the positive aspects of the more secure solution so they realize there is more than just a security benefit. Once enough people sign on -- the folks who have taken the carrot -- most of the rest will grudgingly agree. However for those last that simply cannot live without the old ways, the higher-ups make the decision that supporting the old environment and new simultaneously isn't going to happen, and they'll need to live with it. The better your marketing, the less folks you piss off this way.

The next method I call the "Scotty Solution", in honor of the famous Star Trek engineer. Instead of smoothly transitioning our your insecurities one by one, you go for the sledgehammer approach. Break everything. Lock down things the way you want them to be. Turn off telnet/etc across the board and install ssh everywhere. Lock all user accounts with crackable passwords. Lock down the permissions of everyone's home directories. Delete all the common-use accounts. Turn off unencrypted POP and IMAP access. The users will howl, productivity will be a disaster for a week or so as you transition everything over and teach the users the way to use the new system.

Now you'd think that this would be an instant way to lose your job. The trick is how to time this right -- you want to be seen as the savior, not the one that caused the problem. The best time to employ this method is when you have some external factor that you can blame. Perhaps you're going through a merger with another company and you need to connect the two networks. Or perhaps some cracker and finally got permission to lock things down just broke you into. However my personal favorite is to hire some security consultant to come in and 'fix' things. They come in dictate what needs to be changed and leave. You then have a perfect scapegoat -- the Klingons have fired first, and you're just getting the engines working again. You teach folks how to work in the new system. When they're back up and running, they'll thank you. No one needs to know that you gave the deflector shield codes to the enemy.

Bri Hatch is Chief Hacker at Onsight, Inc, and author of Hacking Linux Exposed and Building Linux VPNs. He's that security consultant that comes in and secures everything to the point of unusability. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 17-Sep-2002.