-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Security Solution] Re-validate rule exceptions when updating pre-packaged rules #84385
Comments
In his recent work with adding exception list support to ML Rules (#84006) @marshallmain mentioned adding value-list support to EQL would be a similar LoE -- just needing to determine behavior around sequence EQL queries. Once that effort is completed though, |
@jmikell821 @Donnater for 7.11, the below pre-packaged rules have been updated from Rules updated from `query` type to `eql`
7.11: c25e9c87-95e1-4368-bfab-9fd34cf867ec - Microsoft IIS Connection Strings Decryption -> type: eql, language: eql
7.11: 0564fb9d-90b9-4234-a411-82a546dc1343 - Microsoft IIS Service Account Password Dumped -> type: eql, language: eql
7.11: 7405ddf1-6c8e-41ce-818f-48bea6bcaed8 - Potential Modification of Accessibility Binaries -> type: eql, language: eql
7.11: 5aee924b-6ceb-4633-980e-1bde8cdb40c5 - Potential Secure File Deletion via SDelete Utility -> type: eql, language: eql
7.11: 6ea41894-66c3-4df7-ad6b-2c5074eb3df8 - Potential Windows Error Manager Masquerading -> type: eql, language: eql
7.11: 2e1e835d-01e5-48ca-b9fc-7a61f7f11902 - Renamed AutoIt Scripts Interpreter -> type: eql, language: eql
7.11: 201200f1-a99b-43fb-88ed-f65a45c4972c - Suspicious .NET Code Compilation -> type: eql, language: eql
7.11: b41a13c6-ba45-4bab-a534-df53d0cfed6a - Suspicious Endpoint Security Parent Process -> type: eql, language: eql
7.11: a624863f-a70d-417f-a7d2-7a404638d47f - Suspicious MS Office Child Process -> type: eql, language: eql
7.11: e2f9fdf5-8076-45ad-9427-41e0e03dc9c2 - Suspicious Process Execution via Renamed PsExec Executable -> type: eql, language: eql
7.11: 97aba1ef-6034-4bd3-8c1a-1e0996b27afa - Suspicious Zoom Child Process -> type: eql, language: eql
7.11: 1dcc51f6-ba26-49e7-9ef4-2655abb2361e - UAC Bypass via DiskCleanup Scheduled Task Hijack -> type: eql, language: eql
7.11: 35df0dd8-092d-4a83-88c1-5151a804f31b - Unusual Parent-Child Relationship -> type: eql, language: eql |
Update on the status of rule types and supported exceptions:
With the current status, we still have a potential problem with value list exceptions being added to EQL or Threshold rules. Updates to the detection engine that converted value list exception evaluation to use Value list exceptions for threshold rules are more difficult, and may not be implemented soon since the nature of threshold aggregations means we don't get all the matching documents back in the search response. This makes it impossible to evaluate each document against the value list exception in the current implementation. Therefore we still have a long term need for providing some kind of validation that prevents (or at least warns) users when value list exceptions are attached to a threshold rule. As for implementing validation that prevents value list exceptions from being added to Threshold and EQL rules, the main problem is that exception lists exist independent of specific rules, instead, rules reference one or more exception lists by If we're willing to do a migration, a solution would be to separate value list and non-value list exceptions into different exception list types and prevent threshold and EQL rules from referencing the value-list exception lists. This could be done at rule create/update time, which is also simpler than attempting to retrieve all rules that reference an exception list at exception item create time. This migration work would not be achievable for 7.12. A near term mitigation would be to add a check in Threshold and EQL rules at rule execution time that checks if the exception list(s) the rule uses contain any value list exception items. If they do, then we would write a @spong @peluja1012 Does adding a warning on rule execution if the exception list contains value list exception items that can't be evaluated by the rule sound like a good approach to mitigate this issue in 7.12? |
@deepikakeshav-qasource can you please validate this ticket on 7.12.0 BC4? Taking a look to the PR can be useful :) |
@marshallmain @spong can you please check Deepika's observations? Thanks :) |
Hey there @deepikakeshav-qasource! 👋 So based off of #92914, it looks like the notification that is displayed is in a partial warning thrown during rule execution. Those will show up not under the exceptions tab, but as a banner at the top of Rule Details (don't believe they're shown in failure history, but I could be incorrect here so good to check there too :). The message that should be display is:
There's definitely more we can do for UX here when viewing the exceptions tab (like have an error callout within the exception entry), but the root issue here should be solved when we break each rule out into their own type as either an SO migration will need to be performed (or a delete-and-add back with resources sorta flow). |
Hi @spong, Thank you for provide the information. We have validated this issue on the 7.12.0 BC4 build and Please find our below observations: Build Details:
observation: 1 observation: 2 observation: 3 Moreover, No item is displyed in "Failure History" Please let us known if something more to be checked for this issue. Else we are good to add "QA Validated" to it. Thanks !! |
Since fix has been validated for Threshold/EQL rules going to go ahead and close this as we'll be re-visiting what it means to 'update a pre-packaged rule' from the RAC perspective. |
Bug Conversion:Created 01 Test-Case for this Ticket Thanks!! |
In v7.10 some pre-packaged rules were updated to change their type from
query
toeql
(#82214). While the system supports this rule-type change, and user rules can be upgraded without error, one thing that can occur is that any existingexception list
could now no longer be valid for the new rule type.For example, if in
7.9
a user installed theNetwork Connection via Certutil
pre-packaged rule (of typequery
), then added an exception list item using a value list, once the user upgrades to7.10
and updates their rule (now of typeeql
), the value list exception list item on the rule will no longer be valid since EQL rules do not support value lists (#79871).Another touch point (though less likely) would be if the rule-type was changed to a type that didn't support exceptions at all, like a Machine Learning rule. In this instance the updated ML rule would then reference an exception list, which is not valid for machine learning rules.
To mitigate this, we should add API validation for adding value list exceptions to EQL rules (similar as we did with
endpoint
exceptions #71791), and ensure this validation is performed when a rule'stype
is updated.For the above example, the expected UX once this is in place would be that when the user attempts to update their pre-packaged rules, if there are any validation errors they would then be displayed to the user within an error toast, and so directing them to remove any invalid exception list items and perform the upgrade again. All other rules should still update.
The text was updated successfully, but these errors were encountered: