Occasionally we get feedback from customers that boils down to questions about truncated audit log output. It is important that security analysts and compliance officers understand some basic technology aspects of audit log processing because it helps them to grasp how audit integrity is preserved within the limits of audit log reporting.

Audit truncation: Just the facts

Some event logs from Exchange and SharePoint contain very large chunks of data. Which is fine, except for a simple and incontrovertible fact: there is a limit to the amount of data that can be written to common audit log outputs such as the Windows Event and Security log and Syslog.

• Windows Event and Security log limit events from about 27,000 to 32,000 bytes.
• Some implementations of Syslog limit the size to 65,000 bytes, while other Syslog variants have different limits.

An example of an excessive event in SharePoint would be when someone changes the layout of a list or document library, or adds a rule to sort the list: event 23 will include tons of information about all the schema changes which quickly adds up to tens of thousands of bytes. Another example: Exchange includes a field on some events called “Additional information” that can contain thousands of bytes only marginally-important from a security perspective.

There is no byte limit to file outputs.

What you need to know about audit integrity and LOGbinder’s audit log truncation

LOGbinder puts audit integrity ahead of other considerations in the course of its work. This does not mean that we don’t truncate logs when the required output demands it. For customers whose SIEM requires an output that imposes a limit to the size of recorded event, a decision must be made on how to deliver the event. (It would be unacceptable to just skip it and fail to deliver the audit event.)

In the case of an excessive byte-sized event, LOGbinder makes the decision to truncate what we view to be extraneous: information that can be retrieved via other means (such as the schema change we mentioned earlier) or that is less important to SIEM security analysts than the particulars about the event such as the “who did it, what did they do, and where did it happen”. Those field data elements are never too big.

When we truncate the event, we take extra care to deliver all that is possible. Our very cool technology truncates events only to the size insisted on by the SIEM-specific Syslog implementation for example, starting with the full amount and reducing until it is accepted.

Of course, no such truncation takes place if the LOGbinder output is directed to a plain text file.

It should be stated that, by a wide margin, most use-cases never encounter this issue. Security officers and SysAdmins have good reasons to narrow their monitoring focus to the most relevant audit events. They exclude the noise events which are typically those that would require truncation.

Audit integrity has always been a LOGbinder core value. Our architects and developers have gone to great length to ensure security analysts have what they need from audit logs, both for real-time security event information and forensic investigations– despite hard-coded technological limitations in common event logging formats. The ability to simultaneously direct output to a file that has no byte limitation is an expression of our core value.

LOGbinder for SharePoint even has a feature to configure “lookup levels” to allow organizations to configure their own suitable balance between system performance and the collected audit log detail. We will take a closer look at this feature in a subsequent post.