Correlation rules that are packaged with ESM come pre-built to meet the needs of a wide range of enterprise customers. All rules are enabled in a default installation; however:
- not all rules are useful in all environments, and;
- many rules can be tuned to provide better insight into your environment.
Below we’ll consider several strategies for tuning your correlation policy.
Examine correlated events to identify rules that require tuning
Start by examining the correlation rules that are triggering most frequently in your environment (for example, look at Event Views/Events by Severity, filtered to show events only from your Correlation Engine). The screenshot below shows an example.
In this query we can see both the high severity events (indicated by color) and the high frequency events (indicated by bar length).
Starting with either the highest severity or highest frequency triggered events, examine a few instances to validate that rule is triggering accurately, and that the rule is giving you valid information. For rules that are not providing useful information, consider the following approaches for tuning.
Disable unwanted rules
There are currently more than 175 pre-built correlation rules in ESM, published by McAfee. Additional rules are published on a regular basis. Some rules, particularly those with very high severity, highlight important patterns and should be closely examined. Others identify more generic behaviors that may not be useful in your environment. Individual correlation rules can easily be disabled in your correlation engine policy, if desired, in order to eliminate unwanted noise.
To disable a correlation rule:
- In any view, select the rule you'd like to disable, and from the popup menu select Show Rule
- Select your Correlation Engine policy to edit. Correlation rules, by default, do not inherit from the Default Policy. If you edit the Default Policy, your changes will most likely not have any effect.
- In the Policy Editor, click on the Action for your selected rule and choose disabled.
- Select Operations/Rollout to roll out your policy change.
Tune variables and parameters
Many rules include embedded parameters, or reference global variables, that provide some control over how the rule functions. As an example, the “Off-hours” rules all include parameters that define working days and working hours, and we tuned these in the section on Basic Correlation Rule Tuning.
As you examine other rules, look for similar opportunities to tune the rule behavior by modifying parameters and variables to match your organization’s needs.
Example: the rule titled “Recon - Horizontal NetBIOS Scan: Port 139 - Events and Flows” is likely to trigger when a vulnerability scanner executes a regular vuln scan. While the rule the rule trigger is accurate, it’s not useful or interesting, and you’d like to eliminate these events from your SIEM.
This rule has a parameter named “ExcludeSrcIP”. By adding the IP address of your vuln scanners to this parameter, you will eliminate the future unnecessary triggers.
Modify rules as needed to tune behavior
In some cases you will find that there is no suitable parameter or variable in your rule to support tuning. In these cases, you may find it necessary to modify the logic of the rule in order to add filtering conditions that eliminate unwanted triggers. This is a multi-step process:
To modify a pre-defined rule:
- Disable the correlation rule that is triggering unwanted events in your correlation policy, as described above.
- Click to select the disabled rule in the Policy Editor, and then select Edit/Copy to duplicate the rule. You will get a 2nd copy of the rule, with a new Signature ID.
- Modify logic on the duplicate as needed in order to eliminate the unwanted events. Also consider modifying the name of the rule help differentiate it from the default rule.
- Ensure the new rule is enabled in your Correlation Engine policy (again, not the Default Policy), and select Operations/Rollout to roll it out to your Correlation Engine.
Example: The rule titled “Suspicious - User Logon from Multiple IP Addresses” is triggering for several shared application accounts that are used by a range of users and systems. You’d like to filter these application accounts out of this rule, to eliminate these unwanted events. This is a very simple rule, and there are no relevant parameters:
In order to accomplish this, we will first create a watchlist that contains the necessary application accounts. Then we’ll duplicate the rule above, and add a clause in the filter block to ignore events where the Source User is on the Application Accounts watchlist.
This will ensure that this rule does not trigger on unwanted application accounts in the future.