In the Elastic Security app, prebuilt detection rules can be tuned to produce the best possible set of actionable alerts. To reduce the noise level, you can:
Add exceptions to detection rules.
Using exceptions is recommended as this ensure excluded source event values persist even after prebuilt rules are updated.
- Disable detection rules that rarely produce actionable alerts because they match expected local behavior, workflows, or policy exceptions.
- Clone and modify detection rule queries so they are aligned with local policy exceptions. This reduces noise while retaining actionable alerts.
- Clone and modify detection rule risk scores, and use branching logic to map higher risk scores to higher priority workflows.
For details about tuning rules for specific categories, see:
Filter out uncommon application alertsedit
Organizations frequently use uncommon and in-house applications. Occasionally, these can trigger unwanted alerts. To stop a rule matching on an application, add an exception for the required application.
For example, to prevent the Unusual Process Execution - Temp rule from
producing alerts for an in-house application named
- Go to Detect → Rules.
Search for and then click on the Unusual Process Execution - Temp rule.
The Unusual Process Execution - Temp rule details page is displayed.
- Select the Exceptions tab, and then click Add new exception.
Fill in these options:
- Click Add Rule Exception.
Tune rules detecting authorized processesedit
Authorized security testing, system tools, management frameworks, and administrative activity may trigger detection rules. These legitimate activities include:
- Authorized security research.
- System and software management processes running scripts, including scripts that start child processes.
Administrative and management frameworks that create users, schedule tasks,
psexecconnections, and run WMI commands.
Legitimate scripts using the
- Applications that work with file shares, such as backup programs, and use the server message block (SMB) protocol.
To reduce noise for authorized activity, you can do any of these:
Add an exception to the rules that exclude specific servers, such as
the relevant host names, agent names, or other common identifiers.
host.name is <server-name>.
Add an exception to the rules that exclude specific
process.name is <process-name>.
Add an exception to the rules that exclude a common user.
user.name is <security-tester>.
Another useful technique is to assign lower risk scores to rules triggered by authorized activity. This enables detections while keeping the resulting alerts out of high-priority workflows. Use these steps:
- Before adding exceptions, duplicate the prebuilt rule.
Add an exception to the original prebuilt rule that excludes the relevant user
or process name (
user.name is <user-name>or
process.name is "process-name").
Edit the duplicated rule as follows:
Risk score(Edit rule settings → About tab).
Add an exception so the rule only matches the user or process name excluded in original prebuilt rules. (
user.name is not <user-name>or
process.name is not <process-name>).
- Lower the
- Click Add Rule Exception.
Tune Windows child process and PowerShell rulesedit
Normal user activity may sometimes trigger one or more of these rules:
While all rules can be adjusted as needed, use care when adding exceptions to these rules. Exceptions could result in an undetected client-side execution, or a persistence or malware threat going unnoticed.
Examples of when these rules may create noise include:
- Receiving and opening email-attached Microsoft Office files, which include active content such as macros or scripts, from a trusted third-party source.
- Authorized technical support personnel who provide remote workers with scripts to gather troubleshooting information.
In these cases, exceptions can be added to the rules using the relevant
host.name conditions. Additionally,
you can create duplicate rules with lower risk scores.
Tune network rulesedit
The definition of normal network behavior varies widely across different organizations. Different networks conform to different security policies, standards, and regulations. When normal network activity triggers alerts, network rules can be disabled or modified. For example:
To exclude a specific source, add a
source.ipexception with the relevant IP address, and a
destination.portexception with the relevant port number (
source.ip is 18.104.22.168and
destination.port is 445).
To exclude source network traffic for an entire subnet, add a
source.ipexception with the relevant CIDR notation (
source.ip is 192.168.0.0/16).
To exclude a destination IP for a specific destination port, add a
destination.ipexception with the IP address, and a
destination.portexception with the port number (
destination.ip is 22.214.171.124and
destination.port is 445)
To exclude a destination subnet for a specific destination port, add a
destination.ipexception using CIDR notation, and a ‘destination.port’ exception with the port number (
destination.ip is 172.16.0.0/12and
destination.port is 445).
Tune indicator match rulesedit
Take the following steps to tune indicator match rules:
Specify a detailed query as part of the indicator index query. Every result returned from the indicator index query will be used by the detection engine to subsequently query the index patterns defined in your rule definition. Using no query or the wildcard
*.*query will result in your rule executing potentially very large queries.
- Limit your rule’s additional look-back time to as short a duration as possible, and no more than 24 hours.
Elastic Security provides limited support for indicator match rules. See support limitations for more information.
Noise from common network trafficedit
These network rules may need tuning to reduce noise from legitimate network activity:
Personal devices, brought to work or used while working remotely, can query arbitrary DNS servers.
Noise from common cloud-based network trafficedit
In cloud-based organizations, remote workers sometimes access services over the internet. The security policies of home networks probably differ from the security policies of managed corporate networks, and these rules might need tuning to reduce noise from legitimate administrative activities:
If your organization is widely distributed and the workforce travels a
lot, use the
machine learning jobs to detect suspicious authentication activity.