Log Management

Samoa’s Time Zone Change Shows The Downside To Using Local Time For Time Stamps in Logs

Naked Security has a good post about Samoa’s move across the international date line.  Using a single time base can be very valuable in recreating the history of an event or incident.  Even if the clocks of all systems are synched using NTP, stitching together logs from systems in different time zones can be tedious, and such a thing generally happens as the result of something bad, where time is of the essence.  The Naked Security post points out that there is even more peril than previously thought in using local time, when the local time changes due to some legal mandate.

Sadly, Samoa is going to completely miss my birthday this year.

Be the first to comment - What do you think?  Posted by admin - December 30, 2011 at 12:45 am

Categories: Log Management, Logging   Tags:

Logging and Syslog Best Practices

In this post, I will cover a basic set of best practices for managing logs. Depending on your specific objectives, regulatory requirements, and business constraints, there are likely to be a number of additional best practices.

  • Forward syslog messages from clients to a secure syslog server.
  • Enable NTP clock synchronization on all clients and on the syslog server. It is very important for all systems
    reporting logs to be using the same time server, so that logs are all synchronized. Without doing this, it can be difficult or impossible to accurately determine the sequence of events across systems or applications.
  • Group “like sources” into the same log file. (i.e. mail server, MTA, spamassassin and A/V scanner all report to one
    file)
  • Use an automated tool to establish a baseline of your logs and escalate exceptions as appropriate.
  • Review your records retention policy, if applicable, and determine if anything kept in logs falls under that policy. If so, establish retention periods based on the records policy.  Legal requirements for keeping logs vary by jurisdiction and application.
  • The “sweet spot” for log retention appears to be one year.  Shorter than 1 year, and it is likely that key data would be unavailable in the wake of a long running attack, and longer than one year is most likely wasting disk space.
  • Include logs and log archives in a standard backup process for disaster recovery.
  • Change read/write permissions on logs files so they are not accessible to unprivileged user accounts.

Have more suggestions for logging best practices? Post them in a comment below.

16 comments - What do you think?  Posted by admin - October 4, 2010 at 9:16 pm

Categories: Compliance, Log Management, Logging, Policy   Tags:

Windows Syslog

Windows does not natively support either sending logs out as syslog messages.  There are a number of applications that will translate Windows Event Logs to syslog.  A partial list is:

Why Send Event Logs To A Syslog Server?

There are a few good reasons to export Windows Event Logs as syslog messages.  Syslog is a basic format and allows logs from many sources to be normalized, stored in a central repository and analyzed by a common system.  Many log analysis engines support the direct pulling of Event Logs, but the mechanism to do so is generally pretty clumsy, requiring a batch process that periodically connects to a share and transfers a copy of the entire log file.  Such a process is inefficient if the log files are large, and does not provide the benefit of having the logs moved to a log sever/analyzer real time.  Logs sent to a separate log server are not at risk of being lost in the event of software or hardware failure or logical attack on the Windows server in question.

Downside

The primary down side to exporting Event Logs to syslog is that Event Logs are structured sets of data and the structure is not cleanly retained as the events are converted into a string of plain text.  Generally, though, it is possible to parse out the data with some rudimentary analysis of the converted log messages.

1 comment - What do you think?  Posted by admin - March 22, 2010 at 5:44 pm

Categories: Log Management, Windows   Tags: , , , ,

Log Analysis and Log Correlation Basics

Log data can provide benefits beyond the obvious notification of system events and security happenings.  Aggregated logs from a system or from multiple systems can provide a more complete picture of problems when those logs are correlated together.  To any experienced administrator, this is obvious.  Consider the following environment:

Read more…

14 comments - What do you think?  Posted by admin - March 15, 2010 at 3:54 pm

Categories: Log Management, Logging   Tags: ,

Defining Log Management and Log Monitoring Objectives

System logs are good for more purposes that many people realize.  In this post, I’ll describe the four broad categories of log usage.

Forensic Record Keeping

Many organizations choose to archive log data for a period of time for future reference.  Generally, the usefulness of keeping archived logs comes from the situation where a system problem is discovered some time in the future, and archived logs can help to piece together the cause of what happened, and can often be used as evidence in court should such a thing become necessary.

Proactive Identification of System Health Problems

Alerting tools can be used to monitor logs streamed from devices and notify operators of a problem, such as a failing disk, low memory, crashing processes, etc.  A big advantage of this is that many serious problems can be remediated before they impact the availability or performance of the system, by removing stale files to add drive space, contacting a vendor for a preemptively hardware replacement and so on.

Proactive Activity Monitoring of Users and Administrators

This is one area of log management that many organizations unintentionally overlook, because the perceived risk is not very high, the administrators are unaware of the options, and more commonly, the view that monitoring the activity of administrators is futile because such monitoring could be bypassed by a skilled administrator.  In separate post, I describe a process to monitor the activities of administrators.

Intrusion Detection

This is arguably the most common use of system logs – looking for evidence of system compromise.  Like system health monitoring, there are many tools on the market that can take in log streams and notify operators or security personnel when an event is detected.

A Note on Protecting Logs

In all cases, it is important to send logs to another system for storage, either real time or by some frequent batch process.  Protecting logs from a failing hard drive, crafty hacker or disgruntled administrator can be achieved by using a hardened syslog server.

1 comment - What do you think?  Posted by admin - February 12, 2010 at 7:19 pm

Categories: Log Management   Tags:

Segregating Logs From Different Log Files On A Centralized Log Server Using Syslog-NG

In this post, I will demonstrate a way to capture logs from a series of log files, and relay those logs to a central log server, where the logs will be separated into log files, as they existed on the original host.

Reading from files

Syslog-ng has the ability to pull log data from files, then treat those logs as any other source, like this:

source  s_file_abclog { file(“/var/log/abc.log” follow_freq(1));};

In this way, you can handle log data from applications that do not have native support for syslog.

Then, you can send that data to a central log server, like this:

source  s_file_abclog { file(“/var/log/abc.log” follow_freq(1));};

destination d_remote{udp(“192.168.0.3” port(514)); };
log { source(s_file_abclog); destination(d_remote);}; Read more…

5 comments - What do you think?  Posted by admin - August 23, 2009 at 4:22 pm

Categories: Log Management, Logging   Tags:

Establishing a Hardened Syslog Log Server

Maintaining a reliable and secure repository of logs is important for many reasons: establishing a foresnic trail of evidence in the case of fraud or attack, and enabling event correlation across many devices, among others.  Particularly in regulated industries, management should enact controls that prevent security, application and system logs from being tampered with.

Many organizations choose to consolidate their logs on to a centralized syslog server.  Many devices and just about all UNIX-like operating systems (Linux, free/net/open BSD, Solaris, AIX) support syslog natively.  Windows-based systems require a tool to convert event logs to syslog.

Syslog is a simple protocol and is easy to wrap some very effective security around.  The goal is remove as many opportunities for the central syslog server to be compromised as practical.  There are 3 aspects to hardening a syslog server that we’ll cover:

  1. The operating system
  2. The network
  3. The application
  4. The users and administrators Read more…

4 comments - What do you think?  Posted by admin - April 29, 2009 at 6:58 pm

Categories: Log Management, Logging, Security   Tags: ,

Logging Windows Events To Syslog Using Snare

There are now a bunch of commercial and open source agents that can run on a Windows system to take in Windows Event Logs and send them off to a syslog server.  We’ll be looking at the Snare agent in this post.

As of this writing, Snare is compatible with Windows NT, 2000, XP, 2003 and Vista.  There is also an agent available for 64 bit Windows versions.

For my test, I am installing on a Windows XP system.  Installation is quite straight forward.  There are MSI and scripted installers available on the Snare web site for large scale deployments.

The recommended installation has Snare taking control over the Event Log configuration, to synchronize the configurable logging “Objectives” in Snare with the Event Log settings.  Read more…

14 comments - What do you think?  Posted by admin - April 22, 2009 at 7:28 pm

Categories: Log Management, Logging, Security, Windows   Tags: , ,

What To Look For In A Compliance Report From Logs

Reports from system logs for compliance generally have the same basic requirements regardless of the standard being measured – whether PCI, SOX or FFIEC.  There are some foundational requirements for compliance reporting of logs to be considered effective:

  • The data/time are synchronized throughout the environment.  This is vital to be able to correlate events between systems and to real-world events, such as security cameras, badge systems, etc.
  • System, security and audit logs are sent to and stored on a system where users/administrators of monitored systems do not have access.   Logs will not be an effective identifier of fraud, theft or other nefarious acts if the perpetrator of those acts has the ability to remove log evidence of his activities.   Subscribing to a Log Management Service is a good way to address this concern.
  • Individuals who access controlled systems should not have access to update or modify the scripts and/or software the produces the security reports.

The key elements for compliance log reports are: Read more…

Be the first to comment - What do you think?  Posted by admin - April 21, 2009 at 5:10 pm

Categories: Compliance, Log Management   Tags: , ,

Why Using A Log Management Service Might Be Right For You

There are a growing number of Managed Security Service Providers (MSSP’s), such as IBM and Symantec, and Verisign, and other companies, such as Savvis, offering an outsourced service to collect and retain system logs, generally called a log management service (LMS).  The initial instinct for many would be to reject such a crazy thought as outsourcing log management, but there are some big advantages, and some things to consider. Read more…

2 comments - What do you think?  Posted by admin - April 19, 2009 at 12:09 am

Categories: Compliance, Log Management, Security   Tags: ,

Recent Posts in the Syslog Forum

RSS Error: A feed could not be found at http://www.syslog.org/forum/.xml/?type=rss. A feed with an invalid mime type may fall victim to this error, or SimplePie was unable to auto-discover it.. Use force_feed() if you are certain this URL is a real feed.

Next Page »