[Security Solutions] Fixes exception lists to be able to filter on os type#106494
Conversation
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
💛 Build succeeded, but was flaky
Test FailuresKibana Pipeline / general / Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/transform/deleting·ts.transform deleting batch transform with latest configuration delete transformStandard OutStack TraceKibana Pipeline / general / Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/transform/deleting·ts.transform deleting "after all" hook in "deleting"Standard OutStack TraceKibana Pipeline / general / Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/transform.transform "after all" hook in "transform"Standard OutStack TraceMetrics [docs]Public APIs missing comments
Any counts in public APIs
Async chunks
Public APIs missing exports
Unknown metric groupsAPI count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
peluja1012
left a comment
There was a problem hiding this comment.
Logic makes sense to me. Thanks for adding the backend plumbing to support Linux exceptions!
… 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 <frank.hassanabad@elastic.co>
… 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 <frank.hassanabad@elastic.co>
Summary
Fixes #102613, and targets
7.14.0as a blocker/criticalPreviously 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.caslessfor filtering against os_type, while agents such as auditbeat, winlogbeat, etc... usehost.os.type. Reallyhost.os.typeis 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.os_types.Checklist
Delete any items that are not applicable to this PR.