[logs] Re: on database logging

From: Tom Le (dottom@private)
Date: Wed Mar 21 2007 - 11:44:46 PST

> > > What's the story? Is database logging hot or not? :-)
> >
> > Hot, it is not.  Necessary, yes for companies with compliance drivers.
> > The reason it is not hot is because it is solely driven by compliance
> and
> > not by any other company requirements.
> Ouch, how about security? I guess we are dealing with some case of
> mental inertia here. Otherwise, why is it not obvious that for
> incident response due to system hacking you look at system logs, and
> for incident response due to database or web application hacking you
> look ... where DO you look if you don't have the database logs?

Application transaction, OS, and DB layer monitoring are just too low on the
priority list for most security budgets.  Benefit is low, complexity is
high, lack of vendor tools (how many SIM's support app/OS/DB auditing?), no
internal champions, and not mention integration effort is high as contextual
information differs from environment to environment.

In my experience the only drivers are compliance.  MSSP's have custom
solutions to convert audit data to log data and integrate the contextual
data.  I know of one that does it well (but will leave vendor info off the

So, somebody need to campaign "Database logging: it just isn't only
> for auditors anymore" :-)

You also need to campaign for app layer and OS logging in concert with DB
logging.  This is because from a security perspective, if a server was
compromised or internal admin user wanted to modify data, the first thing
they would do is disable auditing or logging functionality.  It's like
adding an alarm system to your doors but not monitoring the windows -
there's no point in a partial solution.

 All my DB logging implementations focused implicitly on capturing admin
user activity.  Yes, the implementation audits all users, but heavy focus on
admin users.  This is driven from compliance.  Admin users have carte
blanche access to the environment, so you must implement app/OS/DB logging
if you need to monitor their activity.

>From a log aggregation & reporting perspective, you still need to
integrate contextual data into your monitoring/reporting.  IDS and host
based messages are easy once you can parse, identify, and label
the attributes of each message.  A failed login message or attempt to map C
drive means the same across all customers.  The context here are users and
assets.  With app layer transactions, OS, and DB, each environment is very
different and you need a paradigm to normalize this data for monitoring &

LogAnalysis mailing list

This archive was generated by hypermail 2.1.3 : Wed Mar 21 2007 - 18:58:57 PST