In the SIEM app, prebuilt detection rules can be tuned to produce the best possible set of actionable signals. To reduce the noise level, you can:
- Disable detection rules that rarely produce actionable signals 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 signals.
- Clone and modify detection rule risk scores, and use branching logic to map higher risk scores to higher priority workflows.
For details about tuning prebuilt rules for specific categories, see:
If you are using version 7.6.0 of the Elastic Stack, see Reduce noise for network rules. From version 7.6.1, the network rules have already been optimized.
Filter out uncommon application signalsedit
Organizations frequently use uncommon and in-house applications. Occasionally, these can trigger unwanted signals. To stop a rule matching on an application, you need to modify the rule’s logic so it ignores the application’s name.
For example, to prevent the Unusual Process Execution - Temp rule from
producing signals for an in-house application named
- Go to SIEM → Detections → Manage signal detection rules.
Search for the
Unusual Process Execution - Temprule, and then:
- Click the actions icon on the rule’s row (three dots).
Select Duplicate rule
A duplicate rule is created, named
Unusual Process Execution - Temp [Duplicate].
Search for the new rule, and then:
- Click the actions icon on the rule’s row (three dots).
Select Edit rule settings
At the top of the All rules table, click
Custom rulesto display only your rules.
The Edit rule settings page is displayed.
Do one of these:
In the Custom query field, add this condition:
and not process.name: "myautomatedbuild"
Click Add filter, and then define a
process.name is not myautomatedbuildcondition.
- Save the new rule and disable the original rule. If you want, you can delete the original rule.
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 signal noise for authorized activity, you can do any of these:
Add a statement or filter to the rules that exclude specific servers, such as
the relevant host names, agent names, or other common identifiers.
and not host.name : "server-name".
Add a statement or filter to the rules that exclude specific processes. For example,
and not process.name : "process-name".
Add a statement or filter to the rules that exclude a common user.
and not user.name : "security-tester".
Another useful technique is to assign lower risk scores to rules triggered by authorized activity. This enables detection while keeping the resulting signals out of high-priority workflows. Use these steps:
- Duplicate the same rule twice.
In the first duplication of the rule, exclude the relevant user or process
and not user.name : "user-name"or
and not process.name : "process-name").
In the second duplication of the rule:
Risk score(Edit rule settings → About tab).
Change the rule’s query or filter so it only matches the user or process
names excluded in the first duplication
and user.name : "user-name"or
and process.name : "process-name").
- Lower the
- Disable the original rule.
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 signals, network rules can be disabled or modified. For example:
To exclude a specific source, add a
not source.ipstatement with the relevant IP address, and a
destination.portstatement with the relevant port number (
not source.ip : 188.8.131.52 and destination.port : 445).
To exclude source network traffic for an entire subnet, add a
not source.ipstatement with the relevant CIDR notation (
not source.ip : 192.168.0.0/16).
To exclude a destination IP for a specific destination port, add a
not destination.ipstatement with the IP address, and a
destination.portstatement with the port number (
not destination.ip : 184.108.40.206 and destination.port : 445)
To exclude a destination subnet for a specific destination port, add a
not destination.ipstatement using CIDR notation, and a ‘destination.port’ statement with the port number (
not destination.ip : 172.16.0.0/12 and destination.port : 445).
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.
FTP is sometimes used with external sources.
Marketing and business workflows often use SMTP email traffic. Additionally, personal devices, brought to work or used while working remotely, may use consumer email services.
Although uncommon, accessing databases over the internet may be part of development workflows.
Frequently used port while developing and testing web services.
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.
Reduce noise for network rulesedit
This is only required if you are using version 7.6.0 of the Elastic Stack.
To reduce noise for network rules, duplicate the network rules and either:
Remove all rule index patterns, except for the
network.direction: outboundstatement from the query. The rule then relies on CIDR notation to match traffic direction. The CIDR matches (
destination.ip) can be changed to match your network’s configuration.
The following rules can be modified:
- DNS Activity to the Internet
- FTP (File Transfer Protocol) Activity to the Internet
- IPSEC NAT Traversal Port Activity
- IRC (Internet Relay Chat) Protocol Activity to the Internet
- PPTP (Point to Point Tunneling Protocol) Activity
- Proxy Port Activity to the Internet
- RDP (Remote Desktop Protocol) from the Internet
- RDP (Remote Desktop Protocol) to the Internet
- RPC (Remote Procedure Call) from the Internet
- RPC (Remote Procedure Call) to the Internet
- SMB (Windows File Sharing) Activity to the Internet
- SMTP on Port 26/TCP
- SMTP to the Internet
- SQL Traffic to the Internet
- SSH (Secure Shell) from the Internet
- SSH (Secure Shell) to the Internet
- TCP Port 8000 Activity to the Internet
- Telnet Port Activity
- Tor Activity to the Internet
- VNC (Virtual Network Computing) from the Internet
- VNC (Virtual Network Computing) to the Internet