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][Detection Engine] Adding new rule type specific for signal correlation #62460

Open
P1llus opened this issue Apr 3, 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 triage_needed

Comments

@P1llus
Copy link
Member

P1llus commented Apr 3, 2020

Currently we have a choice between Detection rule and ML Rule as a choice. It would be cool to create a third choice of some sort, with a bit different fronted view, basically when you want to create a rule that is only based on other rules triggering or not.

This could be implemented as a standalone thing, or maybe embedded into the existing rule creation form, if you can choose between a query or a dropdown (more on that below)?

Example Implementation:

A user wants to add a new rule to trigger from existing rules, and clicks on this new ruletype.
The display could then include the following:

The aggregation timespan as with normal rules.
Which indicies (defaults to only signals)
An "add signal button".

When clicking on the "add signal button" the user gets presented a dropdown list of all current detection rules we have, and are able to choose one.
Some additional available options could be a radio button with "should have/should not have triggered".

After this, the user should be able to click the "add signal button" as many times as he wants. While doing that the user is building a specific "chain" of events in a UI compared to a complex query, all which should happen in the order the user has assigned them to create an alert.

Being able to choose between a "should have/should not have" trigger for each event is to prevent false positives in cases where the chain has happened, but since it was followed by another specific event in the chain, it would confirm it is a false positive.

The end result document of the signal triggering should include all events that has been connected to that chain.

Example use-case:
A very basic example would be to have a rule for bruteforce, and a rule for successful login. Now the user could create a very simple chain, by opening this new UI and choosing the bruteforce rule from a dropdown, adding a second rule and choosing the successful login rule.

This allows for both easy and complex chains to be created in a visual manner without the knowledge of complex queries and the structure of the signal index.

@P1llus P1llus added enhancement New value added to drive a business result Team:SIEM labels Apr 3, 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 triage_needed
Projects
None yet
Development

No branches or pull requests

3 participants