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

[SIEM][Action] Open case rule action #62190

Open
P1llus opened this issue Apr 1, 2020 · 1 comment
Open

[SIEM][Action] Open case rule action #62190

P1llus opened this issue Apr 1, 2020 · 1 comment
Labels
enhancement New value added to drive a business result Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:SIEM

Comments

@P1llus
Copy link
Member

P1llus commented Apr 1, 2020

This is a compilation of ideas for what a rule action for cases could be used for.

When creating a Case rule action, you should be able to fill in:

MVP from my point of view:
The creator of the case (dropdown of users with access to cases maybe? Or ask them to fill in a username and run a check when saving the rule that it exists and can access the necessary API?)

The title (With support for adding context from the event itself, either from dropdown or writing the ctx values manually)
A Description (With support for adding context from the event itself, either from dropdown or writing the ctx values manually)

Now after the MVP, there is plenty of ideas that comes up:
Re-using the Markdown editor already used in the CaseUI for writing the Description would be nice.

Being able to suppress (or even cooler, update the existing case as a comment if the same host triggers the same rule again)

Being able to choose which fields you want to aggregate on when creating the rule and action.
Just a basic example, if I choose Source.IP and Destination.IP, 10 hits and X minutes aggregation, that means that two things would happen:

  1. If the aggregation is hit, a case should be created, and ALL events hit by the aggregation should be included or available to be put in the case description.
  2. When choosing to suppress (see the idea before this one), suppression should ONLY happen on the same aggregation fields, so if the aggregation is hit again with a new source or destination, it should trigger again.

When creating aggregation rules, you should also be able to choose which field needs to be unique, a (bad) example would be multiple hosts attacking a single destination, at that point the aggregation would be "unique(source.ip)" but same destination.ip.

@spong spong added enhancement New value added to drive a business result Team:SIEM labels Apr 1, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/siem (Team:SIEM)

@MindyRS MindyRS added the Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. label Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:SIEM
Projects
None yet
Development

No branches or pull requests

4 participants