Easy entry to SIEM Correlation Rules with Policy Validation

December 6, 2011  |  Conrad Constantine

We’d love to do log correlation, but we just don’t know where to start!”

If I had a dollar for every time I’ve heard this expressed, I’d ... have enough to buy everyone in the company a round of drinks..

Start with what you know

For most organizations, the amount of third-party technology they have deployed, far outweighs what was developed bespoke. Approaching log correlation by trying to level of mountain of technical information coming from these systems down to something meaningful is an incredibly daunting task, and all too often, is the approach people take to diving into correlation.

Like so many problems in technology however, working from the desired result backwards, is almost always the correct approach. In the case of SIEM and log correlation, the end result is actionable information. You can only act on what you understand how to act upon, so start with what you know: your business. At the top level of your Security Program, should be your Security Policy, a broad set of guidelines for advising the construction of Process and Procedure for operating securely within the requirements of your business model.

Now, assuming your policy was written for your org, and not just copied verbatim from “best practices”, you likely aren’t seeing a great number of violations of those policies on a daily basis, right? Well, with log correlation, we can put that to the test, in an exercise that gives us a good approach to getting into building correlation rules, with some simple steps:

  • Choose an item in your Security Policy
  • Decide on an action that would violate that policy
  • Determine what devices would have visibility or record of those actions.
  • Locate those log entries, determine what the pattern of logs would be when the violation occurs
  • Build your first custom rule
Once you start giving the policy-driven approach a try, the results are often enlightening and encouraging, and not necessarily in the way you’d think. I’ve seen a lot of people use the policy approach and see that their security policy is being violated thousands of times a day, and not necessarily in a manner that is actually a security issue: sometimes “Industry Best Practices” just don’t match up to how the organization actually operates the business legitimately. This is part of Risk Management though, and it doesn’t necessarily reflect that your practices are bad, just that your Security Policy doesn’t match up to the risk appetite of the organization itself.
But just as often, you’ll be starting on a great source of directly actionable information; a series of alerts of things you *know* should not be happening within your Enterprise, that you most likely already have fairly well-established rectification procedures from.
So give the ‘start with what you know’ approach a try, in security, it’s better to start out by doing a few things perfectly, than do a hundred things poorly. Starting out with what you should know best: your own business, and then slowly working out towards what you don’t, is the panic-free approach to moving the mountain.

Share this with others


Featured resources



2024 Futures Report

Get price Free trial