Use Cases and SIEM Implementation
Once your SIEM is up and running, you need to define what you want to achieve. Often, organizations will tell me that they have been collecting a large amount of data over a number of months, but they can’t tell me what they are trying to do with all of that data. They’re going about it the wrong way. It’s better to say: Here’s what we want to achieve; what data do we need to achieve it?
The following are a number of recommendations I have for getting the most out of your SIEM (these come directly from one of my recent blog posts):
- Focus on your assets/machines: Identify your most valuable assets – the high business impact (HBI) machines and network segments. Even just identifying them can be quite challenging, but I guarantee the time is well spent. After all, you need to know what you are protecting.
- Model a set of use cases around your HBIs: Learn as much as you can about them: What software is running on them? What processes are running? What ports are open? And from a network point of view, what other machines are they communicating with? Which internal machines have access to talk to them? Do they talk to the outside world? What machines? How many different ones? When? Use your imagination to come up with more use cases. Monitor the machines for a week and start defining some policies/metrics that you can monitor. Keep adopting them over time.
- Based on your use cases, determine what data you need: You will be surprised what you learn. Your IDS logs might suddenly lose a lot of importance, but your authentication logs and network flows might come in pretty handy. Note how I turned things around; instead of having the data dictate your use cases, you have the use cases dictate what data you collect.
- Figure out how to actually implement your use cases: Your SIEM is probably going to be the central point for most of the use-case implementations. However, it won’t be able to solve all of your use cases. You might need some pretty specific tools to model user behavior, machine communications, etc. But also don’t give up too quickly. Your SIEM can do a lot, even initial machine profiling. Try to work with what you have.
Finally, once your use cases have been set up, the next question should be, “Going forward, what do we have to do?” Obviously, you can’t just stay static, you need to regularly modify your use cases. You need to implement a process to see what external indicators to use to begin building out new use cases. This includes security news that comes out, new vulnerabilities, etc. You should also be constantly monitoring the threat landscape, like whether more insider threat cases are being discovered or something along those lines.
The ‘SIEM Trade-Off’ and Potential Pitfalls
When it comes to LogRhythm and other SIEMs, you should be conscious of the fact that there is always a trade-off. SIEMs are effective when it comes to real-time correlation, but they generally lack the capability to search quickly through the data. It’s always a huge trade-off.
This is where a lot of organizations are moving to a dual-pronged approach and adding a log management solution on top of the SIEM. The log management can be anything from an open-source tool to even something like Splunk that allows you to offload the searching and retention of the logs, instead of doing it in the SIEM.
There are a few potential pitfalls to consider:
- Underestimating the effort needed: When just getting into the process of managing a SIEM, it can be easy to underestimate the effort it takes to actually bring the data on board. This data onboarding is usually what takes the bulk of the time. You should identify where the data is generated, then go to your networking team to make sure it’s all reconfigured properly, etc. This aspect is generally underestimated — it’s a huge effort.
- Maintenance: Once the SIEM is operational, maintenance is extremely important. You should be regularly confirming that the data is coming in from all of the sources you expect it to and that all devices are reporting in. Automate as much as possible. Further, it’s critical to ensure the systems stay up to date. It can be easy to think, “Well I have these rules and they’re looking for these kinds of things,” without realizing that the list needs to be updated all the time. If the SIEM doesn’t know about it, it won’t send an alert, so make sure you’re not flying blind simply because you’re not properly updating the SIEM.
Ultimately, when it comes to managing a SIEM, the key is to first understand what, exactly, you are looking to achieve, and then build and implement relevant use cases. Once the SIEM is up and running, be sure to regularly update and maintain it based on new threats that may be on the horizon.
Any views or opinions presented in this document are solely those of the Faculty and do not necessarily represent the views and opinions of IANS. Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our written reports, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by the client in connection with such information, opinions, or advice.