SIEM Best Practices: Basic Correlation and Default Content

As awesome as correlation can be (and it can be phenomenal) correlation can’t overcome lack of context. Correlation Rules work best and more efficiently if you can provide them with some basic boundary conditions. The more focus and context you provide the more specific the results will be and the more automated your responses can be (in a word – efficiency).

Typically SIEM Vendor Use Case: Company “X’ wants to correlate on a near real time basis several stimuli and responses, say Network Traffic, IDS Signature(s) and Server/Application Response(s) and have it alert key personnel only when it matters most. With the right event sources, environmental context and log levels you can do that with a good SIEM based on Time, IP’s, Ports, Services, Vulnerabilities and/or other attributes of the related log entries.

What happens in the real world? As many of you know if you leave the default content enabled with your raw data flow - All hell breaks loose. You will see 10’s or 100’s of thousands of correlated activities on a daily basis. This is just a function of lab versus real life.

First, many organizations still don’t have what I would consider a robust IDS signature management program and the alerting from their current systems is ….. um….. well….. interesting. The really good IDS shops have lots of custom signatures that are categorized by the Vendors and won’t necessarily be included in default correlation rules.

Network traffic logging is inconsistent at best and finding out what systems/applications they have (not to mention how and what they log) is neither possible nor realistic without a fundamental change in the organization. Neither of the above is the fault of the SIEM Vendor or Product – it is simply the world we live in.

Yes this is all changing (very slowly) and certain compliance activities (PCI for example) can be used to help us to slowly drive those changes (if we are lucky enough to present a enterprise-wide security enhancement scenario to the exec team before a vendor pitches a product to simply “check the box”).

So then what value does SIEM correlation add? For now, I’ll just say that your mileage may vary, but you can control it! Several factors can add significant value to the data, location information, system information, business use information, vulnerability information, etc… To the Security Analyst the value of the information increases as more about the context of the data set, the targeted system and the overall environment in known. The less context the more work the analyst has to do to understand the alerts that are generated.

You can do the hard work or contextualizing (is that a word???) your environment as best you can for your SIEM ahead of time and say on top of it as the environment changes, or you can do the work with each event you have to analyze. The choice is yours depending on how you configure your SIEM. In the end the team that is prepared with the right ingredients at the beginning will enjoy SIEM life much more.

Other more technical rationale: SIEM Content (Correlation, Statistical Analysis, Reports) are after all memory, processor and/or query operations and consume resources in order to function and provide you with the end result. As minimal as those resources may be for each piece of content – in aggregate or across an enterprise your data will eventually overwhelm those resources if not managed properly. You can hurt yourself with bad content. Yes the good products are scalable, however the complexity with scalability is the topic of a future blog post.

SIEM Configuration Default Content Recommendations:
1. Know your environment. The better you understand your environment the better you can tune the tools you have to help you tame it. I use the concept of system and or network profiles to help capture that data into a knowledge base.

2. Disable default system content: Yes a lot of time and energy went into developing this content and in many cases it is highly useful. My recommendation is to use is as a template and/or a learning tool. Enable the content that you need and understand. If it doesn’t align to a documented workflow or feed a report – what exactly is it doing???

3. Document your known requirements and plan. There is nothing that says you can’t build content to solve tactical and strategic needs of your organization. I suggest a roadmap discussion and plan out your requirements accordingly. Some of these SIEM solutions provide 3 or more ways to accomplish essentially the same thing you can get lost easily.

4. If you don’t know – ask. There is an ever increasing number of SIEM users out there that have similar issues (perhaps with different technologies) but their approaches can be leveraged through Forums/Blogs/Linkedin/etc. Decurity will be providing more help in this area soon. So stay tuned.