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.