Intrusion detection and compliance are the focus of log management, SIEM and security logging.  But security logs, when managed correctly are also the only control over rogue admins.  Once root or admin authority has been given to, or acquired by, a user, there is little they cannot do:  with admin authority, they can circumvent access or authorization controls by changing settings or using tools to leverage their root access to tamper with the internals of the operating system.

Audit logs, when properly managed, can serve as a control and deterrent against the privileged super user’s authority. Simply enabling auditing and deploying a log management solution may not suffice; to really be a deterrent, the audit log must be protected from deletion or tampering by rogue admins.

First and foremost, log data must be moved as frequently as possible from the system where it is generated to separate secure log repository.  Today’s enterprise log management solutions do a great job of frequent log collection and long term archiving.  However, who has privileged access to the log management solution and the systems on which it runs?

A log management process is not an effective control if administrators have privileged access to the log management components.  Though administrators should not be denied access to run reports, configure alerts or research logs, privileged access to the log management solution that allows someone to disable, erase or otherwise compromise the integrity of the log collection and archival process should be carefully managed.

A log management solution cannot serve as a deterrent over administrators who have privileged access at the application level or any of the infrastructure components on which it runs.  This includes:

• the operating system of the log management solution
• any database servers it uses
• the Active Directory forest in which the log manage server resides if a Windows server
• the NAS or SAN where it stores log data

And if the log management application or any of the above components run inside a virtual machine this also includes:

• the virtualization host, such as VMWare ESX(i), if it runs inside a virtual machine
• the virtualization manager, such as VMWare vCenter
• any of the components listed earlier which are used by or host the virtualization manager

Physical access to any of these components could potentially allow administrators to compromise the integrity of the audit trail.  To the extent possible, the log management solution should run on a completely separate infrastructure.

Remember such separation is a protection against not just internal rogue admins but outsiders who succeed in obtaining privileged access.  Typically the larger the organization, the more important and practical it is to achieve maximum separation between the log management solution and the environment it monitors.

Beyond hardware and software separation, the log management application, database servers, storage, OS and other components also need careful management. Larger organizations generally have dedicated information security teams, and usually within that group is someone responsible for the audit log management process.  For full accountability and separation of duty, that team should have no privileged access to production business systems monitored by the log management process.  Ideally that group would provide the oversight necessary for all components in the log management solution and supervise any action that touches the audit log to insure its integrity and prevent the introduction of backdoors into the system.

There are a host of reasons why even “supervised access” can be compromised:  staff in smaller IT shops aren’t always able to specialize so the possibility for separation of skills and duties may not exist. When an in-house log management system can’t be physically and logically separated, log management as a service may be an alternative to consider.  With cloud-based log management, the entire system is controlled by a professional service team at a separate site. Services can be set up with role-based access control so the ability to erase audit logs is controlled.  If organizations can overcome the frequent pushback to sending audit logs to the cloud, full isolation and integrity of log data can be achieved without building a separate log management system, and without the requirement of expertise for audit log management.

Whether an organization goes with an in-house audit log management or turns to the cloud-based service, it should carefully assess its choices in architecture and administrative responsibility. When the worst happens, audit logs may be the only deterrent and detective control over rogue admins.  Are they secure?