From: www.itworld.com
September 16, 2002 —
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 loose 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.
ITworld