SIEM Best Practices:  Very Basic SIEM Implementation Success Criteria

SIEM Best Practices:  Very Basic SIEM Implementation Success Criteria
For purposes of this blog entry I’m defining a very basic successful SIEM implementation as the SIEM product working in a meaningful manner for you and not the other way around.  Here are some basic measurements of a successful SIEM implementation:

Meaningful Data into and out of the system.
Enhanced Analysis Processes
IT Security Workflow Enablement
Enterprise Risk Management Measurements.
Understanding that this SIEM is simply one of your tools!

For purposes of this blog entry I’m defining a very basic successful SIEM implementation as the SIEM product working in a meaningful manner for you and not the other way around.  Here are some basic measurements of a successful SIEM implementation:

1. Data: The SIEM product is technically up and running with the CORRECT set of Event Sources feeding it information. 
This means that you have to understand what you want from the system before you start feeding it.  Garbage in, Garbage out is only the beginning here… If you feed a SIEM garbage it will eat it, store it, process it (correlate, report, alert) and generally make you sorry you gave it that “cupcake” for the next year (or whatever your data retention period is).

2. Analysis:  The SIEM should enhance your overall analytical ability so that you can find new methods of incident identification and automate that identification for the next time it occurs.
This means you have staff ready, wiling and able to use the product in order to conduct analysis, not only of the alerts it generates, but the data in the system waiting for that “expert touch”.  Some SIEM vendors offer great tools to mine this data – but you have to take the time and energy to put them to use.  The benefit is that your SIEM will continually be refined and working to support your needs.  The risk to not doing this work is that your system is out of date about an hour after it is installed.

3. Response: The SIEM should help you to reduce the “Identification Time” for Incidents. 
This means that correlation must be enabled/created/tuned for your environment.  The Vendor’s default correlation settings will certainly not apply in your production environment.  Highlighting and alerting suspicious and malicious traffic is easy, but over/under alerting your team does not reduce the identification time of incidents.  You have to take the time to tame the beast.  Your effort can be rewarded, but it does require effort.

4. Action: The SIEM should integrate with the IT workflow of your organization.
This can apply to Analysis, Incident Response or more generally to IT Operations – in the end the SIEM should stimulate meaningful action for one or more teams. 

5.  Measurements:  The SIEM should provide meaningful metrics and reports.
Top 10 counts do not count in any way, shape or form.  The SIEM should enable your overall IT Risk Management Program.  It can provide input, proof to auditor and in some cases it can help identify new Risks and prioritize other risks, but SIEM is NOT the sole basis of an Enterprise IT Risk Management Program. 

6.  Expectation Management:  The SIEM product is a tool not a solution.
Based on your organizations requirements you have to provide the solution. You enable that solution through properly equipped staff, correct implementation and utilization of the available tools and adherence (and improvement) to processes.