[logs] Re: on database logging

From: Fenwick, Wynn (wynn.fenwick@private)
Date: Fri Mar 23 2007 - 08:06:33 PST


Morty {
	It's worse than that.  Computer security threats evolve quickly.
	Yesterday's risk probability cannot predict what will get
announced at Black Hat tomorrow.  To 	borrow your health care analogy,
imagine what health insurance would be like if new 	superplagues
evolved many times per year, had high mortality rates, and attacked
specific 	cross-segments of the population.
}

I can imagine that. Massive culling of the human race and survival of
the fittest. That's similar to where the dinosaurs went while other life
forms continued. But this is getting way OT.

The generic and specific solutions talked about here need not be
mutually exclusive. And they do not specifically apply only to logging,
so I will try to bring it home for the benefit of the list.

Much as it is not affordable to re-invent ground-up design-specific
security standards for each design, it is not secure to only broad-brush
systems with generic security standard. Rather, the broad-brush approach
should include a line item for an instance analysis. Customization of
the configurations and safeguards for the specific threat models likely
to apply to a system should be ensured. Some continuous re-evaluation of
those configurations handling new threat models based on indications and
warnings. The Answer does not exist on paper. 

To bring this back to the original thread that Anton started in database
log monitoring. One issue with database monitoring is when the systems
are programmed to do bad things to achieve good objectives for
expediency's sake.

Let's take something like phpBB, a popular open-source community forum
written in PHP (I know, I know) that talks to a database on the
back-end.

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. 

I am sure that some web apps are better designed, but I don't plan to
re-write phpBB anytime soon. It works well for its purpose. To migrate
to another platform would cost a lot of money that isn't available based
on this clients revenue model. To unbox the black box that is phpBB and
profile it and flag "anomalies", or accept the risk is the choice. This
is the labourious choice people want to avoid 100%, instead of putting a
measured amount to the problem and seeing what value that can provide.

Consequently when I designed and built an application for an
authentication system, it mapped user classes back to the database. This
restricted the privileges of the unauthenticated masses at the database,
but later switched contexts and connected to the database again with
reasonably privileged userid once the application user had successfully
identified himself. 

W

-----Original Message-----
From: loganalysis-bounces+wynn.fenwick=cgi.com@private
[mailto:loganalysis-bounces+wynn.fenwick=cgi.com@private] On
Behalf Of Mordechai T. Abzug
Sent: Friday, March 23, 2007 4:19 AM
To: Marcus J. Ranum
Cc: Fenwick, Wynn; LogAnalysis@private; Anton Chuvakin
Subject: [logs] Re: on database logging

On Thu, Mar 22, 2007 at 11:00:49AM -0400, Marcus J. Ranum wrote:

> Personally I do not think that is possible because of site variances 
> in security implementation, site variances in targets and their value,

> and site variances in practices. You can compute long-term 
> cigarette-related cancer mortality rates in humans because there is a 
> large (but dwindling!) sample of tobacco smokers but that works 
> because cigarette smoking affects all smokers more or less the same 
> way in large samples.

[snip]

It's worse than that.  Computer security threats evolve quickly.
Yesterday's risk probability cannot predict what will get announced at
Black Hat tomorrow.  To borrow your health care analogy, imagine what
health insurance would be like if new superplagues evolved many times
per year, had high mortality rates, and attacked specific cross-segments
of the population.

- Morty
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis



This archive was generated by hypermail 2.1.3 : Fri Mar 23 2007 - 11:51:01 PST