The Information Security Forum’s (ISF) The Standard of Good Practice for Information Security (Version 4.1, January 2005) states that the objective for logging is “To ensure individual accountability and to enable incidents, such as access violations, to be investigated and resolved.” This is easy to state, but a major challenge to implement in heterogeneous environments that involve hundreds or thousands of hosts and devices. For example, simply detecting an incident can require the correlation of data from multiple systems and devices (hosts, firewalls, IDS, switches, etc.) that are then compared to a profile of past behavior to identify anomalous behavior.

So, how does one deal with this complicated and less-than-glamorous activity? A clear understanding of the audit logging requirements, which can be derived from the organization’s policies and compliance audit criteria (i.e., the legal requirements and/or auditor’s checklist), is a critical first step. Almost everything flows from these requirements and there are no one-size fits-all solutions. Thus, the remainder of this section is based on dealing with a fictitious set of requirements (worse case scenario) that can be summarized as:

Multiple compliance requirements (e.g., SOX, SEC, and HIPAA) exist and involve different types of audits
Security incidents perpetrated by both internal and external sources are a real possibility 

An extremely heterogeneous environment is used by the organization
Multiple levels of data sensitivity and criticality exist
Some audit log data must be preserved as evidentiary information1
Lengthy retention periods exist for some, but not all, of the log data

To address this hypothetical set of requirements, a moderately complex audit logging implementation would be necessary. As a first pass, the heterogeneous environment predisposes the solution to a cross-platform logging approach such as the de facto standard, Syslog2, to transport log event data. Further, the approach needs flexibility in handling logging information.