Critical Control 8 - Controlled Use of Administrative Privileges

Published: 2011-10-12. Last Updated: 2011-10-12 23:05:26 UTC
by Kevin Shortt (Version: 1)
2 comment(s)

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

Next up, Critical Control 8.  This one shines a spotlight on the need to place tight controls around the use of Admin or any Powerful Privileges on all of your systems.  Essentially, what this means is Admin access (root/Administrator accounts) should be tightly controlled and monitored for use and abuse.

Exploiting the Control 

The Admin privileges can always be exploited when controls are not present. Here are some quick examples of why these controls are important.
 

  1.  When Admin accounts are used regularly, they can be exploitable...

         - when a malicious email is opened.
         - when a malicious file is downloaded and opened.
         - when the user visits a site that can exploit the browser.
             (these exist whether unwittingly or inadvertently)

        …which gives enough access to own your system and your data.
 

   2.  When user accounts with Admin privileges are configured with standing access to privilege escalation and little accountability, they can be exploitable…

         - by exploiting the user account through one of the methods above…
         - by password guessing the user account with standing privileges…

    …then escalating access to own your system and your data.

Mitigation

The definition of Critical Control 8  identifies 8 QUICK WINS.  I will not cover them here.  Read through them, and do not be shy about sharing ideas in the comments on how to implement them.  We all want to read more!

One example...

I can provide some detail on the use of sudo to assist in mitigation of risk and the use of the root account on your UNIX servers.  
One method is to implement the following controls to the root account in order to minimize its use and abuse of privilege.

  1. Automate the changing of the root password on a regular basis. Daily is my recommendation.  There are many ways to accomplish this, so please share your ideas.
     
  2. Limit access to the operational staff to an “as needed” basis. When crisis/incident/support needs arise, provide a mechanism for them to “check out” or “look up” the root password.  Again many ways…share your ideas.  
     
  3. A way to keep the revolving need at bay and minimize the exposure to root for any ops support team is to create a list of common commands the systems administrator staff use daily.  Take this list and configure sudo to provide standing access to an exhaustive but limited command set.  This mechanism provides two things:  

               - Lessens the opportunity for the abuse of privilege.
               - Provides accountability to the user that executes the commands.

A brief example of implementing this sudo rule set can be:


(NOTE: this is NOT an exhaustive list, it is brief only to illustrate.)

Place this rule set in to your sudoers file and create and add all of your system admins into the "admins" group, and they will have the ability to us
e sudo to execute these commands as root.

     User_Alias SYSTEM_ADMINS = %admins

     Cmnd_Alias ADMIN_COMMANDS =       \
                       /bin/date,      \
                       /bin/kill,      \
                       /bin/mount,     \
                       /bin/umount,    \
                       /sbin/ifconfig, \
                       /sbin/ifup

      SYSTEM_ADMINS ALL=(root) NOPASSWD: ADMIN_COMMANDS

I have in the past been involved with efforts of this nature in sizeable shops.  It is difficult at first, but it can provide good efficiencies and it always keeps the auditors happy when it comes to US SOX laws and the like. 

Please feel free to share what other ideas are being used out there.

Implementation, Metrics, and Testing

Controlling the use of Admin Privileges is no small task, and only gets harder as your environment continues to grow.  So if your shop is small, get to it.  It will never get easier than it is today. 

The control definition on the URL above provides some insight on Metrics, Testing and Monitoring the use of admin privs.  Read through it and please use the comment button to provide some ideas and feedback on the following:

Any other examples of gaps that this control proposes to mitigate? 
(I offered two above).
What can be used to accomplish the 8 QUICK WINS?
What controls can be used for Windows Powerful Privilege?
(Many of us want to hear what you do!)

Any variations of sudo that can provide some good control?

What are you using for Sensors, Measurement, and Scoring?
(See CC8 definition: http://www.sans.org/critical-security-controls/control.php?id=8)

The more we share these ideas the safer all of our systems and data will be.
     

--
Kevin Shortt
ISC Handler on Duty

2 comment(s)

Comments

For having users on Windows workstations run with a lower privilege level (local Users group) this is what we do:

For Windows workstations that are attached to the Active Directory domain, we setup a domain account that will be used as a local administrator account on all pc's. This account is pushed into the local Administrators group via group policy.
Then we have all users run from the User group instead of local Adminitrators group.

We can hand out that accounts userid/password for local admin access as we see fit.
Anyone have any experience and advice for getting developers to work without being in a local admin group. I work for a development company and they have always done it this way and I am fighting a huge uphill battle.

Diary Archives