Matching Policies for Identifiers

matching policies are applied at the identifier level and give you precise control over which events appear in an identifier's feed using matching policies, you can include or exclude events based on keywords, refine results using a full lucene search query, or define what flare actively collects for an identifier matching policies are organized into two categories filtering and monitoring filtering filtering policies control which events appear in your identifier's feed three policy types are available included keywords shows only events containing at least one of the specified keywords excluded keywords removes events containing at least one of the specified keywords lucene query filters events based on a full lucene search query for complex scenarios learn more docid\ wzkscgu8oblwrnqcs56qh monitoring monitoring policies define what flare actively collects for an identifier two policy types are available cookie monitoring monitors cookies associated with an identifier authentication domain url matching for ulps and email domain monitoring (coming soon) note these policies are available with the account and session takeover prevention (astp) solution learn more docid\ wzkscgu8oblwrnqcs56qh filtering policies filtering policies control which events appear in your identifier's feed previously, identifier level filtering relied on ignore terms, which allowed users to exclude events containing specific terms from an identifier's feed these policies replace ignore terms, and introduce greater flexibility through three distinct policy types excluded keywords, included keywords, and lucene queries where ignore terms applied a simple exclusion filter, matching policies support exclusion, inclusion, and full query based filtering, giving you more control over what appears in your identifier's feed up to 10 matching policies can be assigned to an identifier all existing identifier level ignore terms will be automatically migrated to excluded keyword matching policies on their respective identifiers there are three types of filtering matching policies, each designed for a different level of filtering precision 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 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 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 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 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 you 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 matching policies and subdomains filtering 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 monitoring policies the cookie monitoring policy defines how flare monitors cookies associated with a domain identifier it is available to customers who have subscribed to the account and session takeover prevention (astp) solution how it works when a cookie monitoring policy is assigned to a domain identifier, flare scans incoming stealer logs for cookies matching the monitored domain matched cookies are securely stored and made accessible only to the tenant they belong to each policy can be assigned to any number of domain identifiers configuration each cookie monitoring policy defines two things cookie names the specific cookie names to monitor subdomain monitoring whether cookies from subdomains of the monitored domain should also be included for subdomain monitoring to work correctly, an active identifier must exist for each subdomain for example, if subdomain monitoring is enabled for flare io, cookies from api flare io will only be ingested if an identifier exists for api flare io for more information on automatic subdomain discovery, see discovery policies docid\ bmzupnrd3txznwn0veun2 domain authentication policies are coming soon up to 10 matching policies can be assigned to an identifier create a matching policy there are two ways to create a matching policy for an identifier create the policy from the policies menu create the matching policy from an identifier's configuration click through the following product demo to learn how to create a matching policy 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 scope to a specific source show only events from a particular source, such as a specific ransomware leak site metadata source "ransomhub" you can combine this with other terms for example, to find mentions of your organization specifically on a ransomware leak site metadata source "ransomhub" and (yourcompanyname or yourcompanydomain) filter by date range show only events estimated to have been created after a specific date metadata estimated created at \[2026 01 01 to ] filter by credential fields show only events mentioning a specific credential username credentials username\ admin or combine with a time window to focus on recent results credentials username\ admin and metadata estimated created at >now 30d exclude irrelevant mentions if your monitored term overlaps with an unrelated entity, use the not operator to exclude it flarewidget and not glowwidget require a specific field to be present show only events where a url field exists and exists \ urls this is useful for leaked credential identifiers where you only want results that include a source url use proximity search find events where your brand name appears within five words of threat related terms ("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 related articles