towards CEE logging recommendation (help from the group needed!)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

towards CEE logging recommendation (help from the group needed!)

Anton Chuvakin
All,

As you know, logging recommendations are the 4th pillar of CEE, in
addition to log format, log taxonomy and log transport. With this
email I wanted to launch the effort for creating such recommendations
(further CEE-LR).

First, what do we want to achieve with this? Here is what the upcoming
CEE whitepaper says about it:  "The Common Event Log Recommendations
provide logging guidance of  CEE initiative. With a common way of
expressing events, it is possible to advocate what events products
should log. While it should be expected that a firewall should log
events such as blocked connection attempts, there is no logging
advisements. Should firewalls log all rule change events? What about
login and administration events? CELR will assure that administrators
receive an entire view of all auditable events.

CEE-LR are not only concerned with what events to log, but also
addresses what information such as level of detail should be logged.
This translated to "what are the various event representation elements
and how should they be fulfilled?" Returning to the firewall example,
there should be recommendations as to what data should be included
with various firewall-related events: source, destination, NAT'ed
sources, ports, protocols, and the connection result (allowed,
dropped, etc.). Further considerations include how applications should
log certain events – username, source, connection method, and results
for authentication; configuration changes; and a plethora of other
important event information."

So, as a first step to CEE-LR I would like to summarize all the
logging guidance that is available (yes, a mammoth task indeed).
What are some of the sources of such guidance?

Regulations and industry mandates: all the PCI DSS, NIST, NERC, DISA
STIGs, FISMA, ISO, ITIL, HIPAA and the rest of the compliance
abbreviation soup. From this list, only a few have details (e.g. PCI
DSS) and not just say "appropriate level of logging MUST :-) be
enabled" …

Vendor recommendations: MS, for example, have a lot of suggested
logging guidance. Other OS and even application (e.g. database)
vendors have their ideas on what should be logged.

Community recommendations: for example, loganalysis list had a big
discussion on this subject a few times (e.g.
http://lists.shmoo.com/pipermail/loganalysis/2002-August/thread.html)
SANS  ran a small project last year to create something similar as
well (I can share the document)

I am compiling a list of all sources that contain logging guidance. A
good attempt to do the same is also available here (even though with a
slightly different focus on retention periods):
http://www.splunkbase.com/howtos/Systems_Management/Logging/howto:HOWTOidentifyrelevantdataretentionperiods

Finally, some of the unanswered questions about CEE-LR are:

- Presumably, one set of logging recommendations for all environments
is not possible. How can this be structured – per industry, per
logging device, per regulation?

- How can one address both "what logging to add to an application?"
(for developers) as well as "what logging to turn on in an
application" (for IT operations)?

- Some guidance (especially from regulations) is mandatory while the
rest is "suggested"; many people are looking to do "what they must"
while others are looking to do "what's right." This needs to be
reflected in recommendations somehow (min vs optimum logging?)

Please answer them :-) or contribute in some other way, such as by
suggesting other sources for logging guidance and recommendations.

P.S. I swear this will be less controversial than taxonomy - which we
will definitely revisit!

Best,
--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot.com
    http://www.info-secure.org
Reply | Threaded
Open this post in threaded view
|

Re: towards CEE logging recommendation (help from the group needed!)

David Corlette
Hello,

Question: are we drawing a distinction between what I would call "logging" (e.g. low level details about what the software is doing) versus "auditing" (e.g. high-level events that tell us what people, perhaps indirectly, are doing)?

The below quote seems to be leaning this way, but I would also like to note that the two domains not only imply different types of event messages, but also very different requirements as to how the log data is handled.  For example:
1a) The system administrator should be able to change the log level of the application to get more or less detail about internal operations.
2a) The system admin should *not* be able to change the auditing behavior of the system as defined by the auditor.

1b) The log data should be written to e.g. a local file in plain text so it can be tailed and so forth
2b) The audit data should be protected from disclosure and modification as it is delivered and stored

There are a number of other distinctions one could draw here, but the point being that if you are thinking about "classes" of events to log, it might also make sense to reflect those classes in the logging/auditing infrastructure.

> - How can one address both "what logging to add to an application?"
> (for developers) as well as "what logging to turn on in an
> application" (for IT operations)?
Reply | Threaded
Open this post in threaded view
|

Re: towards CEE logging recommendation (help from the group needed!)

Raffael Marty-3
I think you are bringing up an interesting point. However, I don't  
think it's a function of the log messages. It's more a function of the  
logging infrastructure. Some logging levels and behaviors should be  
adjustable only by certain people. The log messages (syntax) for audit  
trails or log messages (I am using your terminology right now) don't  
have to look different. The event taxonomy, however, might make a  
distinction for the events.

   -raffy

--
   Raffael Marty
   Chief Security Strategist                           @ Splunk>
   Security Visualization: http://secviz.org       raffy.ch/blog



On Feb 7, 2008, at 11:47 AM, David Corlette wrote:

> Hello,
>
> Question: are we drawing a distinction between what I would call  
> "logging" (e.g. low level details about what the software is doing)  
> versus "auditing" (e.g. high-level events that tell us what people,  
> perhaps indirectly, are doing)?
>
> The below quote seems to be leaning this way, but I would also like  
> to note that the two domains not only imply different types of event  
> messages, but also very different requirements as to how the log  
> data is handled.  For example:
> 1a) The system administrator should be able to change the log level  
> of the application to get more or less detail about internal  
> operations.
> 2a) The system admin should *not* be able to change the auditing  
> behavior of the system as defined by the auditor.
>
> 1b) The log data should be written to e.g. a local file in plain  
> text so it can be tailed and so forth
> 2b) The audit data should be protected from disclosure and  
> modification as it is delivered and stored
>
> There are a number of other distinctions one could draw here, but  
> the point being that if you are thinking about "classes" of events  
> to log, it might also make sense to reflect those classes in the  
> logging/auditing infrastructure.
>
>> - How can one address both "what logging to add to an application?"
>> (for developers) as well as "what logging to turn on in an
>> application" (for IT operations)?
>
Reply | Threaded
Open this post in threaded view
|

Re: towards CEE logging recommendation (help from the group needed!)

ArkanoiD
I think log event management is more about entity binding and corellation
rather than just "syslog storage and analysis" ;-) Say, proper audit trail
should be bound to "subjects" more than "devices and programs".

On Thu, Feb 07, 2008 at 11:52:22AM -0800, Raffael Marty wrote:

> I think you are bringing up an interesting point. However, I don't  
> think it's a function of the log messages. It's more a function of the  
> logging infrastructure. Some logging levels and behaviors should be  
> adjustable only by certain people. The log messages (syntax) for audit  
> trails or log messages (I am using your terminology right now) don't  
> have to look different. The event taxonomy, however, might make a  
> distinction for the events.
>
>   -raffy
>
> --
>   Raffael Marty
>   Chief Security Strategist                           @ Splunk>
>   Security Visualization: http://secviz.org       raffy.ch/blog
>
>
>
> On Feb 7, 2008, at 11:47 AM, David Corlette wrote:
>
> >Hello,
> >
> >Question: are we drawing a distinction between what I would call  
> >"logging" (e.g. low level details about what the software is doing)  
> >versus "auditing" (e.g. high-level events that tell us what people,  
> >perhaps indirectly, are doing)?
> >
> >The below quote seems to be leaning this way, but I would also like  
> >to note that the two domains not only imply different types of event  
> >messages, but also very different requirements as to how the log  
> >data is handled.  For example:
> >1a) The system administrator should be able to change the log level  
> >of the application to get more or less detail about internal  
> >operations.
> >2a) The system admin should *not* be able to change the auditing  
> >behavior of the system as defined by the auditor.
> >
> >1b) The log data should be written to e.g. a local file in plain  
> >text so it can be tailed and so forth
> >2b) The audit data should be protected from disclosure and  
> >modification as it is delivered and stored
> >
> >There are a number of other distinctions one could draw here, but  
> >the point being that if you are thinking about "classes" of events  
> >to log, it might also make sense to reflect those classes in the  
> >logging/auditing infrastructure.
> >
> >>- How can one address both "what logging to add to an application?"
> >>(for developers) as well as "what logging to turn on in an
> >>application" (for IT operations)?
> >
>
> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>
Reply | Threaded
Open this post in threaded view
|

Re: towards CEE logging recommendation (help from the group needed!)

ArkanoiD
I mean we need some corellator thing to tell "it is the same person who
sent this email and who copied this sensitive document to external storage!" -
working the way we can easily SELECT or even grep that out ;-)

On Fri, Feb 08, 2008 at 06:36:23PM +0300, ArkanoiD wrote:

> I think log event management is more about entity binding and corellation
> rather than just "syslog storage and analysis" ;-) Say, proper audit trail
> should be bound to "subjects" more than "devices and programs".
>
> On Thu, Feb 07, 2008 at 11:52:22AM -0800, Raffael Marty wrote:
> > I think you are bringing up an interesting point. However, I don't  
> > think it's a function of the log messages. It's more a function of the  
> > logging infrastructure. Some logging levels and behaviors should be  
> > adjustable only by certain people. The log messages (syntax) for audit  
> > trails or log messages (I am using your terminology right now) don't  
> > have to look different. The event taxonomy, however, might make a  
> > distinction for the events.
> >
> >   -raffy
> >
> > --
> >   Raffael Marty
> >   Chief Security Strategist                           @ Splunk>
> >   Security Visualization: http://secviz.org       raffy.ch/blog
> >
> >
> >
> > On Feb 7, 2008, at 11:47 AM, David Corlette wrote:
> >
> > >Hello,
> > >
> > >Question: are we drawing a distinction between what I would call  
> > >"logging" (e.g. low level details about what the software is doing)  
> > >versus "auditing" (e.g. high-level events that tell us what people,  
> > >perhaps indirectly, are doing)?
> > >
> > >The below quote seems to be leaning this way, but I would also like  
> > >to note that the two domains not only imply different types of event  
> > >messages, but also very different requirements as to how the log  
> > >data is handled.  For example:
> > >1a) The system administrator should be able to change the log level  
> > >of the application to get more or less detail about internal  
> > >operations.
> > >2a) The system admin should *not* be able to change the auditing  
> > >behavior of the system as defined by the auditor.
> > >
> > >1b) The log data should be written to e.g. a local file in plain  
> > >text so it can be tailed and so forth
> > >2b) The audit data should be protected from disclosure and  
> > >modification as it is delivered and stored
> > >
> > >There are a number of other distinctions one could draw here, but  
> > >the point being that if you are thinking about "classes" of events  
> > >to log, it might also make sense to reflect those classes in the  
> > >logging/auditing infrastructure.
> > >
> > >>- How can one address both "what logging to add to an application?"
> > >>(for developers) as well as "what logging to turn on in an
> > >>application" (for IT operations)?
> > >
> >
> > email protected and scanned by AdvascanTM - keeping email useful -
> > www.advascan.com
> >
>
> email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: towards CEE logging recommendation (help from the group needed!)

Caudle, Rodney
In reply to this post by ArkanoiD
 
I agree with this statement.  Ultimately, whether talking about auditing or
logging, the information that is expressed involves the interactions of
entities (users, hosts or objects) and some information about what occurred.
The log recommendations should clearly state (a) what entities are involved
and (b) what information is needed about the action that occurred to
generate the event.  The word "needed" is used instead of "desired" because
a minimal amount if information has to be there to be able to remove
ambiguity about what just occurred.

Rodney Caudle

-----Original Message-----
From: ArkanoiD [mailto:[hidden email]]
Sent: Friday, February 08, 2008 10:36 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] towards CEE logging recommendation (help
from the group needed!)

I think log event management is more about entity binding and corellation
rather than just "syslog storage and analysis" ;-) Say, proper audit trail
should be bound to "subjects" more than "devices and programs".

On Thu, Feb 07, 2008 at 11:52:22AM -0800, Raffael Marty wrote:

> I think you are bringing up an interesting point. However, I don't
> think it's a function of the log messages. It's more a function of the
> logging infrastructure. Some logging levels and behaviors should be
> adjustable only by certain people. The log messages (syntax) for audit
> trails or log messages (I am using your terminology right now) don't
> have to look different. The event taxonomy, however, might make a
> distinction for the events.
>
>   -raffy
>
> --
>   Raffael Marty
>   Chief Security Strategist                           @ Splunk>
>   Security Visualization: http://secviz.org       raffy.ch/blog
>
>
>
> On Feb 7, 2008, at 11:47 AM, David Corlette wrote:
>
> >Hello,
> >
> >Question: are we drawing a distinction between what I would call
> >"logging" (e.g. low level details about what the software is doing)
> >versus "auditing" (e.g. high-level events that tell us what people,
> >perhaps indirectly, are doing)?
> >
> >The below quote seems to be leaning this way, but I would also like
> >to note that the two domains not only imply different types of event
> >messages, but also very different requirements as to how the log data
> >is handled.  For example:
> >1a) The system administrator should be able to change the log level
> >of the application to get more or less detail about internal
> >operations.
> >2a) The system admin should *not* be able to change the auditing
> >behavior of the system as defined by the auditor.
> >
> >1b) The log data should be written to e.g. a local file in plain text
> >so it can be tailed and so forth
> >2b) The audit data should be protected from disclosure and
> >modification as it is delivered and stored
> >
> >There are a number of other distinctions one could draw here, but the
> >point being that if you are thinking about "classes" of events to
> >log, it might also make sense to reflect those classes in the
> >logging/auditing infrastructure.
> >
> >>- How can one address both "what logging to add to an application?"
> >>(for developers) as well as "what logging to turn on in an
> >>application" (for IT operations)?
> >
>
> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: towards CEE logging recommendation (help from the group needed!)

Tina Bird
Quoting "Caudle, Rodney" <[hidden email]>:

> I agree with this statement.  Ultimately, whether talking about auditing or
> logging, the information that is expressed involves the interactions of
> entities (users, hosts or objects) and some information about what occurred.
> The log recommendations should clearly state (a) what entities are involved
> and (b) what information is needed about the action that occurred to
> generate the event.  The word "needed" is used instead of "desired" because
> a minimal amount if information has to be there to be able to remove
> ambiguity about what just occurred.

Hi all -- I'm jumping into this discussion rather late, cos most of  
the juicy bits seem to have taken place while I was in the (painful!)  
process of moving from San Jose, California to Austin, Texas. I have  
responses for several threads on this list and on the Log Analysis  
list which I'm hoping to compose in the next day or so.

Maybe the discussion would be simplified if we went back to journalism  
school? My ultimate goal, when designing and using a logging  
infrastructure (it goes double for actual *auditing* purposes, rather  
than "record keeping"), is to capture the who-what-when-where-why of a  
particular event. These "fields", if that's the right word for them,  
ought to exist for most operating systems, applications and devices:

Who -- the user, process, crontab entry, whatever, that triggered the event
  ** complications: are different security contexts defined for a  
given user in different circumstances? Is "root" sufficient, or do I  
need to come up with a way to trace how root priv is being evoked? Can  
entities act as proxies for other entities?

What -- the event or system change captured in the event record,  
probably incorporating the object of an action as well as the action  
itself
  ** complications: a single user action triggering multiple changes?  
One event affecting many parts of the OS or application? At what level  
of detail is "what" defined? [For instance, "backup initiated" is a  
very high level summary of a lot of low level file permissions checks,  
copies, database updates, etc...]

When -- the timestamp associated with the event
  ** complications: reliable time synchronization throughout the  
network? Time zones? Does the event have a duration? Do I record start  
and end time, start and duration, or what? What if the user scheduled  
the event for a later time? What about conflicts between the time  
reported for the event itself and the time the record was created  
locally, or received at the central loghost?

Where -- sources, destinations, locations in the filesystem or AD forest
  ** complications: hostname or IP address? Hierarchical naming?  
Private vs. routable addresses?

Why -- the set of conditions or system context that caused the event  
to occur, or that were in place when the event happened
  ** complications: As in all good mystery novels, "motive" is often  
the hardest part of a crime to discover, because it's the least  
tangible quality of an event.

This is simple-minded, but at least it's a way to start looking at a  
minimum level of information required for an event record to store  
actionable, auditable data on system activity.

I've got sample data from my tutorials and postings on Log Analysis  
(as well as various repositories of log data from other folks); I will  
try taking this journalism approach to see if it makes it easier to  
identify the important fields that are already in the data, as well as  
info that's missing.

I should also add that at the time this thread started, I was busily  
compiling a list of administrative log records for Cisco firewall  
devices. As I've gone through the voluminous Cisco log documentation,  
I've been noting which variables are recorded by default, as well as  
adding my own recommendations for additional information that would  
make the messages more useful to the firewall administrator. I haven't  
quite finished that list yet (there are an *awful* lot of Cisco  
PIX/ASA log messages out there), but when I do I'll provide a summary  
here and to the Log Analysis list -- it may be a useful source of  
"observational" data on firewall records, variables and missing  
information.

cheers -- tbird