[Security Solution] Prebuilt rules' Related Integrations: Azure and GCP are shown as not installed

banderror commented 2 years ago

Epic: https://github.com/elastic/security-team/issues/2108 (internal)

Summary

If a prebuilt rule in one of its related integrations references the whole composite package (e.g. azure) without specifying a concrete integration (e.g. activitylogs)

and this integration (activitylogs) is installed in Fleet, on the Rules page this related integration will be shown as not installed:

We need to determine the path forward: either support it in Kibana or fix the prebuilt rules.

Details

Background

Fleet integrations like AWS and Azure are known to be distributed via composite packages that contain multiple integrations inside. For example:

azure package contains activitylogs, platformlogs, adlogs and other integrations
aws package contains integrations like cloudfront, cloudtrail, cloudwatch, dynamodb, etc
gcp contains compute, gke, etc

NOTE: Some of the cloud integrations are shipped via their own packages, for example Custom Google Pub/Sub Logs integration is shipped via a separate gcp_pubsub package, not the gcp one.

When the user installs integrations like Azure activity logs through the UI, Fleet actually installs its parent package (azure) with all the integrations that it contains: activitylogs, platformlogs, adlogs, etc. But we're able to distinguish enabled integrations from the disabled ones:

This doesn't work

What doesn't work in the app is: if a rule references the whole composite package (e.g. azure) without specifying a concrete integration (e.g. activitylogs), we show such related integration as not installed. Example:

This works

There's an exception from this: if a rule references the whole package that only contains a single integration of the same name (e.g. system), then it works and we show it as installed:

Schema of a related integration

/**
 * Related integration is a potential dependency of a rule. It's assumed that if the user installs
 * one of the related integrations of a rule, the rule might start to work properly because it will
 * have source events (generated by this integration) potentially matching the rule's query.
 *
 *   NOTE: Proper work is not guaranteed, because a related integration, if installed, can be
 *   configured differently or generate data that is not necessarily relevant for this rule.
 *
 * Related integration is a combination of a Fleet package and (optionally) one of the
 * package's "integrations" that this package contains. It is represented by 3 properties:
 *
 *   - `package`: name of the package (required, unique id)
 *   - `version`: version of the package (required, semver-compatible)
 *   - `integration`: name of the integration of this package (optional, id within the package)
 *
 * There are Fleet packages like `windows` that contain only one integration; in this case,
 * `integration` should be unspecified. There are also packages like `aws` and `azure` that contain
 * several integrations; in this case, `integration` should be specified.
 *
 * @example
 * const x: RelatedIntegration = {
 *   package: 'windows',
 *   version: '1.5.x',
 * };
 *
 * @example
 * const x: RelatedIntegration = {
 *   package: 'azure',
 *   version: '~1.1.6',
 *   integration: 'activitylogs',
 * };
 */
export type RelatedIntegration = t.TypeOf<typeof RelatedIntegration>;
export const RelatedIntegration = t.exact(
  t.intersection([
    t.type({
      package: NonEmptyString,
      version: NonEmptyString,
    }),
    t.partial({
      integration: NonEmptyString,
    }),
  ])
);

When we built the related integrations feature, we added support for single-integration packages like windows and system, but not composite integrations like aws and azure:

 * There are Fleet packages like `windows` that contain only one integration; in this case,
 * `integration` should be unspecified. There are also packages like `aws` and `azure` that contain
 * several integrations; in this case, `integration` should be specified.
 *
 * @example
 * const x: RelatedIntegration = {
 *   package: 'windows',
 *   version: '1.5.x',
 * };
 *
 * @example
 * const x: RelatedIntegration = {
 *   package: 'azure',
 *   version: '~1.1.6',
 *   integration: 'activitylogs',
 * };

elasticmachine commented 2 years ago

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

elasticmachine commented 2 years ago

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

terrancedejesus commented 2 years ago

@banderror - TRaDE may be able to help with this based on some changes we did for this release regarding the following PR below:

In short, we are only suggesting the least "major" compatible now instead of least compatible in general based on Kibana version. When we build the related_integrations field, it references the queries in the rule for event.dataset and parses this to determine package and integration, for example, event.dataset: gcp.audit -> package:gcp, integration:audit. If audit is parsed we check against the compatible version package's manifest and it's policy templates to determine if this is an actual integration that exists. If not, package:gcp, version:x.x.x is only given.

Before with these, it could have been a case where we did the least compatible, instead of least major compatible and that manifest reference did not have activitylogs in the policy templates and thus we only set package:azure, version:x.x.x.

I need to spend some more time looking at this on our side to determine if there is a way to be more accurate with this.

banderror commented 2 years ago

@terrancedejesus Thank you, it would be great if we could specify a package + integration instead of only a package in prebuilt rules. But if it's not possible or very hard to do in all cases, we could support this edge case in the app.

I'm still wondering, is there a legitimate situation when a concrete integration doesn't make sense or couldn't be picked due to any non-technical / product-related reasons? cc @jethr0null

banderror commented 1 year ago

@terrancedejesus So we ended up adding support for parent packages (like aws, azure, gcp) specified as related integrations in prebuilt rules, to the app. 🙂

Now the logic is as follows. If a given top-level package is specified as a related integration, for example:

// instead of this:
related_integrations: [{
  package: 'azure',
  version: '^1.1.0',
  integration: 'activitylogs'
}]

// we have this in a rule:
related_integrations: [{
  package: 'azure',
  version: '^1.1.0'
}]

Then we should be able to correctly identify the status of this related integration:

We will show Not installed if the whole package is not installed at the moment (neither any of its integration policies exist, nor any assets are installed).
We will show Installed if the package itself is installed, but no integration policies exist for this package. This happens when you click "Install package assets" in Fleet, or when you install a package by creating policies, but later delete all of them.
We will show Installed: enabled if the package is installed + any of its child integrations have an existing policy.

That said, I'm not sure if from the UX perspective, it makes any sense to specify top-level packages (like Azure) instead of their concrete integrations because I guess it's the concrete integrations that determine what source events will be indexed into ES.

cc @approksiu

banderror commented 1 year ago

@MadameSheema Could you please make sure this bug + https://github.com/elastic/kibana/issues/150968 + https://github.com/elastic/kibana/issues/149970 are verified against the next BC? These three should be fixed by https://github.com/elastic/kibana/pull/152055.

MadameSheema commented 1 year ago

@karanbirsingh-qasource @sukhwindersingh-qasource can you please help to validate this ticket on the current BC? Thanks!

sukhwindersingh-qasource commented 1 year ago

Hi @MadameSheema

We have validated this issue on 8.7.0 BC4 build and observed that issue is not occurring, It is Fixed. :heavy_check_mark:

Please find the below Testing Details:

Build info

VERSION: 8.7.0
BUILD: 60949
COMMIT: de22cd9361a0dbf429f9648d3c7b7c45aa862e90

Screen-Shot out Azure

azure out gcp

Gcp

Hence, We are marking it as QA Validated!!

Thanks!!

elastic / kibana