Skip to content
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

Closed
spong opened this issue Jan 31, 2023 · 5 comments · Fixed by #152055
Closed

[Security Solution] Incorrect Related Integration shows as installed #149970

spong opened this issue Jan 31, 2023 · 5 comments · Fixed by #152055
Assignees
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
Copy link
Member

spong commented Jan 31, 2023

Initially identified in 8.7/main, for certain Related Integrations, when you install the base package it will continue to show as Not installed and mark a sub-integration as Installed.

For example, navigate to the Possible Consent Grant Attack via Azure-Registered Application rule, then install the Azure related integration. Upon navigating back to Rule Details, you'll see that the Azure 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 between name and title 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):

@spong 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
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@banderror
Copy link
Contributor

@spong This looks similar to #142081

@banderror 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
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)
@banderror banderror added the fixed label Mar 1, 2023
@banderror
Copy link
Contributor

Fixed by #152055

@sukhwindersingh-qasource

Hi @MadameSheema @spong

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

VERSION: 8.7.0
BUILD: 60949
COMMIT: de22cd9361a0dbf429f9648d3c7b7c45aa862e90

Screen-Shots
un

in

Hence, We are marking it as QA Validated!!

Thanks!!

@sukhwindersingh-qasource sukhwindersingh-qasource added the QA:Validated Issue has been validated by QA label Mar 6, 2023
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
Projects
None yet
5 participants