Alert Filters

Suppress low-fidelity alerts before they reach the triage pipeline to reduce noise and focus analyst attention on real threats.

Third-party security vendors generate a high volume of alerts, many of which are low fidelity or redundant. Without filtering, this noise degrades alert queue quality and overwhelms security teams. Alert filtering addresses this by suppressing known non-actionable alerts before they reach the triage pipeline—keeping analyst focus on real threats and reducing the storage and compute costs associated with processing low-value data.

Filter rules

Radiant applies filter rules sequentially during alert ingestion. There are two rule types, applied in the following order:

1

Default rules

The base query created and maintained by Radiant that defines which alerts are triaged (e.g., rs_connectorType:ms365_identity_risk AND (NOT source:EndUserReported)). Default rules cannot be modified, disabled, or deleted, but can be refined through a custom rule.

2

Custom rules

Customer-defined rules scoped to a specific default rule, used to narrow down which alerts within the ingestion scope are actually triaged. Each custom rule is built around a Filter Query—an exclusion query applied on top of the parent default rule's ingestion query using an AND NOT operator (e.g., userPrincipalName:"[email protected]"). Together, the two queries define the final triage scope. Custom rules can be created, edited, and deleted by admin users from Settings > Mappings > Alert Filtering Rules.

For example, a default rule for Suricata IDS might ingest all major severity alerts (alert.metadata.signature_severity:Major). A custom rule could then exclude alerts originating from a specific internal IP address (src_ip:"10.109.2.146"), such as a known testing host, ensuring those benign detections never reach the triage pipeline while all other major severity alerts continue to be triaged normally.

Note: Custom rules are not subject to a rule count limit. Rather than creating multiple rules, customers expand suppression coverage by updating the existing query with additional conditions.

Test filter rules

Before saving a new filter rule, use the Test Rule button to see how many alerts would have been suppressed by the rule against historical data in Log Management. This allows analysts to validate and adjust rules before they affect the live triage pipeline.

Filter rule queries use the same Quickwit syntax as Log Management, giving analysts two flexible workflows for building and validating rules:

• Filter-first - Write the query directly in the rule definition, then click Test Rule to be redirected to Log Management with the query pre-populated. From there, adjust the time frame to see how many alerts would have been suppressed.

• Log Management-first - Draft and validate the query in Log Management, then paste it into the rule definition once satisfied.

For guidance on query syntax, see Craft search queries in Log Management.

Query filtered alerts in Log Management

When an alert is suppressed, Radiant tags it with the rs_filterRule field—absent on non-filtered alerts—to identify which rule triggered the suppression. The field follows this format: rs_filterRule:"<rs_connectorType_default>:<version>" .

Analysts can query filtered alerts in Log Management using:

• rs_filterRule:* - returns all suppressed alerts across all rules and versions

• rs_filterRule:paloaltonw9_1_default:* - returns all alerts suppressed by any version of a specific rule

• rs_filterRule:paloaltonw9_1_default:3 - returns alerts suppressed by a specific rule version

Important note: Period escaping in filter rule queries

In filter rule queries, periods ( .) in field names are always interpreted as nested object separators. If a field name contains a literal period, it must be escaped with a backslash ( \) to avoid ambiguity.

For example, host.name:apple.com should be written as host\.name:apple.com in a filter rule query. Note that only the period in the field name requires escaping, not periods in the field value.

Compliance and retention

Filtered alerts are never deleted. All alerts, regardless of their filtering status, are retained in the Parsed Logs index in Log Management for compliance, forensic investigation, and historical analysis. Suppression only excludes alerts from the triage pipeline and does not affect storage or auditability.

If you need to access filtered alerts for forensic or audit purposes, see the Query Filtered Alerts section.

Limitations

Be aware of the following constraints when configuring alert filter rules:

• Filter rules are not applied retroactively to previously ingested alerts

• Filter rules evaluate each alert independently; alert and event joins are not supported in filter rule definitions

• Email alerts are not subject to alert filtering rules

Access and create filter rules

Navigate to Settings > Mappings > Alert Filtering Rules to view all alert connectors for which filter rules can be configured. The table displays the following information for each connector:

Column	Description
Rule Name	The connector name
Updated By	The user who last modified the rule
Updated At	The date of the last modification
Scope	The suppression scope defined by the rule
Filtered Alerts	The total count of alerts suppressed by the rule
Type	Whether the rule is a Default or Custom (Default-Filtered) rule
Status	Toggle to enable or disable the rule

Create an alert filter rule

1. Hover over the connector row you want to configure. A settings icon will appear on the right side of the row.

2. Click the icon to open the rule configuration panel.

3. Click Actions > Add Default Rule Filter.

Note: If a custom rule already exists for this connector, you will see Edit Default Rule Filter instead. Click it to modify the existing rule.

1. Click Next to proceed to the rule definition.

2. Review the Default Ingestion Query. This defines which alerts are triaged by default for this connector and cannot be modified.

3. In the text box below the AND NOT operator, enter your Filter Query using Quickwit syntax to define which alerts within the ingestion scope should be excluded from triage.

1. Click Test Rule to validate your query against historical data in Log Management before applying it.

2. Click Done to save the rule and apply it to the live triage pipeline.

Common use cases

Use the examples below to get started with alert filter rules. Each example includes a real-world scenario, the default ingestion query for context, and a ready-to-use filter query you can copy directly into the rule definition.

Exclude a specific host from IDS alerts (Suricata)

If your environment includes a known testing host that regularly triggers major severity IDS alerts, you can exclude it from triage to prevent it from generating noise in the alert queue.

• Goal: Exclude alerts originating from a specific internal IP address.

• Filter Query:

src_ip:"10.109.2.133"

• What to look for: Replace 10.109.2.133 with the IP address of your testing host.

Exclude low severity UTM alerts (Fortinet FortiGate)

Fortinet UTM alerts can generate significant noise at the low-severity level, particularly for events that don't warrant analyst attention. You can exclude these from triage while retaining all medium and higher severity alerts.

• Goal: Exclude low severity UTM alerts from triage.

• Filter Query:

severity:"low"

• What to look for: If you find that additional subtypes or severity levels are generating noise in your environment, you can expand the filter query with additional conditions. For example: severity:"low" OR severity:"medium".

Exclude blocked events from alerts (Proofpoint TAP)

Proofpoint TAP ingests both permitted and blocked events by default. Blocked events—such as blocked clicks and blocked messages—are already prevented by Proofpoint and typically don't require analyst triage. You can exclude them to keep the alert queue focused on actionable threats.

• Goal: Exclude blocked messages and clicks from triage.

• Filter Query:

rs_subType:"messagesBlocked" OR rs_subType:"clicksBlocked"

Exclude informational and low-value detections (Microsoft Defender for Endpoint)

Microsoft Defender for Endpoint can generate a high volume of informational alerts and specific detection types that are not actionable in most environments. You can exclude these from triage while retaining all higher severity and custom detections.

• Goal: Exclude informational severity alerts and a specific known low-value detection title from triage.

• Filter Query:

severity:"informational" OR title:"Suspicious file dropped by Exchange Server process"

• What to look for: The title field is particularly useful when a specific detection consistently generates false positives in your environment but no other field distinguishes it from actionable alerts. Review your alert history in Log Management to identify other detection titles that may be candidates for exclusion.