# Alert Filters 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: {% stepper %} {% step %} ### 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. {% endstep %} {% step %} ### 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:"user@example.com"`). 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](https://app.radiantsecurity.ai/settings/mapping/suppression-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. {% endstep %} {% endstepper %} {% hint style="info" %} **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. {% endhint %} ### 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](https://help.radiantsecurity.ai/log-management/log-search-and-query/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:":"` . 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 {% hint style="warning" %} **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. {% endhint %} ### 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](#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](https://app.radiantsecurity.ai/settings/mapping/suppression-rules) to view all alert connectors for which filter rules can be configured. The table displays the following information for each connector:
ColumnDescription
Rule NameThe connector name
Updated ByThe user who last modified the rule
Updated AtThe date of the last modification
ScopeThe suppression scope defined by the rule
Filtered AlertsThe total count of alerts suppressed by the rule
TypeWhether the rule is a Default or Custom (Default-Filtered) rule
StatusToggle 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.**
{% hint style="info" %} **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. {% endhint %} 4. Click **Next** to proceed to the rule definition. 5. Review the **Default Ingestion Query**. This defines which alerts are triaged by default for this connector and *cannot* be modified. 6. 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.
7. Click **Test Rule** to validate your query against historical data in Log Management before applying it. 8. 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:** {% code overflow="wrap" %} ```powerquery src_ip:"10.109.2.133" ``` {% endcode %} * **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:** {% code overflow="wrap" %} ```powerquery severity:"low" ``` {% endcode %} * **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:** {% code overflow="wrap" %} ```powerquery rs_subType:"messagesBlocked" OR rs_subType:"clicksBlocked" ``` {% endcode %} #### 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:** {% code overflow="wrap" %} ```powerquery severity:"informational" OR title:"Suspicious file dropped by Exchange Server process" ``` {% endcode %} * **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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://help.radiantsecurity.ai/manage-radiant/alert-filters.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.