Is there a solution for adding a value in a tag field or custom field by a alert rule when meeting specific conditions (IOC's). Purpose is to have new alerts marked by a tag (or better a custom field with an URI to the explanation) that a detection hit has already been seen and research info is available. (it is not my intention to use the close option, because I do want to see specific alerts that are most probably false positive, but in some conditions might change that point of view and need investigation to confirm that it indeed is.
To add a tag or custom field in an Elastic Security alert rule based on specific conditions (like the presence of certain Indicators of Compromise, or IOCs), you can use Enrichments in detection rules or customize Event Correlation rules to apply tags when specific criteria are met.
Here’s a step-by-step approach to set this up:
1. Use Enrichment for Tagging Based on Conditions
Elastic Security’s Enrichments feature lets you enrich alerts with specific fields when an alert matches a set of conditions, such as an IOC. To apply an enrichment based on an IOC:
- Go to Security > Rules and select Create rule.
- Choose a rule type (e.g., Indicator Match if using IOCs).
- In the Enrichments section, add the enrichment criteria. This can involve setting conditions to match specific fields or indicators that trigger the enrichment.
- Define the fields to be added as a tag or custom field. For instance, you can add a field with a URI link or research info if an IOC match is found.
2. Add a Custom Action in Detection Rule for Tagging
Another approach is to use a detection rule with specific logic and then add a tagging action. To create a custom tagging rule:
- Set up your KQL (Kibana Query Language) or Lucene query to filter alerts matching specific IOCs or other conditions in the rule.
- In the Actions section of the rule, you can define an action to add tags to alerts that meet these conditions:
- Add a Custom webhook action pointing to an endpoint where you control the tag addition, or use the Add tags action if available in your version.
Note that custom fields with URI information for reference are better managed if your rule output is piped into a case management or SIEM system with this capability.
3. Manage False Positives Separately
If you don’t want to close these alerts outright but tag them instead, you can use specific tags (e.g., "likely_false_positive") and then create a Kibana Saved Search or separate view for alerts tagged this way. This setup will help you monitor potentially ignored alerts but still keep them visible for review.
This configuration should help you maintain visibility on potentially recurring alerts with clear tagging for additional context, without needing to close or dismiss the alerts directly.
@Peter_K have you looked into using an Indicator Match rule for this use case?
This rule type searches for matches between two datasets, and generates alerts enriched with information from both sides. In your situation, you could define a rule that matches the alerts you wish to tag against known indicators, and the result would be an alert enriched with information from the indicator(s) that it matched. By default this would now generate two alerts where you only want one, but that could be solved either by defining some "close child" action as part of the IM rule, or defining the intermediate alerts as building block alerts, or by simply closing both as part of your investigation process.
While IM rules can be slow on large sets of data, on a restricted dataset like this (e.g. alerts) you should have no issue.
For more information on what's populated on these IM alerts, check out the above documentation as well as the investigation guides of our prebuilt IM rules.
Thanks for your reply. This looks promising. I need to gain knowledge in this matter and will reply the outcome to let you know
Thanks for your reply also. I do also need to gain knowledge in this matter and will reply the outcome to let you know
@thiagodsrodrigues @RylandHerrick Thanks for your reply folks.
For me it is not entirely clear what y'all mean with a "close child"/"add tag" action. Is this the Webhook action that talks to some kind of API that in turn talks to the Elastic Security APIs?
I'm running ELK 8.15.2 and only have access to the actions seen in the attached screenshot. Am I missing something? 
Thanks!
