“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