Security, et al

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?