Building A Program To Manage And Monitor Administrators
Monitoring the activities of privileged users or server administrators is becoming a common requirement in many organizations for a few reasons:
- Compliance with legal or regulatory requirements, such as PCI, HIPAA, etc
- Performing outsourcing services to clients who require controls to prevent the service provider’s employees from causing harm to the client.
- A recent experience where a trusted employee performed some malicious action
In this realm of managing administrators, there are two primary objectives:
- Individual accountability
- Proactive monitoring of actions taken
Many administrators have the opinion that once you allow a person to act as root, all bets are off. That is true to a large extent, and will require a fundamental change in thinking for some. Controls need to be implemented to manage the actions of these privileged users in a manner that is commensurate with the risk of the system(s), applications and data being managed.
Individual Accountability
Individual accountability is the ability to directly attribute a specific action to a specific person. Individual accountability is particularly challenging in the world of Unix and Linux, where the primary administrator ID, root, must be shared between administrators. Sharing the ID removes the ability to determine who, among a team of administrators, performed a certain action on the system. Windows servers have a similar challenge with the Administrator ID, but Windows provides the ability to add administrative privileges to other user accounts.
On Linux/Unix systems, the most common way to implement individual accountability is this:
First, implement a policy where administrators perform all normal functions by using SUDO. SUDO lets ordinary users perform actions as root, but all actions are fully logged, including who performed the action. The use of SU must be prohibited.
Second, since there are occasions where logging in as root is required, a mechanism is needed to ensure that:
- Authorized administrators can access the root password when needed
- Only one administrator at a time can know the root password
This functionality is generally provided through a password vault system that allows check-out and check-in of passwords, with automatic password changes after use. Commercial password vaulting systems are available from a number of vendors.
System security logs can be used to verify compliance with the no-root and no-SU policy. A real-time or periodic (daily, weekly, etc) automated analysis of log files can extract instances of root logins and SU to root events. Feed the output of this analysis into an “administrative user monitoring program”, defined later. Following the good practice of sending logs to a hardened log server for storage and processing will prevent determined administrators from covering his tracks by deleting the logs on the local server.
Proactive monitoring of actions taken
An administrator has the ability to perform a very wide range of actions on systems he manages, some of which is interesting and should be examined and the balance of which is uninteresting house-keeping. A tremendous advantage of administrators using SUDO is that a command-by-command accounting of all actions taken is maintained in the logs. Build a table of important or sensitive files and applications to scan SUDO logs for, such as:
- adduser
- chgrp
- passwd
- shadow
- audit
- and so-on
Entries found likely constitute an action worth investigating further and should be fed into an “administrative user monitoring program”, defined later.
Performing actions as root or under “SU” do not provide such an accounting, and so other means of identifying unapproved actions must be used. The most effective way to accomplish this is through the use of the operating system’s “audit” capabilities. As with above, a definition of important commands and configuration files can be created and used to scan the audit logs. Identified changes to key configurations should be fed into the “administrative user monitoring program”.
We will cover the requirements of the “Administrative User Monitoring Program” in a separate post.
[...] This is one area of log management that many organizations unintentionally overlook, because the perceived risk is not very high, the administrators are unaware of the options, and more commonly, the view that monitoring the activity of administrators is futile because such monitoring could be bypassed by a skilled administrator. In separate post, I describe a process to monitor the activities of administrators. [...]