Re: on database logging

Marcus,

I think that your statement is true for most commercial
organizations
whose drivers are related to finances and regulatory
issues.
Unfortunately, security risk management activities seem to
take a back
seat to this. It seems this is The Way, for the objectives
of each camp
are less instersecting than I would like on seeing some of
the results
of a recent SAS-70 Type II audit.

The root seems that few are practicing business-level risk
management on
IT assets and safeguards because the risks are difficult to
quantify and
express in dollar units as they do in the physical realm. 

The policies ask for it but the control objectives
beat-around-the-bush.
Quantifying probabilities and loss expectancies from IT
security risk in
dollars actually requires monitoring in the first place. Add
a certain
amount of eye-of-newt and ear-of-bat, and you could come up
with an ALE
that might point out that some increased vigilance,
increased precision
of monitoring could result in lower operational cost (from
the risk
component). If the risk component is not too large, risk
acceptance and
monitoring of the risk level is an equally good practice. 

My issue is that most organizations accept unquantifiable
risk without
even attempting to measure it. This is not good risk
management. Others
many have sized the potential $risk by eyeball, and are
afraid to
actually put the $numbers to slide decks because of the
$safeguards
required to demonstrate $effective risk management.

Government departments in Canada are working toward
compliance of a
different sort. Communications Security Establishment has
laid out
control objectives in "a series of Baseline Security
Requirements" that
are prescribed by Canadian Government Security Policy. These
control
objectives are prescriptive, if unrealistic, for zones of
the network.
ie: "Continuous" monitoring is prescribed for most
network zones. A
database often resides in a zone that requires continuous
monitoring.

The next step is to define what are the attributes of a
effective
monitoring system. What is the point of an exception
monitoring and
handling system if it does not generate and handle
exceptions? We often
talk of monitoring but that's only part of the process.
Business types
are too literal. Why monitor without identifying exceptions,
determining
if they are sufficient risk to contain and if necessary
eradicate? 

Too often management are afraid of extra unscoped costs that
a
investigating the exceptions a monitoring system will
inevitably
generate. Estimate a reasonable budget we IT security gurus
should say
"we can start with $x in monitoring and response, and
we will measure
how much risk we would not manage". 

For databases specifically, the reports that the control
objectives that
are inducing are fundamentally misaligned with many web
application
designs that drive today's business. Few web applications
map the
application-layer user instance back to the database-layer
user
instance. However, many current control objectives assume
that is true.
That's just one instance of the misalignment.

Many other objectives are oversimplified and rules-based so
the rest of
the world can put complex systems into simple little
tick-boxes. As an
omnibus safeguard, they actually get in the way of practical
risk
management. 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.

W
--
Wynn Fenwick, 
Chief Techincal Architect, 
CGI Managed Security Services


-----Original Message-----
From: loganalysis-bounces+wynn.fenwick=cgi.comlists.shmoo.com
[mailto:loganalysis-bounces+wynn.fenwick=cgi.comlists.shmoo.com] On
Behalf Of Marcus J. Ranum
Sent: Wednesday, March 21, 2007 2:25 PM
To: Anton Chuvakin; LogAnalysislists.shmoo.com
Subject: [logs] Re: on database logging

Anton Chuvakin wrote:
>Ouch, how about security? I guess we are dealing with
some case of 
>mental inertia here

All the current trend toward legislating compliance has
accomplished is
setting the bar very low, and encouraging companies to look
only at
meeting that standard. I've had senior IT managers tell me
"We are going
to do the exact minimum, wherever possible."

In log analysis terms, that means that the logs to to a big
bucket which
is periodically dumped into the compost heap. Nobody'll look
in the
bucket until someone passes legislation requiring people to
LOOK at it.
And, of course, when that happens, they'll do the exact
minimum, &c...

mjr. 

_______________________________________________
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

Fenwick, Wynn wrote:
>The root seems that few are practicing business-level
risk management on
>IT assets and safeguards because the risks are difficult
to quantify and
>express in dollar units as they do in the physical
realm. 

I agree with you 100%. But the root cause is that the notion
of
"risk management" is a fantasy and I think that
that realization
has begun to sink in where it matters.

And that's because, exactly as you say, "the risks are
difficult to
quantify." Which is a bit of an understatement, really.
The problem
is that:
- Risk is hard to quantify
- Expected loss is hard to quantify
- Effectiveness of protective measures is hard to quantify
In fact, "hard" is generous -
"impossible" might be a better word.

To get all Rumsfeld on you, we're dealing with "unknown
unknowns"
and a very small handful of "known unknowns." The
whole premise
of risk management is false - it's that you can somehow
perform
a cost/benefit analysis based on a risk probability. You
don't
have to have passed Statistics 101 to realize that
cost/benefit
analysis is complete science fiction if you've got a single
unknown (known or unknown) in your equation.

The "quants" understand this, too. If you were to
go to an
insurance company and try to get them to write a policy
based on no useful actuarial data, no reliable threat
data, and unbounded costs they'll either laugh at you
or ask "what's the value of the thing you want us to
ensure? because that's the annual premium."

> Add a certain
>amount of eye-of-newt and ear-of-bat, and you could come
up with an ALE
>that might point out that some increased vigilance,
increased precision
>of monitoring could result in lower operational cost
(from the risk
>component). If the risk component is not too large, risk
acceptance and
>monitoring of the risk level is an equally good
practice. 

This is the problem, in a nutshell, with the risk
management
philosophy. I'm not slamming you, personally, here, but the
statement above is a perfect example of why security
remains
a backwater. Basically, what you're saying is:
"since we don't really have anything real, let's make
up some
plausible-sounding bullsh*t and try to sell it to executive
management." 

That summarizes the last 15 years of computer security
quite nicely!! We have relied way too much on selling
management
plausible-sounding bullsh*t to the point where it's made us
sound absolutely stupid. Because we are. After all, if
we're
asking management for millions and millions of dollars to
improve the computer security situation, it ought not to be
getting WORSE, right?

>My issue is that most organizations accept
unquantifiable risk without
>even attempting to measure it. This is not good risk
management.

There is no good risk management.

As you say, it all depends on being able to measure risk.
And, as
you say earlier - all we can offer is " a certain
amount of eye-of-newt
and ear-of-bat"   That's pseudoscience. When you talk
about there
being "good risk management" what you're really
saying is:
"If risk management weren't complete bullsh*t it
wouldn't be
complete bullsh*t."

That's true. The question is whether we can get from where
we
are (100% unadulterated bullsh*t - or "unknown
unknowns") to
at least being able to deal with the "known
unknowns."  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. In
computer security about the only things we can say with any
degree of certainty is that there are large populations of
Windows users - but as soon as you start thinking about
threat models by patchlevel, administrative practices, and
local network topologies - it all falls apart quickly. If
you start
trying to quantify things like "dollar value at risk if
this
server fails" you discover that it's all hand-waving
because
nobody knows (and I mean "nobody") what systems
really
depend on eachother, anymore. I was at one site where they
had multiple layers of redundancy for all their stuff and
the
software layer would have all gone kerblooie if their local
DNS server had failed. Anyhow - you get the point.

And to muddy things up you have "security
legends"
like "80% of attacks come from the inside" that
people
repeat as if they are gospel, but, in fact, that's a number
that someone pulled out of his butt one day at a conference
and everyone has been repeating it ever since as if it
had been handed down by the Archangel Gabriel on
a stone tablet. :(

> Others
>many have sized the potential $risk by eyeball, and are
afraid to
>actually put the $numbers to slide decks because of the
$safeguards
>required to demonstrate $effective risk management.

What you mean there is "many have pulled numbers out of
their
butts and have been afraid to stand by them because they
know
they are bullsh*t."

>Government departments in Canada are working toward
compliance of a
>different sort. Communications Security Establishment
has laid out
>control objectives in "a series of Baseline
Security Requirements" that
>are prescribed by Canadian Government Security Policy.
These control
>objectives are prescriptive, if unrealistic, for zones
of the network.
>ie: "Continuous" monitoring is prescribed for
most network zones. A
>database often resides in a zone that requires
continuous monitoring.

Yup. And the problem is that a lot of those concepts come
from,
well, people like us. We're cutting our own throats. You
know how
it goes - someone at VISA asks, "what should we require
for PCI
compliance?" and some security practitioner thinks,
"...Well, a bit
of pen-testing wouldn't hurt. Besides, I make my living
doing
pen-testing."   "Pen testing!"  These
prescriptive recommendations
are largely nonsensical because they are not tied to a
meaningful
design. And that's the problem. None of this stuff makes
any
sense unless it's tied to a design but none of what we have
was
ever designed - it just "happened" one night. So
we're trying to
come up with ubiquitous retro-design patches for flawed
architectures. Yeah... THAT is gonna work... :(

>The next step is to define what are the attributes of a
effective
>monitoring system. What is the point of an exception
monitoring and
>handling system if it does not generate and handle
exceptions? We often
>talk of monitoring but that's only part of the process.
Business types
>are too literal. Why monitor without identifying
exceptions, determining
>if they are sufficient risk to contain and if necessary
eradicate? 

Bingo. Now you're asking design questions. But these
questions
cannot be meaningfully answered except on a case-by-case
basis.

>Too often management are afraid of extra unscoped costs
that a
>investigating the exceptions a monitoring system will
inevitably
>generate. 

Managers are HORRIFIED by the unscoped cost labelled
"computer security." And rightly so. We keep
asking for more
and more money, as if throwing money at the next little
facet of the problem is going to be the one little band-aid
that stops the gushing blood.

I'll stop there.

mjr. 

_______________________________________________
LogAnalysis mailing list
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis

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

All,

Wow, I haven't seen any traffic on the list for a while.
What's the
story? Does logging still matter (it does!)?

So,  just to restart things up  - do the
esteemed members of the
list care about database logging at all? Oracle, MS SQL,
MySQL, that
sort of thing?

Database logging is rarely discussed whenever logging is
mentioned.
Recently, I wrote this paper about db logging
(http://chuvakin.blogspot.com/20
07/03/on-database-logging-and-auditing-teaser.html),
and I was actually pretty surprised when people started
asking about
it.

What's the story? Is database logging hot or not? 

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot
.com
    http://www.info-secure.org

_______________________________________________
LogAnalysis mailing list
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis

> So,  just to restart things up  - do the
esteemed members of the list
care about database logging at 
> all? Oracle, MS SQL, MySQL, that sort of thing?

Yes, both database audit logs and logging application
transactions via the
database present interesting opportunities for analysis.


> Database logging is rarely discussed whenever logging
is mentioned.
> Recently, I wrote this paper about db logging 
>
(http://chuvakin.blogspot.com/2007/03/
on-database-logging-and-auditing-tease
r.html),
> and I was actually pretty surprised when people started
asking about it.

Yes, and I'm still waiting for my copy.  

PaulM

_______________________________________________
LogAnalysis mailing list
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis

> > 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?

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

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot
.com
    http://www.info-secure.org

_______________________________________________
LogAnalysis mailing list
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis

Anton Chuvakin wrote:
>Ouch, how about security? I guess we are dealing with
some case of
>mental inertia here

All the current trend toward legislating compliance has
accomplished is setting the bar very low, and encouraging
companies to look only at meeting that standard. I've had
senior IT managers tell me "We are going to do the
exact
minimum, wherever possible."

In log analysis terms, that means that the logs to to a big
bucket which is periodically dumped into the compost
heap. Nobody'll look in the bucket until someone passes
legislation requiring people to LOOK at it. And, of course,
when that happens, they'll do the exact minimum, &c...

mjr. 

_______________________________________________
LogAnalysis mailing list
LogAnalysislists.shmoo.com
h
ttp://lists.shmoo.com/mailman/listinfo/loganalysis