Re: [logs] Eventlog to syslog Mar 01 2008 04:34AM
tbird precision-guesswork com
Quoting David Corlette <DCorlette (at) novell (dot) com [email concealed]>:

> Why not have them implement a modern, secure auditing standard? The
> CEE and XDAS work is promising, and is getting analysts attention
> (Burton, for one). They aren't complete yet, but if you look at
> the requirements they embody you will see why insecure syslog
> really isn't the way to go. In fact, *nix OSs are moving away
> from syslog - witness LAF on Linux, BSM on Solaris, etc....
> Anything that might have security-relevance needs to be treated a
> little more carefully.
> And yeah, I know that there are all sorts of more secure extensions
> to syslog, but they aren't "standards," at least not yet.

Whoa, d00d, talk about comparing apples and oranges...you've got
apples, tomatoes, sheep and, uh, oil filters in there ;-) There are at
least 4 different areas to consider:

- what events to record
-- and what information is vital for each event
- how to secure the log data locally
- how to transport the log data to a central location securely and reliably

I'm not familiar with LAF, but BSM and its cohorts are host-based
auditing systems; they enhance a host's ability to record activity and
detect unauthorized activity by increasing the amount of record
keeping the OS does. These are alarms, which are certainly a vital
part of a monitoring infrastructure, especially when you consider how
completely *awful* most operating systems and applications are at
recording unusual behavior.

These tools come under the category of what to log, and how much to
log about what you log; they're generally controlled by configuring
specific applications or kernel parameters, *not* by configuring
syslog. syslog configuration controls how much data is stored, but has
no control about how much data is generated in the first place.

BSM et al. are not syslog *replacements*. syslog is not an alarm of
any sort; it's just a collection mechanism with rudimentary volume
controls and transport capabilities. You can send BSM output to syslog
for archiving and reporting. One doesn't replace the other.

Most folks who are worried about secure local storage and data
transport are happy with SSL/TLS transport mechanisms and digital
signatures for data integrity, despite the lack of a finalized
"standard" requiring these tools. Of course, syslog-reliable and
syslog-secure are still being implemented, but to some extent they've
been swamped by the real world adoption of TLS as the answer to
transport security (at least as long as you don't worry about
certificate validation).

The transport and storage problem is basically solved; it's getting it
implemented as widely as plain ol' syslog that's taking forever. I think
any company that can manage to provide an HTTPS Web GUI for its
product ought to be able to provide syslog over SSL, although the
product space seems to be
unaware of that. Sigh.

To summarize, there are several (at least) independent components of
"system audit" or "system logging" getting mixed up together here:

- What system events "should" be recorded? What information about
those events is required to make the records actionable (for
troubleshooting, compliance reporting, whatever)?
- How do we generate reliable event data, minimizing the chances for
data loss, forgery, etc?
- How do we store the event data safely?
- How do we move the event data safely?

Microsoft is way ahead of most UNIXen when it comes to recording and
securing a set of basic system messages (cf. my earlier posts about
the Security Event
Log), and its logging is vastly easier to configure and parse than
most "average" syslog data; not to mention BSM output or audit data
from the mandatory-access-control systems I've used, which as we've
recently seen are, uh, arcane. But MS falls down when it comes to
using a standards-based mechanism for aggregating all that data.

If we consider the transport piece of the problem by itself, it's easy
to criticize Microsoft; and although there's plenty of room for
criticizing the
security of syslog, it's also true that the combination of SSL/TLS for
transport and digital signing provides a "good enough" secure
transport mechanism for a lot of people.

Wow. Guess I just unpacked my soapbox from my move :-) I should point
out that I am consulting for Splunk, a contender in the IT data
management space; and that I'm on the CEE discussion list; and that
I've tossed the occasionally comment over the wall at the folks
working on syslog-reliable and syslog-secure.

And I'm still getting hung up on the first part of the task list up
there: what events do we *want* to record, and what do we need to know
about them??? More on that over the weekend...I've got a bunch of
references to check, and then a lot of summarizing to do.

cheers -- tbird

LogAnalysis mailing list
LogAnalysis (at) loganalysis (dot) org [email concealed]

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus