Re: Re: on database logging

This is a pretty well known problem. Getting application vendors to
pay attention to logging, or to consider adhering to any kind of
standard is really an uphill battle. Tina, I know you've seen dozens of
attempts at various logging standards (if not many more) - and so far
none have really stuck. Even IBM has tried their hand at it with the
CBE (Common Base Event) standard/technology, but I'm not sure how well
that's caught on.

And throw in the issue of all the legacy systems that vendors have no
plans to go back and reinstrument to create useful logs.

The reality is that log analysis solutions MUST be capable of coping
with different formats of data from different sources. Further, these
products cannot assume all logs will have certain pieces of information
(e.g., IP addresses, or usernames). A master schema that all logs can
magically fit into is essentially impossible.

Speaking of HIPAA specifically, you are absolutely right that auditing
the most granular activity at the application level is critical. Some
patient management systems offer highly tunable logging configurations,
and any good vendor will have a policy on what events you need to turn
on for HIPAA compliance, and which ones are optional.

This also brings up another issue about what information is being
written to the logs in the first place. We hear a lot of customers say
they want to know every nurse who has accessed patients with diagnosed
with <insert sensitive condition>. If that information is being
written to the logs, then the logs themselves now contain PHI. The
point being that real care must be taken to make sure you're logging
the right things, and not the wrong things.

Dan

Dan Barahona

Vice President, Emerging Markets

SenSage, Inc.

[email protected]

415.808.5911 (w)

415.505.3007 (m)

Tina Bird wrote:

I would prefer if application programmers would map the users at the
application layer of a web application to a database user. I would
prefer if the RBAC groups implemented in that application were
manifested in the database as well. Finally I would prefer if
the groups
of logical operations that the groups of users were mapped
back into the
database also.

With phpBB, all application users connect to the backend database as
user phpbbuser (or whatever I happen to configure). That "phpbbuser"
will have the superset of database access privileges that admins,
moderators, validated users, unvalidated users, suspended
users require.

This application cannot do not fine-grained access control at the
database layer. The control objectives I see in ISO 17799 and other
standards assume that it can.

And HIPAA. Don't forget HIPAA. I have been blithely making statements along
the lines of "medical applications need to be able to record every write,
change, read or delete to an electronic medical record at a per-user level"
for years, until it finally sunk in (a year or so ago) that the vast
majority of DB applications -- including those with Web front ends -- did
generic authentication "to the database." No hope of individual
accountability.

This discussion brings me back to one of my persistent chants, when it comes
to logging -- the end users (in this case, the sys admins and auditors who
must demonstrate compliance to laws) have *got* to provide the technical
requirements to the developers for more detailed auditing; systems have to
be architected and maintained to support the additional strain created by
the logging.

Does anyone have any numbers on the additional CPU load (or performance hit)
created by this level of auditing in a high-load DB environment? And then,
of course, we can worry about how much worse the performance gets if we
insist that user crendentials and authorization tokens are suitably
encrypted...

cheers -- tbird

p.s. Wynn, I am still laughing about your last posting:

"IT systems often do not fit into simple little boxes and
that is part of the problem. We build cloverleafs at dirt-road
intersections to avoid teaching people about the 4-way stop."

What a *perfect* description.

_______________________________________________
LogAnalysis mailing list
[email protected]
http://www.loganalysis.org/mailman/listinfo/loganalysis

_______________________________________________
LogAnalysis mailing list
[email protected]
http://www.loganalysis.org/mailman/listinfo/loganalysis