-
Notifications
You must be signed in to change notification settings - Fork 19
Add fields connected to rules and alerts #355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@pzl any idea if |
are we ever going to filter/search via name? I would imagine in filtering scenarios we probably know the rule_id and will be exact matching on that, right? If for some reason we will filter on the name, do we know the full string to match (e.g. find rule by name "Unusual Network Activity")? then keyword. If we expect to filter on partial word matches (e.g. match the previous rule name based on the search string "network") then text could be ok. If we don't need to filter by name, then I would set it to keyword, and |
# Conflicts: # custom_schemas/custom_base.yml # package/endpoint/data_stream/actions/fields/fields.yml
@pzl @dasansol92 could you take a look please? Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks okay, I think things are added in the right place. Added @ashokaditya to review the intent of whats being added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some suggestions to update the mappings. Let me know if you need help or have questions.
custom_schemas/custom_base.yml
Outdated
- name: data.rule_id | ||
type: alias | ||
path: EndpointActions.data.rule_id | ||
level: custom | ||
short: EndpointActions.data.rule_id | ||
description: > | ||
ID of the rule that triggered the action | ||
|
||
- name: data.rule_name | ||
type: alias | ||
path: EndpointActions.data.rule_name | ||
level: custom | ||
short: EndpointActions.data.rule_name | ||
description: > | ||
Name of the rule that triggered the action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rules fields should be updated to use ECS names. That would mean they don't stay under EndpointActions
. They would be at the same level as agent
and user
which are ECS fields.
So the field definitions should not appear here.
EndpointActions
is a grouping we created for storing fields that are not available in ECS. Consequently, you'd also need to update the custom_subsets/elastic_endpoint/actions/actions.yaml
file to update the action doc mappings. That would end up looking like
...
...
user:
fields:
id: {}
rule:
fields:
id: {}
name: {}
By the way, there's also a rule.uuid
. Not sure if we want to use that instead of id
https://www.elastic.co/guide/en/ecs/current/ecs-rule.html
custom_schemas/custom_base.yml
Outdated
- name: data.alert_ids | ||
type: alias | ||
path: EndpointActions.data.alert_ids | ||
level: custom | ||
short: EndpointActions.data.alert_ids | ||
description: > | ||
List of alert ids that triggered the action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good as alert_ids
is a custom field.
- name: data.rule_id | ||
type: keyword | ||
level: custom | ||
short: rule id | ||
description: > | ||
ID of the rule that triggered the action | ||
|
||
- name: data.rule_name | ||
type: keyword | ||
index: false | ||
level: custom | ||
short: rule name | ||
description: > | ||
Name of the rule that triggered the action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rule_id
and rule_name
should not be here as they are not custom fields as I mentioned earlier.
- name: data.alert_ids | ||
type: keyword | ||
level: custom | ||
short: alert ids | ||
description: > | ||
List of alert ids that triggered the action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You would also need to edit the custom_subsets/elastic_endpoint/actions/actions.yaml
file instead. If you want the fields to also exist on the response doc then you need to edit the custom_subsets/elastic_endpoint/action_responses/action_responses.yaml
.
custom_schemas/custom_base.yml
Outdated
@@ -52,6 +52,14 @@ | |||
description: > | |||
The action request information | |||
|
|||
- name: data.alert_ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be named with a singular form, i.e. data.alert_id
. https://www.elastic.co/guide/en/ecs/8.6/ecs-guidelines.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took another pass at reviewing. I have a question and suggestions.
path: EndpointActions.data.alert_ids | ||
short: EndpointActions.data.alert_ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These lines also need updates. 😅
rule: | ||
fields: | ||
id: {} | ||
name: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: Do we need these fields also in the response index? If yes then we need to add this to the action_responses/action_responses.yml
file too.
- name: data.alert_id | ||
type: keyword | ||
level: custom | ||
short: alert id | ||
description: > | ||
List of alert ids that triggered the action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes. The fact that this is a keyword
we can store an array of strings here s, so you can have multiple alert ids in the doc. Just that we should conform to ECS naming best practices.
@ashokaditya Thank you for your feedback and bearing with me fixing it so many times :P |
Package endpoint - 8.8.0 containing this change is available at https://epr.elastic.co/search?package=endpoint |
Closes: https://github.com/elastic/security-team/issues/5929
Not sure if we need rule_name, but from what I remember, it was agreed that we wanted it.