Collect the log data you need without the fire-hose

With all the regulatory and compliance requirements surrounding log and security event management, a typical scenario is to “log everything” – even though the regulation or compliance control objective typically articulates a requirement “…to collect and archive audit trail data”. Audit trails or “interesting” log messages generated by operating systems, applications, or network devices are really a subset of all the logs that are being generated.

This is where a review of logging configurations and what to log is necessary. Every environment and its logging requirements will vary. Some may only need the logs to be collected and archived, others may require the logs to be collected to provide active alerting on configuration changes, and still others may need detailed logging to capture all administrative activities..

In a perfect world, this effort is initiated and supported by management, involving input from a variety of knowledgeable people throughout the organization (e.g. application developers, system administrators, DBAs, auditors, security administrators, etc.). Each system/application/device’s logging capabilities and configurations would be properly to ensure that all desired actions are logged. This allows each group to properly configure logging levels, ensuring that all logs required for security and/or compliance are being retained and made available for analysis.

Whether or not this “perfect world” scenario is feasible, administrators can still follow best practices by configuring and tuning their logging configurations to focus on logs that are pertinent to their requirements.

Given their widespread enterprise footprint, I’ll use Cisco devices as an example of how this can work. Let’s assume you’re required to log and capture only successful logins and configuration changes as well as any operational related errors. Let’s also assume the following:

  1. Successful Logins = severity level of 6 (Informational)
  2. Configuration Changes = severity level of 5 (Notifications)
  3. Error conditions = severity level of 3 (Errors)

It’s common to see logging for Cisco devices to be set with a default configuration logging at severity level 6. This means all logs with severity 6 and higher will be retained generating far more logs than are usually required. But these devices can be easily configured to log to syslog only what is required. With some simple tuning an administrator can stop logging messages showing severity level 6 and 5 while capturing all required log data.

Rather than execute a command to stop logging specific messages,

(config)# no logging message message-number

the admin can “promote” the VMID to a different severity. This lets the admin set the VMIDs related to successful authentications and configuration changes to severity 3 rather than severity 5 or 6.

(config)# logging message message-number [level level]

Now logs originally set for severity 3, as well as the logs for successful authentications and configuration changes, are being logged within severity level 3. This eliminates a lot of logging overhead without dropping the data an organization is required to collect.

Tags: , ,

0 Comments | Security

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>