[unisog] Password vaulting

Stephen John Smoogen smooge at unm.edu
Tue Feb 19 17:09:13 GMT 2008

Trevor Odonnal wrote:
> Hi all.  I have been asked by management to do some asking around to
> see if anybody out there is currently using any sort of
> "password vault" solution to manage administrative privileges
> to secure systems.
> For those who may not be familiar with this term, a password vault
> is a system that vaults administrator or root passwords in either
> a physical vault, or electronic secure storage.  When an individual
> needs root or admin access to a secure system, he or she must have
> a valid work order or change control number to request the access.
> The password is removed from the vault and provided to the individual
> for a specific amount of time.  At the end of this time period, the
> password is changed and re-vaulted.

I have seen such systems at work when I was in the US National Lab
system, but they really needed to be audited for work-arounds. The main
issue was that the first time the system got in the way of getting work
done, people would try to figure out ways to get around it. It is a
natural response usually due to 'stress' and 'existing habits'. The
stress of getting something fixed and being stopped by what is
considered a roadblock, and existing habits of 'hey I have had root for
4+ years.. and nothing has gone wrong (well except that time I rebooted
the cluster, or the time I removed /usr, but hey they were learning

So basically you have to do the following:

0) Make sure this has management and buy-in from moneyed interests. That
way if you have to let your head superstar sysadmin go because he keeps
breaking this.. no one says "We can't do that." If they do, scrap the
1) Extra training and rewards. Everyone has to know why this is in place
and see a benefit from it.
2) Extra auditing. If people find workarounds that give them admin.. the
system is worthless.
3) Put the system in place where it is needed and don't put it where it
isnt needed. Putting it in your devel environment because all systems
have to have it is a bad idea. Putting it in your integration/qa
environment makes more sense, but may need extra care and feeding.
4) Make sure you have made methods of change control obvious with the
continual improvement made very important. That way when the vault
becomes a roadblock, you figure out why and fix it within a short time
versus allowing 'resentment' to fester.

> The obvious question is "Why not just assign admin or root authority
> to the user's account?"  That is the usual procedure.  However,
> there are times when engineers need full root access to a system
> to perform their duties, or emergencies arrive when the privileges
> are needed right away.
> So, is anybody using a system like this?  If so, what are you doing
> and how well is it working?  What kinds of political issues have you
> had to deal with?  Thanks in advance!
> Trevor O'Donnal CISSP, CCFS, GREM
> Network Security Analyst
> Brigham Young University
> (801) 422-1477
> trevoro at byu.edu
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

Stephen Smoogen -- ITS/Linux Administrator
  MSC02 1520 1 University of New Mexico Albuquerque, NM  87131-0001
  Phone: (505) 277-8219  Email: smooge at unm.edu
 How far that little candle throws his beams! So shines a good deed
 in a naughty world. = Shakespeare. "The Merchant of Venice"

More information about the unisog mailing list