[SIEM][Detection Engine] Adding new rule type specific for signal correlation #62460
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
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.
The text was updated successfully, but these errors were encountered: