Say What? Deleting old logs isn’t the responsibility of the SIEM?!??

Wow I just got off the phone with a prospective customer
helping them to determine if out LOGbinder SP product would integrate with
their SIEM solution (it did and does with all SIEM solutions).

During the call they told me something I found very
surprising.After verifying that
LOGbinder SP can purge old SharePoint audit events they said that every SIEM
provider they speak to tells them that it’s not the job of the SIEM solution to
delete old logs – it their job as part of operations.

The customer’s beef with that response is that it causes
them extra work to delete voluminous logs

Well I agree that SIEM solutions should be able to delete
old logs but for a very different and much more important reason.Here’s the theorem:

1.Security logs should not be left on the system
where generated.This is infosecurity
best practice 101.You need to get logs
off the systems where they are generated and into a separate, secure
archive.Why? Log integrity: 1) If a bad
guy breaks in to your system the first thing he’ll do is delete your logs to
cover up his tracks.2) Logs are the
only control over administrators but if your official copy of logs are left on
the system they administer they can tamper with the logs that are supposed to
provide accountability over them.

Ergo: Logs need to be collected.

2.Logs eventually need to be cleaned up on the
system where they are generated.Some
logs automatically wrap – like the Windows event log for instance – but some
applications logs grow and grow – like the IIS for instance.These logs can soon consume gigabytes of
space

3.Logs should not be deleted before they have been
collected or else you lose valuable audit events and the integrity of your
audit trail.

Ergo: If logs need to be collected, need to be deleted from
local systems but should not be deleted before being collected then who is the
in the best position to do that?The
SIEM solution, right?