[Security Solution] Alerts are not triggered for windows OS if user add the exception for MAC OS Only. #102613
Comments
ghost
added
bug
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
@manishgupta-qasource Please review!! |
|
Reviewed & Assigned to @MadameSheema |
manishgupta-qasource
added
the
impact:high
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
kevinlog
added
Team:Defend Workflows
|
Pinging @elastic/security-onboarding-and-lifecycle-mgt (Team:Onboarding and Lifecycle Mgt) |
|
Chatted with @peluja1012 offline - our team can take this since we (me specifically) introduced this nuance. Proposed solution is to introduce a third option "Windows and macOS" so that users have the flexibility to create Exceptions for both OSs from scratch. Linux still needs to remain exclusive because we must form Options in the dropdown would be:
Selected OSs for new Exceptions will show the OS they apply to in the UI as the do today, we'll just make sure users can still create them for Mac and Windows together in one action if they choose to preserve the older functionality. |
|
PR: #103404 FYI @peluja1012 |
kevinlog
added
the
QA:Ready for Testing
|
Hi @kevinlog, We have validated this ticket on 7.14.0 BC3 build and Please Find the below observations: Build Details: Observation 1: "Windows and mac OS" is displaying in drop down when create the exception from scratch and successfully able to create the exception. Screenshot:
Observation 2: We have same field "event.code" with same value "malicious_file" for all OS i.e, Windows, Mac OS, Linux. when we create the exception from scratch for only one OS e.g: Mac OS with field "event.code" then the alert is not trigger from Linux and windows as well. Please find the below steps: Steps:
Screenshot: Could you please confirm if it is expected. Thanks!! |
|
Hi @kevinlog, Please Find the below observations for this issue: Build Details: Observation: When we add the exception from scratch for MacOS with field "event.code" value "malicious_file", and trigger the alert from Windows host then we get the notification on windows host but the windows alert did not streamed to Kibana. Screenshot:
Thanks!! |
|
thanks for the update @deepikakeshav-qasource I can verify that the alert documents from the Windows host are still successfully streaming to ES. See the below in Discover.
The Alert is triggering on the Endpoint and it's being streamed to ES. It seems like it might be a bug in the Detection engine. FYI @peluja1012 on this - I'm digging more and going to reproduce. This seems like a critical issue. |
kevinlog
added
impact:critical
… type (#106494) ## Summary Fixes #102613, and targets `7.14.0` as a blocker/critical Previously we never fully finished the plumbing for using the `os_types` (operating system type) in the exception lists to be able to filter out values based on this type. With the endpoint exceptions now having specific selections for os_type we have to filter it with exceptions and basically make it work. Some caveats is that the endpoints utilize `host.os.name.casless` for filtering against os_type, while agents such as auditbeat, winlogbeat, etc... use `host.os.type`. Really `host.os.type` is the correct ECS field to use, but to retain compatibility with the current version of endpoint agents I support both in one query to where if either of these two matches, then that will trigger the exceptions. * Adds e2e tests * Enhances the e2e tooling to do endpoint exception testing with `os_types`. * Adds the logic to handle os_type * Updates the unit tests ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
… type (elastic#106494) ## Summary Fixes elastic#102613, and targets `7.14.0` as a blocker/critical Previously we never fully finished the plumbing for using the `os_types` (operating system type) in the exception lists to be able to filter out values based on this type. With the endpoint exceptions now having specific selections for os_type we have to filter it with exceptions and basically make it work. Some caveats is that the endpoints utilize `host.os.name.casless` for filtering against os_type, while agents such as auditbeat, winlogbeat, etc... use `host.os.type`. Really `host.os.type` is the correct ECS field to use, but to retain compatibility with the current version of endpoint agents I support both in one query to where if either of these two matches, then that will trigger the exceptions. * Adds e2e tests * Enhances the e2e tooling to do endpoint exception testing with `os_types`. * Adds the logic to handle os_type * Updates the unit tests ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
… type (elastic#106494) ## Summary Fixes elastic#102613, and targets `7.14.0` as a blocker/critical Previously we never fully finished the plumbing for using the `os_types` (operating system type) in the exception lists to be able to filter out values based on this type. With the endpoint exceptions now having specific selections for os_type we have to filter it with exceptions and basically make it work. Some caveats is that the endpoints utilize `host.os.name.casless` for filtering against os_type, while agents such as auditbeat, winlogbeat, etc... use `host.os.type`. Really `host.os.type` is the correct ECS field to use, but to retain compatibility with the current version of endpoint agents I support both in one query to where if either of these two matches, then that will trigger the exceptions. * Adds e2e tests * Enhances the e2e tooling to do endpoint exception testing with `os_types`. * Adds the logic to handle os_type * Updates the unit tests ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
… type (#106494) (#106596) ## Summary Fixes #102613, and targets `7.14.0` as a blocker/critical Previously we never fully finished the plumbing for using the `os_types` (operating system type) in the exception lists to be able to filter out values based on this type. With the endpoint exceptions now having specific selections for os_type we have to filter it with exceptions and basically make it work. Some caveats is that the endpoints utilize `host.os.name.casless` for filtering against os_type, while agents such as auditbeat, winlogbeat, etc... use `host.os.type`. Really `host.os.type` is the correct ECS field to use, but to retain compatibility with the current version of endpoint agents I support both in one query to where if either of these two matches, then that will trigger the exceptions. * Adds e2e tests * Enhances the e2e tooling to do endpoint exception testing with `os_types`. * Adds the logic to handle os_type * Updates the unit tests ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Frank Hassanabad <[email protected]>
… type (#106494) (#106597) ## Summary Fixes #102613, and targets `7.14.0` as a blocker/critical Previously we never fully finished the plumbing for using the `os_types` (operating system type) in the exception lists to be able to filter out values based on this type. With the endpoint exceptions now having specific selections for os_type we have to filter it with exceptions and basically make it work. Some caveats is that the endpoints utilize `host.os.name.casless` for filtering against os_type, while agents such as auditbeat, winlogbeat, etc... use `host.os.type`. Really `host.os.type` is the correct ECS field to use, but to retain compatibility with the current version of endpoint agents I support both in one query to where if either of these two matches, then that will trigger the exceptions. * Adds e2e tests * Enhances the e2e tooling to do endpoint exception testing with `os_types`. * Adds the logic to handle os_type * Updates the unit tests ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Frank Hassanabad <[email protected]>
|
Hi @MadameSheema, We have validated this ticket on 7.14.0 SNAPSHOT build and observed that issue is Fixed. Alerts are triggered when we add the exception from scratch for MacOS with field "event.code" value "malicious_file", and trigger the alert from Windows host and Linux. The alerts are triggered successfully. Build Details: Observations:
Screenshot: Thanks!! |
Bug Conversion
Thanks! |
Description
Alerts are not triggered for windows OS if user add the exception for MAC OS Only.
Build Details:
Browser Details:
All
Preconditions:
Steps to Reproduce:
["event.module" "is" "malicious_file"]
Impacted Test case:
N/A
Actual Result:
Alerts are not triggered for windows OS if user add the exception for MAC OS Only.
Expected Result:
Alerts should be triggered for windows OS if user add the exception for MAC OS Only.
What's working:
N/A
What's not working:
N/A
Screenshot:
The text was updated successfully, but these errors were encountered: