From: McAfee
This was started by some good conversations around how a company does all the things a SIEM does. Thanks to those who participated.
I like to think of all the use cases that a SIEM performs as standing in four groups:
- Log Management – get the events generated on your network flowing through SIEM and keep that pipeline operating smoothly
- Threat and Risk Correlation – add intelligence to the event flow by attaching context or combining simple events into more complex ones
- Incident Response – now that you know something is happening, you have to do something about it
- Compliance – providing the necessary detail on security attributes to measure and report it to regulatory bodies
As a product manager, I have used that to organize my thoughts on features, workflow, pretty much everything. What is new for me, is the idea that these are related to the maturity of the SIEM process.
A SIEM maturity scale: a company starts at the left and works to the right as learning and experience grows
While there is nothing mind-blowing about the concept, it got me started thinking about what happens when your company doesn’t follow this sequence as it matures its SIEM process. It’s similar to what happens in child development: the normal course is crawl, walk, run, jump. If a kid skips crawling and goes to walking, some researchers say it has an impact on future development.
Plays NOT to run
Here are a couple of examples of these steps taken out of order and their potential impact.
Skip Correlation and Go Directly to Incident Response. There are a couple of reasons (maybe many more) that a company gets blocked on the threat and risk correlation use case. The first reason is that once all the events from the network start flowing into the SIEM, the responders have to go into triage mode from all the stuff the SIEM is sending them. Another reason is that the team is spending so much focused time on log management, there isn’t any spare bandwidth for writing and tuning correlation rules. Either way, you can end up with an inefficient incident response process.
The Left-Whisky-Six. While Correlation blocks, Incident Response makes an end run.
How do you know you ran this play? You might answer “yes” to one of these statements:
- “my company only uses the correlation rules that shipped with the product”
- “we don’t use correlation rules to manage events, only alarms”
- “we had to disable those devices because they were sending too many events”
Besides “catching the bad guy” (one I don’t agree with, BTW), threat and risk correlation serves the purpose of helping you shape events to only tell you what you really care about. It’s more than just a filter, it’s a way to focus information, add context, and increase the ROI of your security data
Go Straight from Log Management to Compliance. It surprising to think that this happens, but not so much when you think about why. Many types of compliance from SOx to GLBA to HIPAA (those are just US examples) require some form of security information and event management. Folks are not helped by the murkiness of the requirements, look to the SIEM to help check a box, and there you have it. However, log management only assures that the data is there; it doesn’t actively manage risk, which is something that compliance is legally forcing you to do.
The Hotel Mike. Compliance waits (patiently) at the end of the field for Log Management to connect.
How do you know you ran this play? You might answer “yes” to one of these statements:
- “there are hardly any events showing up in our compliance reports”
- “events? I just know about reports”
- “we can’t keep up with all these findings from internal audit”
Compliance is a process that depends on other processes, like Log Management, Threat and Risk Correlation, and Incident Response. I like to think of Compliance as a way to measure these other processes and report on them. Most people are focused on regulatory compliance, but the Compliance use case is focused on measurement of the processes (in control or out of control). You need all the other use cases to be in control before compliance is under control.
My Pick for Play to Run
I think the best thing to do for a company building a SIEM process is to follow the four use cases in the expected order: Log Management, Threat and Risk Correlation, Incident Response, Compliance. I do NOT think it should be done in a waterfall fashion: get ALL the logs in the SIEM, then do ALL your correlation rules, etc. You should start with a few critical data sources and take them ALL the way through the process. This gets you the true benefit of the SIEM without getting stuck at an earlier stage.
The Golf Bravo: if it seems backwards, look at it the other way.
Focus on the Flow, not the End State. To run this play, you have to change the way you look at the game. We don’t live in a flowchart world, processes don’t have neat boxes around them and all the input doesn’t magically show up at the step where it needs to be. To me, all the logs in the SIEM, or all the correlation rules that are enabled, are just state. The point of getting them into that state is really just to get them somewhere else now. When you are adding data sources, think about what correlation rules this could generate; when you create a correlation rule, think about how efficient you can make the incident response on this. All of the SIEM use cases fit into a process flow, whose purpose is to tell your company what you want to know about the security data you are generating. If you focus on the flow, not these end states, you aren’t walking or crawling, you’re runnning.
Grant Babb SIEM Product Manager
Leave a Reply