http://www.sans.org/critical-security-controls/control.php?id=11

Both Account Monitoring and Account Control are things that "slide by" in many organizations, and come up over and over (and over) again in security assessments.
Things that get often missed or overlooked:

Too many Administrative Accounts.  All to often, we see everyone in the IT group has "Administrator" equivalent rights in Active Directory.  If you are an application developer, you don't need Admin (every).  If you mainly reset passwords, you also do not need Admin rights.

Using the Administrator or Root Account directly.  To add to the first point, everyone who needs admin rights should have a named account that has those rights.  So, for instance, Jane Doe might have an account "jdoe" for day-to-day application use, but and admin account of "admin.jdoe".  If people use the administrator accounts directly, then there is no way of ever finding out "who did what" in the event that you need that information (and believe me, someday you will need that information).  If you can do this with a single admin account for multiple platforms (for instance, an Active Directory account) , it also means that when an admin leaves the company, you can revoke their access by deactivating their account from a single location.

Using an Admin level account for day-to-day tasks.  Let's paint a scenario - if you check your email with an admin level account, and some malware gets past your SPAM filter (like that doesn't happen every day), the malware now has admin rights in your domain.  If it's a keylogger, and you now SSH to a router or fire up vCenter to admin your VMware Infrastructure, they've now got credentials and access to a whole lot more of your Datacenter.  Really, use sudo or su in Linux, or use "run as administrator" in Windows to flip back and forth.  Or if you really need admin, keep a VM running that has that right so you can flip back and forth easily!

Work with HR for account creation and deletion.  In all too many cases we see dozens of accounts (sometimes hundreds) that haven't been used in months, only to find that people have left the organization and the IT group wasn't told.  Even if their account data needs to be kept around, create a "data transition procedure" to move data to the person who needs it next after someone leaves.

Shared accounts are EVIL (really).  Too many times we see clerical accounts that are shared between dozens of people in a group.  These folks generally have direct access to customer information and to data input that affects prices.  I've seen one example where a temp wasn't sure what a field was, so they put "1" in to close out orders.  Unfortunately, it was the "dollars per square foot" value for the material selected - it took accounting weeks to untangle that mess!  Without named accounts, it would have been impossible to figure out who was making this error !  Shared email accounts can create similar problems with accountability.

Password Complexity is a must-have anymore.  While we can have a flame-fest about if complex passwords or passphrases are better (I'd lean towards passphrases, but it's not workable in every environment), you simply can't have people use "password", or their kid's names anymore for access - it's simply too easy to crack. 

Account Lockout is a must have.  If someone is trying to brute-force your CEO's webmail account, yes, you do want the account locked until you can speak with them.  Better they lose access for an evening, as opposed to having their account compromised and confidential information be disclosed (next years products, mergers or acquisitions, salaries etc).

If you don't have a Password Policy (or have it covered in your Acceptable Use Policy), it's probably time that you put one together that covers all of these issues, as well as enforcement of periodic changes.  Make sure that whatever is in the policy, that you can enforce your policy it in the OS (it's not a bad thing to mirror the default Windows Password Complexity setup, that way enforcement and audit are built into the OS)

While you are at it, try to put one-way encryption into your password policy.  We recently had a lively discussion about user passwords for an application being stored in a database, "in case someone needed it".  You should never need a user's password.  If you do, you need to revisit how your application is being written.  If you keep users' passwords, they immediately have deniability for anything that happens.  This could mean that system administrators could then be suspected or found liable in the case of illegal activity.  So, really, get with the 90's and use the OS passwords wherever possible, or, second choice, use hashes and salts to govern your app accounts.

You can and enforce and monitor for all of this with issues with native logging and controls in the Operating System of most popular OS's (Windows, Linux, Unix).  If you have a legacy system that does not do this, it's probably a system that should be revisited.

As always, any tools you might use, solutions you may have found or "war stories" you'd like to share are welcomed - please use our comment form !


PS - a handy "su" for Windows is shown below (if you have a neater "su" or "sudo" solution, please share via our comment form):

Update:  Reader Stefan noted (correctly) that as a best practice, the path should be fully specified for both RUNAS and for CMD.EXE in our "SU.CMD batch file.  Also, it's important to fully spell out the file name and extension (you can for instance execute a file named "cmd" with no extension on it).    These updates are reflected in the script below.

While this is indeed a best practice, if you suspect that your machine is compromised, it's files like RUNAS.EXE and  especially CMD.EXE that are popular targets.  If you suspect that your machine is compromised, it's best to execute files from trusted read-only media, or, better yet, boot from optical and run your investigation from there.  

If you need to do true forensics (as in "admissible in court"), a whole entire other methodology is required (image the machine, only work with copies of the data, maintain chain of custody, the works).  SANS SEC408 and SEC508 are both good courses to consider if you want to get your feet wet with forensics.

========== su.cmd ==============

@echo off
if "%1" == "" goto HELP
if "%1" == "?" goto HELP
%SystemRoot%\System32\runas.exe /env /user:%1 "%SystemRoot%\System32\Cmd.Exe"
goto ENDEND
:HELP
echo ===========================================================
echo SU.CMD - start a shell as another user (usually admin)
echo Usage:   su USERID
echo Where USERID is the target user
echo It is recommended that you do NOT SU to or login as native
echo Administrator accounts
echo ===========================================================
goto ENDEND
:ENDEND
 

 ===============
Rob VandenBrink
rvandenbrink@metafore.ca