TWTQ: Correlation field-based conditions

TWTQ: Correlation field-based conditions

Hello everyone!

We are happy to share that we're starting a new weekly feature on this forum, called "This Week's Top Question". Each week, we will select one or more popular questions which we receive from our customers, and share the answer with you right here on the forum.

So, getting right to it:  

Q: What are field-based conditions in event correlation? How and when do I use them?

A: Field-based conditions are useful when you are building correlation rules. So first, let's understand how a correlation rule is structured. A correlation rule is a pattern used to detect possible security incidents on your network. This pattern is made up of a sequence of log events - including Windows logon events, firewall denied connections, and tables created in databases - also known as 'actions'. EventLog Analyzer collects logs from the various devices on your network, and if a sequence of logs or user actions matches this pattern, you receive an alert instantly. 

You can create custom rules by going to:

Correlation -> Manage rules -> +Create rule

You can modify existing rules by going to:

Correlation -> Manage rules -> Selecting the Update icon next to the required rule

When you are creating or modifying a correlation rule, you can use field-based conditions to make the rule more specific and well-defined. These conditions are applied to specific fields within the actions that make up the ruleā€”for instance, the device name in a Windows logon, or the IP address from a connection denied by a firewall. You can find them by selecting "Advanced" for the required action, and then by clicking on the filter icon next to the required field name.

These are the types of conditions EventLog Analyzer allows you to apply:

  • Filter: Provide conditions for the value of the field. Eg. You can specify that the device name should have a certain value, or IP address should start with a given value.
  • Constant within action: Ensure that this field has the same value for all occurrences of the event. This is useful when you've provided a threshold value for the event. Eg. When you wish to track five consecutive Windows failed logons from the same user, you can set a threshold limit of five for the Windows failed logon action, and apply this condition for the username field.
  • Constant across actions: Compare the value of a field, with fields from other events. Eg. When you wish to track a Windows successful logon followed by a software installation by the same user, you can check that the username field is the same in both events.


These conditions offer a lot of flexibility in building correlation rules. Go ahead and try using them, and let us know if you require any assistance!