Properly Leveraging a SIEM

For some reason, when organizations have a SIEM, the overwhelming tendency is to deluge the SIEM with data.  Any kind of data -- as much as can be gathered from myriad data sources, regardless of its actual value to security operations and incident response (I've previously blogged on the different between data value and data volume).  To be fair, I can completely understand the need to log as much data as possible to a SIEM for auditing and retention purposes -- one never knows what data might be needed for an investigation.  However, it is also often the case that organizations have a hard time distinguishing between data that is to be retained vs. data that is to be reviewed/analyzed/monitored as part of a Security Operations Center's/Incident Response Center's operational workflow.  There is a difference, and it's an important one to understand.

A SIEM can be a valuable tool to use as the foundation of an organization's security operations workflow -- but only if it is configured/set up in such a way as to provide events of value to the analysts and incident handlers.  In other words, if there is more noise than value-add, human nature is to tune out.  There are a number of techniques that one can employ to increase the value-add of one's SIEM by selectively and precisely engineering/tuning the rules, events, and views presented to the analyst.  They mainly involve (surprise, surprise) studying, analyzing, and understanding the data on the network, and then purposely selecting those rules, events, and views that will return the most bang for the buck when presented to the analyst and/or incident handler.

I believe this to be an important point that is, unfortunately, often overlooked by organizations.