Event correlation is the real return on a SIEM investment. In a properly secured network, at least a dozen types of security devices generate events with potentially critical information on ongoing attacks, holes in the network, or operational concerns. SIEM correlation’s job is to turn all this data into a prioritized to-do list for security staff.
Unfortunately, every network and organization imagines 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 very difficult 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 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.
1. Turn Down the Volume
While there is some consensus on which security behaviors should trigger alerts (e.g. unauthorized access, scanning, malformed packets on the network, etc.), there is a lot of room for variation when it comes to the devices that trigger them. You get the simple events that correlation combines into complex events from somewhere, but the source could be an Intrusion Prevention System (IPS), 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 baseline 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, consider these tips:
- Device rules should be lowered. With 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 farther 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.
2. 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:
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 turning on MySQL signatures if an asset is discovered running MySQL.
If you have a system doing the hard work of identifying these potential risks, then you are rewarded with the huge opportunity of integrating that into the security event picture your SIEM is giving you.
3. 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—and I mean pouring—events into your SIEM, consider replacing the reliance on the simple event with a correlation rule. If you think about it, I can bet that you will find many instances where your real concern lies in any significant changes to the baseline of these firing devices. Keeping 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 whether a network flow (particularly one enriched with machine information or geolocation) might have what you need for detection. For 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 for a logon event from when the infected machine went to it. I’m just sayin’.
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.