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?