Security, et al

Randy's Blog on Infosec and Other Stuff

«  LOGbinder SQL Beta is rel... | Come On Feel the Noise »

Security Logging as a Detective/Deterrent Control Against Rogue Admins

Wed, 19 Oct 2011 08:24:56 GMT

Intrusion detection and compliance are often the focus of log management/SIEM efforts and security logging in general.  But security logs (when managed correctly) are also the only control over rogue admins.  Why do I say that?  Well, once you give someone root or admin authority there is nothing they cannot do.  They can circumvent any access or authorization controls you implement on the system because with admin authority they can either directly change those settings or use hacker tools that leverage their root access to tamper with the internals of the operating system.  Beyond rogue internal admins, the same issues I bring up in this article apply to the risk of outside attackers who gain admin authority (aka root access).

The only control you really have over privileged super users is an audit log that, if properly handled, can serve as a deterrent and possibly detective control against misuse of privileged authority.  But notice I say “if properly handled”.  Those 3 words serve as in important warning that simply enabling auditing and deploying a log management solution may not suffice to provide a solid deterrent to rogue admins. 

To really be a deterrent, the audit log must be protected from deletion or tampering by rogue admins.  First and foremost that means you must move log data 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 archival.  However, who has privileged access to your log management solution and the systems on which it runs?

A log management process is not an effective control over administrators if those same administrators have privileged access to the log management components.  To be clear I’m not suggesting that administrators be denied access to run reports, configure alerts or research logs.  I’m talking about 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.

So, to reiterate: a log management solution cannot serve as a deterrent over administrators if those same administrators have privileged access to it at the application level or any of the infrastructure components on which it runs.  That 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

Moreover if the log management application or any of the components above run inside a virtual machine you should also include:

·         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

And of course physical access to any of those components would also potentially allow administrators to compromise the integrity of your audit trail.  Wow!  Does that mean your log management solution needs to run on a completely separate infrastructure?  To the extent possible, absolutely.  It certainly speaks to at least consider building your log management components from traditional physical servers and local disk storage.

And remember such separation is a protection against not just internal rogue admins but any outsider that succeeds in obtaining privileged access well.  Any outsider sophisticated enough to achieve that will also make efforts to erase their tracks.

Of course there are always cost/benefit comparisons to be made.  Typically the larger the organization the more important and more practical it is to achieve maximum separation between the log management solution and the environment it monitors. 

Beyond hardware and software separation, you must also consider who will provide the care and feeding for the log management application, database servers, storage, OS and other components.  Larger organizations have a dedicated information security team.  Within that team there should be a group with responsibility 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 care and feed necessary for all components in the log management solution.  Of course that may be impractical since information security professionals on that team may not be conversant in all the technologies involved.  In that case they should call upon the expertise of IT staff with the required skills as needed and ideally they would supervise the actions taken by such staff to ensure they do not compromise audit log integrity such as through the introduction of backdoors.

There are a host of reasons why even the “supervised access” method described above may not work.  Staff in smaller IT shops have to back each other up and often can’t specialize so the possibility for separation of duty like that described above may not exist.  Or, there may be a dedicated security and compliance officer, but that person may not be technical enough to supervise IT staff when maintenance is required on log management components.  Finally in some organizations there may be great push back to carving out a separate physical hardware environment for audit log management.  

When an in-house physically and logically separate log management system isn’t possible organizations, log management as a service may be an interesting alternative.  With cloud-based log management the entire log management system is at another site under the control of a professional service team.  Furthermore, some services can be set up with role based access control so that the ability to erase audit logs is controlled.  If organizations can overcome the frequent pushback to shipping audit logs to the cloud, full isolation and integrity of log data can be achieved without building a separate log management system and without needing system care and feeding expertise within the team responsible for audit log management.

Whether an organization goes with an in-house audit log management or turns the cloud it should carefully assess whether its choices in architecture and administrative responsibility allow it to rely on the log management system as a deterrent/detective control over rogue admins and as a means of impact analysis and recourse against outside intruders who gain root access.  When the worst happens, audit logs may be all you have.  Are they secure?

email this digg reddit dzone
comments (1)references (0)

Related:
Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Automating Review and Response to Security Events
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log

Comments

RE: Security Logging as a Detective/Deterrent Control Against Rogue Admins
by sam
Saturday, October 29, 2011 6:02 PM

Thank u for this intersting ideas!


Comments disabled

powered by Bloget™

Search


Categories
Recent Blogs
Archive