Security 101: Privileged User Logging

Is authority and access to use advanced operating system utilities and commands that bypass system access controls monitored, logged, reviewed and restricted to those individuals or accounts that require access to perform the respective job function(s)?

Welcome to the second post in my series on security compliance. The purpose of this series is to dive into security requirement statements and detail what they mean, what they want, how to acheive them, and how to prove you're doing it. If you want to learn more about this series, read the introduction. This post is about privileged users and logging their access so that the business can be in compliance with access control and still allow system administrators to have the tools to perform their roles. 

Description

This requirement is actually pretty straight forward.  Do you have a mechanism to log instances where an administrator accesses resources they may not necessarily have the rights to view normally using their administrative privileges? For sure, one could make the argument that system administrators, by default, have access to everything but that's not exactly right. In truth, a system administrator shouldn't access things that would normally be restricted unless they specifically need to do so in support of the business.

The "go to" example I use for this is accounting data.  Generally speaking, this is pretty sensitive stuff. One would be hard pressed to suggest that the IT team needs access to this data all the time.  It's sensitive. The IT team doesn't need to access it generally.  But from time to time, they might to support the team.  When they do, in order to be compliant, any data they access which is part of the accounting team's data will need to be explicitely logged.

Let's go back to the first post in the series where we talked about role based access.  Administrators would also have a role based access control package that defines the resources they have standard access to.  As administrators, they should also have access to tools that allow them the ability to provide them access to other resources to manage the system. Use of these tools should be logged and those logs should be maintained in a way that cannot be manipulated by those with administrative rights.

TL;DR: You need a consolidated log server to track all access in your environment, whether it's administrative or normal.  There's no way around it.  Sorry.

Policy

My plan for this series is to provide an inline example of a policy that would address this requirement, but since I'd essentially be copying and pasting a full document from the great folks at the SANS Institute, let me point you to their Information Logging Standard policy.

The linked policy adds another layer to the role based policy discussed in the post about access control.  We know that there's a subset of folks who, by the definition of their role (system administrators) will need to bypass default access controls using the tools at their disposal.  So, an administrator, defined by a role, can bypass access control. But usage of administrator tools are logged based upon the logging standard policy (along with all other access to sensitive info - based upon the policy).

Controls

There's four ways to do this and which way is most appropriate to your organization is largely dependent upon how you're infrastructure is layed out. Likely as not, you'll be using multiple different ways because the available option may not be available on a particular platform.

No matter what mechanisms you put into place you're going to need a consolidated log server.  Essentially, this log server accepts logs from all of your critical systems.  At the minimum you're looking at capturing system and application logs from the following:

1. Active Directory Domain Controllers
2. Anything that tracks user logins
3. Active Directory File Servers
4. Anything that tracks file access
5. Application servers (custom or otherwise)
6. Backup Servers

My rule of thumb is that every system that isn't assigned to a specific user has their logs shipped to the log server.

Shared Administrator IDs (Grab an ID when needed)

Thesea are IDs that are shared and must be checked out of a vault in order to utilize administrative rights. The logging of the check out/check in process as well as any actions taken with the generic ID are logged. This was the solution that IBM used for administrative access to SAN devices.  All of the system accounts were kept in a vault and if you needed to perform admin functions you'd need to check out the ID, get the password, perform your task, change the password, and check it back in.

I'm not going to lie: This was a collosal pain in the hind end but it worked.  The vault maintained a log of who checked out an ID and the systems logged what that ID did whilst it was checked out. The SAN team wasn't in charge of the vault - it was controlled by a central security practice so we couldn't manipulate the logs of the vault.

Unique Administrator Level IDs (Log in as your admin ID)

When I was working for Alteris Group, we briefly toyed with the concept of unique IDs for the IT team with administrative privileges. In order to use the administrative rights, we'd have to log into the domain (Active Directory) using our admin accounts rather than our normal accounts. From a logging/audit point of view you only need to be concerned with the use of the administrator IDs rather than all the normal traffic.

SUDO and the Like (Temporarily turn on Admin Rights)

SUDO is a tool that let's a user execute commands as root if they'v been granted the ability to use SUDO.  It's pretty much the go-to for *nix type systems.  Any access granted using SUDO is logged by default and it's a really great way to grant administrative rights without adding a user to a system management group.  Essentially SUDO and other systems like it allow an administrator to "act like" they have root permissions without granting the individual ID those permissions.  The individual needs to "switch" to administrator mode before accessing the tools. 

Granted Permissions (All The Rights, All the Time)

This is probably the most common: Administrative users are provided with unfettered access.  Alas, it's also probably the least secure.  Okay.  No probably.  This option essentially grants administrators access to everything all the time.  Now, I'm not going to be naive and suggest that this isn't a thing.  A small organization can function with this approach just fine.  In fact, unless your IT organization has multiple departments (T1, T2, management) it's probably the way your organization works.

Sending To A Log Server

In order to comply with this security requirement, you need a log server.  There's really no way around it. Essentially the log server is the canonical reference for anything that happens on a server.  Even if the logs are removed, unavialable or otherwise compromised, the Log Server provided a canonical resource.  Canonical means that it's the authorative source.  It's where the auditor goes to view activity on the systems covered. No matter what happens on the system, the log server is where the final say happens.  In the references section I've posted a couple of solutions to consider.  

A special note regarding mighty IT teams of one. The controls described above are in place to prevent administrators who, by the nature of their job, can not only access things they shouldn't but also have the ability to hide or manipulate logs. The secure log server becomes a bit moot when dealing with a small IT team because, likely as not, the same folks manage that environment as well.

That being said, having a centralized logging solution has many advantages from a administration point of view even if it's not going to help with security if the IT team goes rogue. I highly recommend putting one in place even if you're the only IT resource the company has.

Audit

With a logging server in place, it isn't a horrible task to prove that you are, in fact, logging the use of administrative tools. If you're asked to provide specific instances you can use the search function within your centralized logging solution to provide the desired output. Would it necessarily be easily parsable? No. But you can provide evidence that the data is being collected.

I would suggest creating a dashboard on administrative access use and a regular calendar item for your IT lead/Security lead that indicates that they're reviewing the dashboard.  Both of these items can be used to fulfill the audit requirement.  Why the calendar entry? It's all well and good to be recording the info, but if it's not being reviewed the value (except as an "after the facct" RCA is minimal).

The short version is this:  If you're logging your access requests and it's being consolidated in a centralized logging solution then you can address the audit requirments.  It may take some doing but you'll have the data.  And that's what's important.

Reference

1. I found this site that lays out why a centralized logging server is great as well as a list of several superb open source solutions.  Check it out: 11 Open Source Log Collectors for Centralized Logging
2. I personally use Graylog for my centralized logging. It's easy to set up and it works as advertised.  I have it running under Hyper-V on an old machine I have in the datacenter (read: utility room).  I, of course, back it up every night even though the only person who cares about it is me.
3. If you're looking for a managed solution, I really liked, Sumo Logic. It's not as pricey as some and the features are great.
4. I know this is only the second post but, SANS Institute has some of the best boiler plate security policies available for free.  They're a great resource for crafting your policies.