Skip to content
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

[RAC] RuleDataClient writer should handle inserting required fields into new alert documents #107980

Closed
Tracked by #101016
marshallmain opened this issue Aug 9, 2021 · 5 comments
Labels
Team:Detection Alerts Security Detection Alerts Area Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Theme: rac label obsolete

Comments

@marshallmain
Copy link
Contributor

marshallmain commented Aug 9, 2021

Right now the RuleDataWriter is a thin wrapper around the ElasticsearchClient. It expects callers to provide a request that it can provide directly to the ElasticsearchClient.bulk method. The RuleDataWriter does not make any changes to the documents before sending them off to ES, which means callers are responsible for adding the required fields (at least space IDs, consumer, producer, rule type ID, event.kind, and @timestamp). Since these fields are absolutely required for all alerts-as-data documents in order for RBAC and filtering to work correctly, inserting them should not be left up to individual rule types.

Rather than taking a fully formed request ready to pass into ElasticsearchClient.bulk, the RuleDataWriter.bulk method could take an array of alert documents that each contain the rule specific fields that need to be included in the alert. The RuleDataWriter would then augment each document with the additional required fields, format the documents in the request to ElasticsearchClient.bulk, and index the docs.

This could be done as a refactor for 7.16 rather than rushing to get it in 7.15, as it's not absolutely required for alerts as data to work correctly. However, this change will make it easier to develop rules on top of the rule registry - reducing the likelihood of bugs in required fields and reducing the knowledge devs writing rules need to have about the internals of the rule registry - so it is medium-high priority.

@marshallmain marshallmain added Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Theme: rac label obsolete labels Aug 9, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@jasonrhodes
Copy link
Member

I think this is a good idea, thanks for filing 👍

@weltenwort
Copy link
Member

ℹ️ A lightweight variant of this on the lifecycle/persistent-executor-level is in progress in #108679.

@marshallmain
Copy link
Contributor Author

Addressed by #108679

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Detection Alerts Security Detection Alerts Area Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Theme: rac label obsolete
Projects
None yet
Development

No branches or pull requests

5 participants