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.comlists.shmoo.com
[mailto:loganalysis-bounces+wynn.fenwick=cgi.comlists.shmoo.com] On
Behalf Of Mordechai T. Abzug
Sent: Friday, March 23, 2007 4:19 AM
To: Marcus J. Ranum
Cc: Fenwick, Wynn; LogAnalysislists.shmoo.com; 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
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis
_______________________________________________
LogAnalysis mailing list
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis