--- title: Matching Policies to Filter Events slug: matching-policies-to-filter-events image: https://archbee-image-uploads.s3.amazonaws.com/wtmLmyh6YG71yn5qVtkMM/q7bYcFkA1fKzbJKSrfDBw_flare-logomark-full-color-1.png docTags: createdAt: 2026-08-16T11:17:19.303Z --- Identifier Matching Policies control which events appear in an Identifier's feed and which are filtered out. There are four policy types for filtering events: - **Included Keyword:** Shows only events that contain at least one of the specified keywords. - **Excluded Keyword:** Removes events that contain at least one of the specified keywords. - **Lucene Query:** Shows only events that match a Lucene search query. - **Lookalike Domain Strategies:** Shows only lookalike domains detected with the selected permutation strategies. *(Coming soon)* Combine policies on an Identifier to keep its feed focused on the events relevant to you. :::hint{type="info"} Up to 10 Matching Policies can be assigned to an Identifier. ::: ::::Tabs :::Tab{title="Included Keyword"} An Included Keyword policy ensures that only events containing at least one of the specified keywords appear in the identifier's feed. **How it works:** When you use an Included Keyword policy with keywords like `product-x` and `product-y`, the Identifier's feed will only return events that mention at least one of those terms. Everything else is filtered out. In Lucene query terms, this is equivalent to: `AND (product-x OR product-y)` **Configuration: **Add one or more keywords when creating the policy. Each policy supports multiple comma-separated keywords, up to a maximum of 50. **When to use:** - You monitor a broad domain identifier but only care about events that mention a specific product name, geography, or business unit - Your identifier for a company name matches many unrelated mentions; adding included keywords like a product name or executive name narrows the results to what is relevant **Important:** An Included Keyword policy is restrictive by design. If none of the specified keywords appear in an event, that event will not show in the feed. Be deliberate about which keywords you include to avoid filtering out legitimate results. ::: :::Tab{title="Excluded Keyword"} An Excluded Keyword policy removes events from the identifier's feed when they contain at least one of the specified keywords. **How it works:** When you use an Excluded Keyword policy with keywords like `keyword1` and `keyword2`, any event mentioning either of those terms will be excluded from the identifier's feed. In Lucene query terms, this is equivalent to: `AND NOT (keyword1 OR keyword2)` **Configuration details: **Add one or more keywords when creating the policy. Each policy supports multiple comma-separated keywords, up to a maximum of 50. **Use case examples:** - Your domain identifier surfaces events from internal test environments or staging domains that are not actual threats - Known false positives keep appearing in the feed for a specific identifier, such as events referencing an internal company name that matches a common word **Relationship to legacy Ignore Terms:** If you previously used identifier-level ignore terms, they have been automatically migrated to Excluded Keyword policies. The behavior is identical. ::: :::Tab{title="Lucene Query"} Only events that match a configured search query will appear in the Identifier's feed. This policy type uses Flare's Lucene query syntax, allowing to target any searchable field within Flare's data models. A Lucene Query policy applies a full search query as a filter. Only events matching the query will appear in the Identifier's feed. **How it works:** Write a Lucene-syntax search query, and the identifier feed is filtered to show only events matching that query. This gives you the full power of query-based filtering for complex or highly specific scenarios, with faster results than a Query Identifier. - The Search Query Assistant is available to help write the query - Query complexity limits align with existing Query Identifier limits **When to use:** - You need to combine multiple conditions that cannot be expressed with simple keyword inclusion or exclusion - You want to filter by specific metadata fields, such as source type or severity attributes, in addition to content keywords - Your filtering requirements involve complex boolean logic (e.g., events that mention "acme" AND are from a specific source, but NOT from a specific actor) **Example 1: **A domain Identifier for example.com should only show leaked credential events that include a URL. The Lucene Query Policy would be: `_exists_:urls` **Example 2:** You want to exclude all events before a specific date. The policy query would be: `metadata.estimated_created_at:[2026-01-01 TO *]` If you are already familiar with Flare's search syntax, writing Lucene Query Policies will feel natural. The same operators, field names, and syntax rules apply. For additional guidance regarding building Matching Policies with queries, see: [Build Lucene Query Policies](docId\:Zg1zxObuLcIJhudRJ_Hkg). ::: :::Tab{title="Lookalike Domains Strategies"} A Lookalike Domain Strategies policy controls which lookalike domains appear in a domain Identifier's feed, based on the permutation strategy used to detect them. **How it works:** Each Lookalike domain is detected through a permutation strategy, such as a removed character or a homoglyph substitution. When this policy is assigned to a domain Identifier, only lookalike domains detected with at least one of the selected strategies appear in the feed. All strategies are selected by default. **Configuration:** Select one or more of the available strategies, or select all strategies to include all detected lookalike domains. For more information on each strategy, see [Permutation strategies](docId:1pejLZ19MtYhA6XuRIMPS). ::Image[]{src="https://api.archbee.com/api/optimize/wtmLmyh6YG71yn5qVtkMM/QiTijX00fkkMExXkUMPes_image.png" size="80" isUploading="false" width="1060" height="1020" darkWidth="1060" darkHeight="1020" position="flex-start" showCaption="false"} **When to use:** - Your domain Identifier surfaces a high volume of lookalike domains from strategies that are not relevant to your organization, such as plural or subdomain permutations. - You want to focus review on specific techniques, such as homoglyph substitutions that are visually hard to distinguish from your domain. - Your domain is short or is a common word, and some strategies produce matches unrelated to your organization. **Important:** A Lookalike Domain Strategies policy is restrictive by design. Deselecting a strategy filters out every lookalike domain detected only through it, including potential threats. Review all [Permutation strategies](docId:1pejLZ19MtYhA6XuRIMPS) before deselecting a strategy. ::: :::: :::hint{type="warning"} **Matching Policies and Subdomains** - Matching Policies assigned to a domain Identifier do not inherit down to its subdomain Identifiers. Each subdomain Identifier must have its own policies configured. - A Matching Policy can be assigned to one or multiple subdomain Identifiers, either when editing an Identifier directly or from the Matching Policies list view. ::: *** # Create a Matching Policy There are two ways to create a Matching Policy for an Identifier: 1. Create the policy from the Policies menu. 2. Create the Matching Policy from an Identifier's configuration. Click-through the following product demo to learn how to create a Matching Policy. :::Iframe{iframeHeight="0" code="
"} ::: ## Apply a Matching Policy to Past Events By default, a new Matching Policy applies only to events detected after it is assigned to an Identifier. To apply it to past events as well, select **Apply to selected identifiers' past events** when you create or edit a policy. Processing time depends on the number of past events. Most policies are applied to past events in under an hour, but Identifiers with a large number of past events can take longer. If processing is not complete after 24 hours, please contact our [Support team](http://support.flare.io/). :::hint{type="warning"} **Caution:** This action is irreversible. Once a policy is applied to past events, any events it filters out are removed from the Identifier's feed and cannot be restored. ::: ::Image[]{src="https://api.archbee.com/api/optimize/wtmLmyh6YG71yn5qVtkMM/ZdEHbVqQqQeQeayHXSjVM_image.png" size="80" isUploading="false" width="1054" height="908" darkWidth="1054" darkHeight="908" position="flex-start" showCaption="false"} ## Modify a Matching Policy When you change the content of an existing Matching Policy: - **Existing events** are re-evaluated. Only events that still match the updated policy are kept in the feed. Events that no longer match are discarded - **Future events** are evaluated against the updated policy. New events collected going forward will be filtered according to the modified rules This means changes take effect both retroactively (for events already in the feed) and prospectively (for new events). *** # Building Lucene Query Policies The Lucene Query Policy type unlocks the full power of Flare's search syntax for Identifier-level filtering. Here are some examples showing how to construct queries for common filtering scenarios. ::::ExpandableHeading **Scope to a Specific Source** Show only events from a particular source, such as a specific ransomware leak site: :::BlockQuote metadata.source:"ransomhub" ::: You can combine this with other terms. For example, to find mentions of your organization specifically on a ransomware leak site: :::BlockQuote metadata.source:"ransomhub" AND (YourCompanyName OR YourCompanyDomain) ::: :::: ::::ExpandableHeading **Filter by Date Range** Show only events estimated to have been created after a specific date: :::BlockQuote metadata.estimated\_created\_at:\[2026-01-01 TO \*] ::: :::: ::::ExpandableHeading **Filter by Credential Fields** Show only events mentioning a specific credential username: :::BlockQuote credentials.username\:admin ::: Or combine with a time window to focus on recent results: :::BlockQuote credentials.username\:admin AND metadata.estimated\_created\_at:>now-30d ::: :::: :::ExpandableHeading **Filter by Password Attributes** | **Looking for** | **Search** | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Passwords shorter than 10 characters
| `password_attributes.password_length:<10` | | Passwords with no lowercase letters | `password_attributes.password_lowercase_count:0` | | Passwords with no uppercase letters | `password_attributes.password_uppercase_count:0` | | Passwords with no numbers | `password_attributes.password_number_count:0` | | Passwords with no special characters | `password_attributes.password_special_count:0` | | Passwords meeting a full policy
(10+ characters, 1+ number, 1+ special) | password\_attributes.password\_length:>=10
AND password\_attributes.password\_number\_count:>=1 AND password\_attributes.password\_special\_count:>=1 | ::: ::::ExpandableHeading **Exclude Irrelevant Mentions** If your monitored term overlaps with an unrelated entity, use the NOT operator to exclude it: :::BlockQuote FlareWidget AND NOT GlowWidget ::: :::: ::::ExpandableHeading **Require a Specific Field to Be Present** Show only events where a URL field exists: :::BlockQuote AND \_*exists\_*:urls ::: This is useful for leaked credential Identifiers where you only want results that include a source URL. :::: ::::ExpandableHeading **Use Proximity Search** Find events where your brand name appears within five words of threat-related terms: :::BlockQuote ("YourBrand exploit"\~5 OR "YourBrand hack"\~5 OR "YourBrand database"\~5) ::: :::: **Best Practices for Building Lucene Query Policies** - **Start broad, then refine.** Begin with basic terms and add filters (date ranges, excluded terms, field-specific searches) incrementally to narrow results - **Use parentheses** to group related terms and operators clearly - **Leverage date filters** such as `metadata.estimated_created_at` and `metadata.first_crawled_at` to focus on relevant time windows - **Escape special characters.** If searching for symbols like `+`, `-`, `(`, `)`, `{`, `}`, `[`, `]`, `^`, `"`, `~`, `*`, `?`, `:`, or `\`, remember to escape them with `\` - **Be cautious with wildcards.** Broad wildcards (`*`) can return very large result sets. Combine them with other terms to keep results manageable - **Test queries in the search bar first.** Before applying a query as a Matching Policy, run it in Flare's tenant search to preview the results and confirm it returns the expected data