Re: Eventlog to syslog

Quoting David Corlette <[email protected]>:

> 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