Event correlation is the real return on a SIEM investment.  In a properly secured network, at least a dozen types of security device are generating events that can have critical information on ongoing attacks, holes in the network, or operational concerns.  Turning all this data into a prioritized to-do list for security staff is a job for SIEM correlation.

 

Unfortunately, every network and every organization paint a different security picture.  Each one is a mixed palette of security vendors, device makes and models, and an endless variety of network designs.  Having one-size-fits-all correlation is a very difficult thing for a SIEM to provide to its customers.

 

The good news is that you can use some out-of-box ESM features with the out-of-box ESM rules to get better, actionable intelligence from the your security devices.  If you've got a stable deployment with devices sending events regularly, and you have a  baseline for what correlation rules are firing off your network, then you are ready for this step in maturing your correlation capability.

 

[Update: wow, folks really responded to this topic.  Let me know in comments or PM if you'd like more ways to mature SIEM correlation or ideas for other areas like log management, incident response, etc  - Grant]

 

 

imsis244-038.jpgurhere.jpg

72265071.jpg

 

From right to left: SIEM customer at deployment phase, SIEM customer maturing security business process, and optimized SIEM customer.

 

Turn Down the Volume

 


While there is some consensus on which security behaviors should trigger alerts (unauthorized access, scanning, malformed packets on the network), there is a lot of room for variation when you get to the devices that trigger it.  You have to get the simple events that correlation combines into complex events from somewhere, but the source could be an Intrusion Prevention System (IPS) or network flows, or something else.  If you have these simple, low-level events enabled and set to a high severity, you will get some inflated numbers attached to those machine IP addresses.  The goal here is to have a reasonable baseline for your firing events, so that deviations from that are clear and straightforward for the incident response process.  If you have process steps that involve alarm suppression, or if you are trying to handle this phenomenon with alarms to begin with, these bullet points are for you:

 

  • Device rules should be lowered -- Noisy events like connection buildups/teardowns, you may disable or lower to 2 (CAREFUL: if you go to 1, this can invoke some default behavior, configured somewhere else)
  • Consider disabling all simple events that do not feed correlation rules.  This is obviously an ideal state for some folks, but an optimized customer should be closer to this than far away.
  • Review your enabled correlation rules based on the number of events they generate, and lower their severities as needed.  This is a good habit to develop, because it will help with the technique of adding logic for false positive handling (link to future blog post goes here)

 

 

Add Vulnerability Data to the Mix

 


If you have a vulnerability management solution in your organization, you can use that data to make a big contribution to actionable intelligence from your SIEM.  McAfee ESM supports a ton of vulnerability management solutions, both 3rd party and our own MVM.  If you haven't seen the vulnerability data source configuration yet, it's part of the Asset Manager.

 

assetmgr.png

 

From the help documentation, you can use this data in several ways.

 

  • Raise an event's severity based on the endpoint's known vulnerability to that event.
  • Set the system to automatically learn assets and their attributes (operating system and services detected).
  • Create and manipulate the membership of user-defined asset groups.
  • Access summary and drill-down information of the network assets.
  • Modify Policy Editor configuration, such as turn on MySQL signatures if an asset is discovered running MySQ

 

If you have a system doing the hard work of identifying these potential risks, then you have a huge opportunity integrating that into the security event picture your SIEM is giving you.

 

 

 

Correlate on Deviations and Flows

 

 

With the 9.2 release of the McAfee ESM, some powerful new functionality was added to help with advanced detection using these features.  What they also assist with is controlling your event baseline.  If you have a data source that is pouring, I mean POURING events into your SIEM, consider replacing the reliance on the simple event with a correlation rule.  If you think about it, my bet is you will find many instances where your real concern lies in any significant changes to the baseline of these firing devices.  Kepping your security staff's eyes on the deviation is much less exhausting then watching a massive event flow.

 

Flows are a way to enhance your threat detection models outside of the log data that you already know well.  If you have been in a meeting where someone said "it would be awesome to detect that behavior, but there is no log event that points to that", then consider if a network flow (particularly one enriched with machine information or geolocation) might have what you need for detection.  As an example, if an infected machine starts pivoting out to others on your network, it might be easier to see that with DNS flows FROM the infected machine, instead of searching your entire client network logs to see if they have a logon event that happened when the infected machine went TO it.  I'm just sayin'.

 

 

Conclusion

 

If you are up and walking with your ESM deployment, you aren't ready to run just yet.  Get squared away with intelligent threat and risk correlation first.