-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Incorrect Related Integration shows as installed #149970
Labels
bug
Fixes for quality problems that affect the customer experience
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
Feature:Related Integrations
Security Solution Detection Rules Related Integrations feature
fixed
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
QA:Validated
Issue has been validated by QA
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
v8.7.0
Comments
spong
added
bug
Fixes for quality problems that affect the customer experience
triage_needed
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
Team:Detection Rule Management
Security Detection Rule Management Team
Feature:Rule Details
Security Solution Detection Rule Details page
labels
Jan 31, 2023
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
3 tasks
spong
added
v8.7.0
Feature:Related Integrations
Security Solution Detection Rules Related Integrations feature
and removed
triage_needed
Feature:Rule Details
Security Solution Detection Rule Details page
labels
Feb 20, 2023
banderror
added
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
labels
Feb 22, 2023
1 task
spong
added a commit
that referenced
this issue
Mar 1, 2023
…ed or enabled when they actually are (#152055) ## Summary Resolves: #142081 #149970 #150968 By adding an initial query for installed integrations and augments the existing `InstalledIntegrationArray` constructed using `PackagePolicy`'s. Also removes `version` from the `packageKey` when calculating installed integrations as there can be mis-matches between different policy versions and the integration itself, and I believe the intended behavior here is to not have multiple `relatedIntegrations` returned for different versions. We may want to expand the response here to include all the different policy versions that exist (and perhaps # of agents assigned the policy). Lastly, updates `getIntegrationsInfoFromPolicy()` to also pull the base `package` details in addition to the policy_template details, as this is what ensure base packages show as `Installed: enabled` if they have an integration policy assigned (vs just showing as `Installed` like when there isn't an integration policy). Note: This PR also adds the `getPackages()` method to the `PackageClient` as it didn't currently exist, and was only available via the fleet API via the `/api/fleet/epm/packages` route. ### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221066781-be7aa1c6-1728-4200-98b2-d40946e48bbe.png" /> </p> ### After <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221323469-e24081f9-0741-41fd-8227-9e319c98b0d3.png" /> </p> --------- Co-authored-by: Georgii Gorbachev <[email protected]>
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 1, 2023
…ed or enabled when they actually are (elastic#152055) ## Summary Resolves: elastic#142081 elastic#149970 elastic#150968 By adding an initial query for installed integrations and augments the existing `InstalledIntegrationArray` constructed using `PackagePolicy`'s. Also removes `version` from the `packageKey` when calculating installed integrations as there can be mis-matches between different policy versions and the integration itself, and I believe the intended behavior here is to not have multiple `relatedIntegrations` returned for different versions. We may want to expand the response here to include all the different policy versions that exist (and perhaps # of agents assigned the policy). Lastly, updates `getIntegrationsInfoFromPolicy()` to also pull the base `package` details in addition to the policy_template details, as this is what ensure base packages show as `Installed: enabled` if they have an integration policy assigned (vs just showing as `Installed` like when there isn't an integration policy). Note: This PR also adds the `getPackages()` method to the `PackageClient` as it didn't currently exist, and was only available via the fleet API via the `/api/fleet/epm/packages` route. ### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221066781-be7aa1c6-1728-4200-98b2-d40946e48bbe.png" /> </p> ### After <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221323469-e24081f9-0741-41fd-8227-9e319c98b0d3.png" /> </p> --------- Co-authored-by: Georgii Gorbachev <[email protected]> (cherry picked from commit b833b10)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 1, 2023
…ed or enabled when they actually are (elastic#152055) ## Summary Resolves: elastic#142081 elastic#149970 elastic#150968 By adding an initial query for installed integrations and augments the existing `InstalledIntegrationArray` constructed using `PackagePolicy`'s. Also removes `version` from the `packageKey` when calculating installed integrations as there can be mis-matches between different policy versions and the integration itself, and I believe the intended behavior here is to not have multiple `relatedIntegrations` returned for different versions. We may want to expand the response here to include all the different policy versions that exist (and perhaps # of agents assigned the policy). Lastly, updates `getIntegrationsInfoFromPolicy()` to also pull the base `package` details in addition to the policy_template details, as this is what ensure base packages show as `Installed: enabled` if they have an integration policy assigned (vs just showing as `Installed` like when there isn't an integration policy). Note: This PR also adds the `getPackages()` method to the `PackageClient` as it didn't currently exist, and was only available via the fleet API via the `/api/fleet/epm/packages` route. ### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221066781-be7aa1c6-1728-4200-98b2-d40946e48bbe.png" /> </p> ### After <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221323469-e24081f9-0741-41fd-8227-9e319c98b0d3.png" /> </p> --------- Co-authored-by: Georgii Gorbachev <[email protected]> (cherry picked from commit b833b10)
1 task
Fixed by #152055 |
We have validated this issue on 8.7.0 BC4 build and observed that issue is not occurring, It is Fixed. ✔️ Please find the below Testing Details: Build info
Hence, We are marking it as QA Validated!! Thanks!! |
bmorelli25
pushed a commit
to bmorelli25/kibana
that referenced
this issue
Mar 10, 2023
…ed or enabled when they actually are (elastic#152055) ## Summary Resolves: elastic#142081 elastic#149970 elastic#150968 By adding an initial query for installed integrations and augments the existing `InstalledIntegrationArray` constructed using `PackagePolicy`'s. Also removes `version` from the `packageKey` when calculating installed integrations as there can be mis-matches between different policy versions and the integration itself, and I believe the intended behavior here is to not have multiple `relatedIntegrations` returned for different versions. We may want to expand the response here to include all the different policy versions that exist (and perhaps # of agents assigned the policy). Lastly, updates `getIntegrationsInfoFromPolicy()` to also pull the base `package` details in addition to the policy_template details, as this is what ensure base packages show as `Installed: enabled` if they have an integration policy assigned (vs just showing as `Installed` like when there isn't an integration policy). Note: This PR also adds the `getPackages()` method to the `PackageClient` as it didn't currently exist, and was only available via the fleet API via the `/api/fleet/epm/packages` route. ### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221066781-be7aa1c6-1728-4200-98b2-d40946e48bbe.png" /> </p> ### After <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/221323469-e24081f9-0741-41fd-8227-9e319c98b0d3.png" /> </p> --------- Co-authored-by: Georgii Gorbachev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Fixes for quality problems that affect the customer experience
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
Feature:Related Integrations
Security Solution Detection Rules Related Integrations feature
fixed
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
QA:Validated
Issue has been validated by QA
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
v8.7.0
Initially identified in
8.7
/main
, for certain Related Integrations, when you install the base package it will continue to show asNot installed
and mark a sub-integration asInstalled
.For example, navigate to the
Possible Consent Grant Attack via Azure-Registered Application
rule, then install theAzure
related integration. Upon navigating back to Rule Details, you'll see that theAzure Activity Logs
integration says it's installed instead:Actual installed integrations:
Package links from Rule Details:
Azure (package only): http://localhost:5601/kbn/app/integrations/detail/azure-1.0.0/overview
Azure activity logs: http://localhost:5601/kbn/app/integrations/detail/azure-1.0.0/overview?integration=activitylogs
O365: http://localhost:5601/kbn/app/integrations/detail/o365-1.3.0/overview
Additional Note: There appears to be an additional bug with how we label the
Related Integration
title on Rule Details. Slight mis-match betweenname
andtitle
and how it can be searched/found within the fleet UI.Integration Details in Fleet:
Fleet API Response:
Fleet UI: (note: nothing returned when searching
office
):The text was updated successfully, but these errors were encountered: