]]> Wed, 21 Mar 2007 12:44:46 -0700 Tom Le http://lists.jammed.com/loganalysis/2007/03/0024.html hi all,
I have finished the work on the log preprocessing module called LogPP
(http://logpp.sourceforge.net) - the very first alpha version is
available at http://prdownloads.sourceforge.net/logpp/logpp-0.12.tar.gz
The tool is able to tail an arbitrary number of log files, apply regexp
filters to incoming lines, and write output to files, syslog or external
programs. The tool supports both Perl-compatible and POSIX-style regular
expressions, and multi-line matching. One can employ logpp as a filter
in front of a more complex log analysis software (e.g., SEC), but also
as a standalone tool for converting non-syslog multi-line logs messages
to syslog format.
Currently, there is no separate mailing list or forum for logpp, so you
can post your comments to my private e-mail address.
br,
risto
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Mon, 26 Mar 2007 12:33:57 +0300 Risto Vaarandi http://lists.jammed.com/loganalysis/2007/03/0010.html > 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."

No kidding - but, at the same time, those organizations who used to
fly (eh, crawl) BELOW that low bar would benefit if they are kicked
into doing at least *something*. So, I am a bit more positive about
such compliance motivators.

> In log analysis terms, that means that the logs to to a big
> bucket which is periodically dumped into the compost
> heap.

Indeed, this is common but compare this to a) never enabling logging
or b) disabling logging or c) storing logs based on short default
retention policy on each device? A huge improvement, isn't it?

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

Well, this already happened: e.g. PCI. It doesn't define what
"looking" means, but running a log analysis tool sure beats just
running a tape drive to save the logs...

Best,
--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
http://www.chuvakin.org
http://chuvakin.blogspot.com
http://www.info-secure.org
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Wed, 21 Mar 2007 14:46:58 -0700 Anton Chuvakin http://lists.jammed.com/loganalysis/2007/03/0018.html 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
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Thu, 22 Mar 2007 11:00:49 -0400 Marcus J. Ranum http://lists.jammed.com/loganalysis/2007/03/0013.html Anton Chuvakin wrote:
>> 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."
>
> No kidding - but, at the same time, those organizations who used to
> fly (eh, crawl) BELOW that low bar would benefit if they are kicked
> into doing at least *something*. So, I am a bit more positive about
> such compliance motivators.

I'm not. The other aspect of working towards compliance is that
organisations often only focus on those things that you have to be
compliant with. Given limited IT Security budgets this is sometimes at
the expense of what could actually be important. It also sometimes
leads to the thinking - "We're SOX/PCI/CoBIT etc etc compliant and
therefore secure".

>
>> In log analysis terms, that means that the logs to to a big
>> bucket which is periodically dumped into the compost
>> heap.
>
> Indeed, this is common but compare this to a) never enabling logging
> or b) disabling logging or c) storing logs based on short default
> retention policy on each device? A huge improvement, isn't it?

And the value add is? You spend all that money on log aggregation and
retention but do nothing with the logs? Where is the security and
business benefit here? What exactly is the business case? "Gee it'd be
nice if we had all these logs in one place" wouldn't be moving my dollars.

>
>> 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...
>
> Well, this already happened: e.g. PCI. It doesn't define what
> "looking" means, but running a log analysis tool sure beats just
> running a tape drive to save the logs...

Unless 'looking' is defined, linked to business requirements and
security outcomes/benefits, then what exactly are you analysing? Again,
what's the value add?

Regards

James Turnbull

--
James Turnbull <james@private>
---
Author of Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)

Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

• application/pgp-signature attachment: OpenPGP digital signature
  

]]> Thu, 22 Mar 2007 14:51:39 +1100 James Turnbull http://lists.jammed.com/loganalysis/2007/03/0007.html > Performance reasons might be of the past.
> There are non-intrusive DB auditing solutions out there that
> are very low on maintenance and has zero impact on performance.
> These solutions do not work off of the DB server. Instead, they
> monitor the network traffic directed to and from the DB server
> and they sit on an applicance of their own.

In every DB audit/monitoring case I have participated or had extensive
discussions, everyone wanted to monitor local admin activity. This is a key
issue for audit controls, and since all DB auditing I believe are always
compliance driven, if you can't cover on-the-box admin access, it's not
worth implementing one of these in-line app layer appliances.

The in-line solutions also typically only cover sql traffic it can see.
There is a lot that goes on with a DB as you know including stored
procedures, triggers, job automation, etc. The in-line appliances have a
variety of ways to address this but they solutions are never complete and
always intrusive (e.g. they need to log into the DB). If you cannot be 100%
passive and you lack coverage, I haven't seen a customer yet adopt the
in-line solution for DB auditing. The only reason I've seen in-line sql
monitoring is for sql injection coverage for very large web server farms (an
IDS role rather than compliance).

Performance usually is not a problem once you intelligently identify the
compliance controls. Each auditor has different requirements (which makes
life hard for log analysis), but in no case have I had an auditor tell us
"monitor everything". Usually the "performance issue" is first raised by
the DBA's at project introduction. Once they accept the compliance mandate
and realize we only have to monitor a subset of transactions, it doesn't
become as much of an issue.

What I'm suggesting to answer Anton's original question is that DB auditing
is not "hot" because it won't be championed by internal users. DBA's
implement it reluctantly. It requires a compliance mandate and even then
encounters various levels of resistance. When you look at other log
analysis projects (such as security event monitoring or log aggregation),
you'll find other internal champions where none exists for DB auditing.
YMMV.



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

]]> Mon, 19 Mar 2007 09:40:56 -0700 Tom Le http://lists.jammed.com/loganalysis/2007/03/0022.html 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

]]> Fri, 23 Mar 2007 12:06:33 -0400 Fenwick, Wynn http://lists.jammed.com/loganalysis/2007/03/0016.html Anton Chuvakin wrote:

> No kidding - but, at the same time, those organizations who used to
> fly (eh, crawl) BELOW that low bar would benefit if they are kicked
> into doing at least *something*. So, I am a bit more positive about
> such compliance motivators.

I totally agree here. Organizations with some knowledge will already do
more than that - the clueless ones will _at least_ do that.

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

]]> Thu, 22 Mar 2007 12:22:03 +0100 Stefano Zanero http://lists.jammed.com/loganalysis/2007/03/0011.html > DBA's
> implement it reluctantly. It requires a compliance mandate and even then
> encounters various levels of resistance. When you look at other log
> analysis projects (such as security event monitoring or log aggregation),

Huh? What does "log aggregation" mean here? Shouldn't database logs part of it?!

--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
http://www.chuvakin.org
http://chuvakin.blogspot.com
http://www.info-secure.org
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Wed, 21 Mar 2007 14:52:24 -0700 Anton Chuvakin http://lists.jammed.com/loganalysis/2007/03/0019.html Any one come across documentation for an Win 2003 528 event with the
Login type set to 12? All documentation I can find doesn't list the
type 12 login.


**************************************************************************
This electronic message may contain confidential or privileged information
and is intended for the individual or entity named above. If you are
not the intended recipient, be aware that any disclosure, copying,
distribution or use of the contents of this information is prohibited.
If you have received this electronic transmission in error, please notify
the sender immediately by using the e-mail address or by telephone
(704-633-8250).
**************************************************************************
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Thu, 22 Mar 2007 12:47:12 -0400 Tyler, Grayling http://lists.jammed.com/loganalysis/2007/03/0005.html > 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. DBA's hate enabling auditing both
for performance and maintenance reasons. Monitoring for other types of
assets is often welcome by internal champions (systems, security devices,
networking device, etc.). Monitoring of non-DBA assets also has
non-security & non-compliance related benefits as well and can therefore be
more easily justified either from cost or mind-share perspective. But DBA
auditing is rarely championed by anyone other than the auditors.

Tom



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

]]> Sat, 17 Mar 2007 22:03:10 -0700 Tom Le http://lists.jammed.com/loganalysis/2007/03/0020.html 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

]]> Fri, 23 Mar 2007 04:19:21 -0400 Mordechai T. Abzug http://lists.jammed.com/loganalysis/2007/03/0014.html >
> > 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."
>
> No kidding - but, at the same time, those organizations who used to
> fly (eh, crawl) BELOW that low bar would benefit if they are kicked
> into doing at least *something*. So, I am a bit more positive about
> such compliance motivators.


In most cases the fine grain auditing we're talking about in this thread
(DB, OS, app layer transactions) are wolves too far away from the sleigh.
Companies are just beginning to adopt centralized log aggregation for things
like host based logs, IDS/IPS traffic, and networking devices. DB, OS, and
app transaction logging/monitoring is discussed but always the first to get
cut.

There's also a major analysis & reporting issue here that can't be ignored.
You can look at a Windows, Unix, IDS, or firewall message and any IT or
security admin will, generally speaking, know what to do with it. When you
wrap correlation or other monitoring value around those log events, people
know whey mean. They understand X failed logins in Y minutes is meaningful.

But they have a hard time understanding the meaning behind inserts,
updates, drops, grants, revokes, etc.. This is because so much context is
required to understand each environment. This is true for DB, OS, and app
layer auditing.

So you have no internal champions (I know I'm repeating myself) for this
type of logging. You have higher complexity and lower (immediately
observable) benfit. I just don't see companies adopting this granular
auditing/logging/monitoring with a few exceptions. There will always be
compliance drivers, but like Marcus said it's a big ambiguous "do the
minimum" approach and host, IDS, and network logs are easy ways to tackle
the audit requirements even if incomplete.

Tom



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

]]> Wed, 21 Mar 2007 21:05:37 -0700 Tom Le http://lists.jammed.com/loganalysis/2007/03/0008.html 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
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Wed, 21 Mar 2007 14:25:02 -0400 Marcus J. Ranum http://lists.jammed.com/loganalysis/2007/03/0023.html Hi all -

Many list readers - not to mention folks who aren't subscribed to this list
- have commented on the fact that the Log Analysis Web site seems to have
fallen into hibernation. Marcus and I have also noticed that meaty
discussions on the list are less and less frequent than they were several
years ago.

It's unlikely that this slump is due to the fact that everyone's figured out
what to do with their logs.

I've certainly got lots of reasons for why I'm not as involved with it as I
was in 2004, primarily related to changes in my job focus and (mostly
negative) changes in my health. At the moment, I have a mailbox bulging with
site updates, at which I stare guiltily at least twice a week, and a list
moderation queue almost entirely filled with spam, this week's discussion of
data base auditing notwithstanding.

After much discussion, review of the much-evolved "enterprise log
management" space (please substitute your own favorite description for
commercial products that do the things we're all trying to do with our
logs), and my experience in working with the Patch Management mailing list
(which has maintained its vendor neutrality despite being sponsored by
Shavlik, one of the patch management product vendors) Marcus and I have
entered into a partnership with Splunk for the support and management of
this mailing list and loganalysis.org.

This decision was not made lightly, and on my part at least is mostly based
on Splunk's determinimation to build a publicly-available knowledge base for
log messages and end-to-end event log management. Those of you who were here
in the early days will remember that that has always been one of my goals
for loganalysis.org; but as it turned out, we didn't have the time or
resources to devote to building it a community exchange and database. My
discussions with Splunk - and their dedication to a "community commons" type
of arrangement for Splunkbase - convinced me that the partnership will
benefit everyone involved.

Splunk has acquired both loganalysis.org and this list. Within the next few
days, we will be migrating the mailing list from my shmoo.com listserver to
their dedicated loganalysis.org list serv installation. If you are currently
subscribed, you don't need to make any changes - we're just migrating the
list of subscribers directly from the old to the new server. The list will
now have the address loganalysis@private (which probably should have
happened years ago).

I will maintain the server at the old address for a while, in order to
capture any genuine posts to the list which accidentally get sent to the
wrong address. I will remain a moderator; Dee-Ann LeBlanc, the content
manager for SplunkBase, is my moderator-in-training; and depending on how
things go we may recruit another external expert to assist. We will continue
to moderate the list in the same fashion I've done since its inception; the
discussions will remain vendor neutral, and all discussions of particular
commercial and open source products will emphasize the technical
capabilities of the applications, as well as "real world" experience from
list members.

The loganalysis.org site is being maintained independently from Splunkbase,
at least for the foreseeable future, and I may be contacting the list for
assistance with its maintenance at some point in the next couple of weeks.
It seems to me that I'd save myself a lot of time (and subsequent guilt) if
we morphed it into a Wiki, an option which didn't really exist when Marcus
and I first set things up.

Please feel free to contact me off-list if you have questions or concerns
about this change. My access to email is somewhat intermittent, because of a
family health crisis, but I will make every reasonable effort to respond to
messages in a timely fashion.

As we make the transition to the new server, we may send out one or two test
messages. These will be marked as such in the subject line; please disregard
them.

Thanks very much for your ongoing support of this list.

cheers -- tbird

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

]]> Fri, 23 Mar 2007 13:44:39 -0700 Tina Bird http://lists.jammed.com/loganalysis/2007/03/0017.html 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.com@private
[mailto:loganalysis-bounces+wynn.fenwick=cgi.com@private] On
Behalf Of Marcus J. Ranum
Sent: Wednesday, March 21, 2007 2:25 PM
To: Anton Chuvakin; LogAnalysis@private
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
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Thu, 22 Mar 2007 10:12:36 -0400 Fenwick, Wynn http://lists.jammed.com/loganalysis/2007/03/0012.html Anton Chuvakin wrote:
>A huge improvement, isn't it?

I'm not trying to be a wiseass, but we've all heard of countless
"huge improvements" going on in computer security. Gargantuan
sums of money have been spent. Yet I see no sign whatsoever
of the situation improving, unless you're:
a) a security consultant
b) a pen tester
c) someone who sells compliance-mandated security products

Systems appear to be just as penetrable as they were 10 years
ago. Data appears to be just as exposed as it was 10 years ago
(it just shows up in the press now, whenever a customer database
is dumped). Organizations appear to be just as clueless about
what's going on in their networks as before. Etc.

Let's enjoy it while we can. But sooner or later the bean-counters
are going to come looking for all that return on security investment
and all we'll have to show them is....? Well - the constant stream
of disasters has to stop.

mjr.

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

]]> Wed, 21 Mar 2007 23:28:31 -0400 Marcus J. Ranum http://lists.jammed.com/loganalysis/2007/03/0006.html > > 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
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis

]]> Mon, 19 Mar 2007 09:50:33 -0700 Anton Chuvakin http://lists.jammed.com/loganalysis/2007/03/0021.html > Any one come across documentation for an Win 2003 528 event with the
> Login type set to 12? All documentation I can find doesn't list the
> type 12 login.

Logogn type 12 is CachedRemoteInteractive
They say it is the same as RemoteInteractive (10), except used internally
for auditing purposes.

See http://msdn2.microsoft.com/en-us/library/aa380129.aspx

Frank Heyne
http://www.heysoft.de/

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

]]> Fri, 23 Mar 2007 14:10:14 +0100 Frank Heyne http://lists.jammed.com/loganalysis/2007/03/0015.html On 3/21/07, Anton Chuvakin <anton@private> wrote:
>
> > DBA's
> > implement it reluctantly. It requires a compliance mandate and even
> then
> > encounters various levels of resistance. When you look at other log
> > analysis projects (such as security event monitoring or log
> aggregation),
>
> Huh? What does "log aggregation" mean here? Shouldn't database logs part
> of it?!


"Log aggregation" in the above context means implementing centralized
logging. Most database logs at most companies are not sent to a centralized
log server.

"Security event monitoring" means either an internal SIM/SIEM or outsourcing
to an MSSP.

Companies are only beginning to adopt solutions around these two areas.
Sure, companies do some of this to varying degrees (e.g. they send all Unix
logs to a centralized server), but my point is that when you are adopting a
new policy/process/paradigm, you tend to implement it in stages. The stages
that are likely to internal champions are the system, security, and network
logging/monitoring. This is because the use of centralized log aggregation
or SIM/SIEM/MSSP solutions greatly improve the quality of work these users
(system, security, and network admins).

The application admins and DBA's have traditionally never championed
auditing. It's a nuisance to them. They offer resistance and often
implement it reluctantly.

It's hard enough trying to convince customers to adopt a new technology when
all the technical recommenders agree. A vendor recommends a whiz bang
solution and everyone agrees it's needed and useful. You still have to sell
management on cost vs. benefits. Now imagine a scenario where the technical
recommenders (DBA's, application admins) are reluctant the minute the topic
comes up.

You might want to consider hiring a focus group (like San Jose Focus) to
talk to DBA's and IT security managers. You'll be able to dig even deeper
into this issue. It's been money well spent IME for product & marketing
analysis.

Tom



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

]]> Wed, 21 Mar 2007 21:23:04 -0700 Tom Le