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] Allow importing prebuilt rules at the API level #180168

Closed
Tracked by #174168
jpdjere opened this issue Apr 5, 2024 · 5 comments
Closed
Tracked by #174168

[Security Solution] Allow importing prebuilt rules at the API level #180168

jpdjere opened this issue Apr 5, 2024 · 5 comments
Assignees
Labels
8.17 candidate enhancement New value added to drive a business result Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area 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.

Comments

@jpdjere
Copy link
Contributor

jpdjere commented Apr 5, 2024

Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168

Summary

  • Allow importing prebuilt rules at the API level
  • API users should be able to import both custom and prebuilt rules, including any customizations that might have been done over their modifiable fields.
  • An imported prebuilt rule should continue to track the rule asset from security_detection_engine package if the rule_id matches. This means that a user will be able to upgrade a previously imported prebuilt rule, visualize any diffs on any customized fields, and continue to receive updates on the rule.
  • To allow for importing of Elastic prebuilt rules, we will not rely on the rule_source or the immutable fields (which are not part of the import endpoint parameters), but we will rather calculate them dynamically based on the rule_id and version request parameters.

Acceptance criteria

  • Changes need to be hidden behind prebuiltRulesCustomizationEnabled feature flag
  • Modify the Rule Import schema as described in the RFC to allow the importing of prebuilt rules. (TBD: do we hide this change behind a FF?)
  • Modify the import handler logic as follows:

From the RFC:

The logic to importing a rule is as follows:

  • First, read the import endpoint request parameters rule_id and version. These two are two required parameters in the endpoint.

  • Secondly, check that the security_detection_engine Fleet package is installed and install it if it isn't. We will need the package to be installed to check if a rule that is being imported is an Elastic prebuilt rule.

  • Then, using the rule_id and version, attempt to fetch the corresponding security-rule asset from ES.

  • If a matching rule_id and version is found, that means that the rule is an Elastic prebuilt rule, and we should therefore dynamically calculate the rule's rule_source field and its subfields:

    • type: should be always external since a matching external security-rule was found.
    • is_customized: should be calculated based on the differences between the security-rule asset's fields and the rule fields from the import request. If any of them are different, i.e. have diverged from the base version, is_customized should be true.
{ 
  immutable: true,
  ruleSource: {
    type: 'external',
    isCustomized: <either true or false, depending on payload>
  }
}
  • Finally, using the import payload, plus the rule's security-rule asset fields and the calculated rule_source fields, create the rule, or update it if already exists in Kibana.

If a matching rule_id is found, but the version is not found, it means there are some versions of this prebuilt rule known to Kibana, which means we should identify the rule being imported as prebuilt. The prebuilt rules package has a limit on the number of historical rule versions, and we can't assume that for a given rule_id we will always have ALL historical versions available as security-rule assets.

In this case, we will set the rule's params to be:

{ 
  immutable: true,
  ruleSource: {
    type: 'external',
    isCustomized: false
  }
}

If a matching rule_id is NOT found, that means that the rule is a custom rule. And rule_source will be simply:

{ 
  immutable: false,
  ruleSource: {
    type: 'internal',
  }
}

And we can finally create a rule or update an existing rule using the request payload and the calculated rule_source field.

Background

1. See table for Importing rules, with expected import payload input and expected rule outputs
2. See how to handle different scenarios for the version parameter

@jpdjere jpdjere added 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:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area labels Apr 5, 2024
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

@elasticmachine
Copy link
Contributor

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

@banderror banderror changed the title [Security Solution] Allow importing prebuilt rules at the API level [Security Solution] Allow importing prebuilt rules at the API level (DRAFT) Apr 17, 2024
@banderror
Copy link
Contributor

Hey @jpdjere, tomorrow we'll have Milestone 3 onboarding meetings with Ryland and Zhenia, and I think it would be great if we could finalize descriptions for all the tickets we're going to ask them to help us with. Could you please prioritize writing a description at least for this one before the meetings?

@jpdjere jpdjere changed the title [Security Solution] Allow importing prebuilt rules at the API level (DRAFT) [Security Solution] Allow importing prebuilt rules at the API level Jul 17, 2024
@banderror banderror added enhancement New value added to drive a business result and removed triage_needed labels Jul 17, 2024
rylnd added a commit that referenced this issue Oct 16, 2024
…90198)

## Summary

This PR introduces the backend functionality necessary to import
prebuilt rules via our existing import API. The
[RFC](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md)
goes into detail, and the import-specific issue is described
[here](#180168), but at a high
level we're adding two things in this PR:

1. The logic to calculate the new `rule_source` field on import, which
contains the information about the rule's relationship to existing
prebuilt rules.
2. A new code path for importing rules, which respects the calculated
`rule_source` field.

In order to maintain backwards compatibility with the existing import
logic, and because the existing import implementation is hard to
modify/extend, I opted to add a top-level switch on the feature flag in
the import route itself, which calls either the existing import function
(now named `importRulesLegacy`), or the new function, `importRules`,
which ultimately calls the new `DetectionRulesClient` method,
`importRules`. Neither knows about the feature flag, and thanks to great
suggestions from @xcrzx there are nice, clean boundaries between the
import functions and the client methods.

I went down the path of trying to write the new import code by reusing
the outer `importRules` function, but after discussion with the team we
decided it was simplest to simply bifurcate the code at that point, so
that we have:

1. The legacy import code, which:
    * only supports custom rules (`immutable: false`)
    * accepts `version` as an optional parameter
* calculates a legacy `rule_source` value based on the `immutable` field
2. The new import code, which
    * Installs the prebuilt rules assets as necessary
    * Accepts both kinds of rules (`immutable: true/false`)
    * Requires `version` as a parameter for _prebuilt_ rules
    * Allows `version` to be optional for custom rules
    * calculates a proper `rule_source` (and `immutable`)


### Deprecation of `immutable`
The RFC (and thus I) had initially thought that we'd be deprecating the
`immutable` field as part of this PR/Epic. However, after
[discussion](#190198 (comment))
we have opted to continue supporting `immutable` until such time as we
can drop it, compatibility-wise.


## Steps to Review
1. Enable the Feature Flag: `prebuiltRulesCustomizationEnabled`
2. Install the prebuilt rules package via fleet
3. Create and export a custom rule to serve as a template (or download
one:

curl -L -H 'Authorization: 8eef0fe5d7dfc52b' -o 'rules_export
(1).ndjson'
https://upload.elastic.co/d/4693e7fe4356ce7bcf7b7d6b72881a9fd189730c61bf5ef47c9930458d746979
    )
    
4. Install some prebuilt rules, and obtain a prebuilt rule's `rule_id`,
e.g. `ac8805f6-1e08-406c-962e-3937057fa86f`
5. Edit the `rules_export.ndjson` to contain only the first line, and
modify the `rule_id` with the prebuilt rule's
6. Import `rules_export.ndjson` and then retrieve the rule via the Dev
Console:

GET
kbn:api/detection_engine/rules?rule_id=ac8805f6-1e08-406c-962e-3937057fa86f

7. Observe that the rule has the expected `rule_source` and `immutable`
values
8. Test other permutations of import by modifying `rules_export.ndjson`
and re-importing; see ([the test
plan](#191116) as well as a
[reference table of
scenarios](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md#importing-rules))

### Checklist

Delete any items that are not applicable to this PR.

- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed

---------

Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Georgii Gorbachev <[email protected]>
kibanamachine pushed a commit to kibanamachine/kibana that referenced this issue Oct 16, 2024
…astic#190198)

## Summary

This PR introduces the backend functionality necessary to import
prebuilt rules via our existing import API. The
[RFC](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md)
goes into detail, and the import-specific issue is described
[here](elastic#180168), but at a high
level we're adding two things in this PR:

1. The logic to calculate the new `rule_source` field on import, which
contains the information about the rule's relationship to existing
prebuilt rules.
2. A new code path for importing rules, which respects the calculated
`rule_source` field.

In order to maintain backwards compatibility with the existing import
logic, and because the existing import implementation is hard to
modify/extend, I opted to add a top-level switch on the feature flag in
the import route itself, which calls either the existing import function
(now named `importRulesLegacy`), or the new function, `importRules`,
which ultimately calls the new `DetectionRulesClient` method,
`importRules`. Neither knows about the feature flag, and thanks to great
suggestions from @xcrzx there are nice, clean boundaries between the
import functions and the client methods.

I went down the path of trying to write the new import code by reusing
the outer `importRules` function, but after discussion with the team we
decided it was simplest to simply bifurcate the code at that point, so
that we have:

1. The legacy import code, which:
    * only supports custom rules (`immutable: false`)
    * accepts `version` as an optional parameter
* calculates a legacy `rule_source` value based on the `immutable` field
2. The new import code, which
    * Installs the prebuilt rules assets as necessary
    * Accepts both kinds of rules (`immutable: true/false`)
    * Requires `version` as a parameter for _prebuilt_ rules
    * Allows `version` to be optional for custom rules
    * calculates a proper `rule_source` (and `immutable`)

### Deprecation of `immutable`
The RFC (and thus I) had initially thought that we'd be deprecating the
`immutable` field as part of this PR/Epic. However, after
[discussion](elastic#190198 (comment))
we have opted to continue supporting `immutable` until such time as we
can drop it, compatibility-wise.

## Steps to Review
1. Enable the Feature Flag: `prebuiltRulesCustomizationEnabled`
2. Install the prebuilt rules package via fleet
3. Create and export a custom rule to serve as a template (or download
one:

curl -L -H 'Authorization: 8eef0fe5d7dfc52b' -o 'rules_export
(1).ndjson'
https://upload.elastic.co/d/4693e7fe4356ce7bcf7b7d6b72881a9fd189730c61bf5ef47c9930458d746979
    )

4. Install some prebuilt rules, and obtain a prebuilt rule's `rule_id`,
e.g. `ac8805f6-1e08-406c-962e-3937057fa86f`
5. Edit the `rules_export.ndjson` to contain only the first line, and
modify the `rule_id` with the prebuilt rule's
6. Import `rules_export.ndjson` and then retrieve the rule via the Dev
Console:

GET
kbn:api/detection_engine/rules?rule_id=ac8805f6-1e08-406c-962e-3937057fa86f

7. Observe that the rule has the expected `rule_source` and `immutable`
values
8. Test other permutations of import by modifying `rules_export.ndjson`
and re-importing; see ([the test
plan](elastic#191116) as well as a
[reference table of
scenarios](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md#importing-rules))

### Checklist

Delete any items that are not applicable to this PR.

- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed

---------

Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Georgii Gorbachev <[email protected]>
(cherry picked from commit c0b1301)
kibanamachine added a commit that referenced this issue Oct 16, 2024
…PI (#190198) (#196613)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[Security Solution] Allow importing of prebuilt rules via the API
(#190198)](#190198)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ryland
Herrick","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-10-16T21:19:05Z","message":"[Security
Solution] Allow importing of prebuilt rules via the API (#190198)\n\n##
Summary\r\n\r\nThis PR introduces the backend functionality necessary to
import\r\nprebuilt rules via our existing import API.
The\r\n[RFC](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md)\r\ngoes
into detail, and the import-specific issue is
described\r\n[here](#180168),
but at a high\r\nlevel we're adding two things in this PR:\r\n\r\n1. The
logic to calculate the new `rule_source` field on import,
which\r\ncontains the information about the rule's relationship to
existing\r\nprebuilt rules.\r\n2. A new code path for importing rules,
which respects the calculated\r\n`rule_source` field.\r\n\r\nIn order to
maintain backwards compatibility with the existing import\r\nlogic, and
because the existing import implementation is hard to\r\nmodify/extend,
I opted to add a top-level switch on the feature flag in\r\nthe import
route itself, which calls either the existing import function\r\n(now
named `importRulesLegacy`), or the new function, `importRules`,\r\nwhich
ultimately calls the new `DetectionRulesClient`
method,\r\n`importRules`. Neither knows about the feature flag, and
thanks to great\r\nsuggestions from @xcrzx there are nice, clean
boundaries between the\r\nimport functions and the client
methods.\r\n\r\nI went down the path of trying to write the new import
code by reusing\r\nthe outer `importRules` function, but after
discussion with the team we\r\ndecided it was simplest to simply
bifurcate the code at that point, so\r\nthat we have:\r\n\r\n1. The
legacy import code, which:\r\n * only supports custom rules (`immutable:
false`)\r\n * accepts `version` as an optional parameter\r\n* calculates
a legacy `rule_source` value based on the `immutable` field\r\n2. The
new import code, which\r\n * Installs the prebuilt rules assets as
necessary\r\n * Accepts both kinds of rules (`immutable:
true/false`)\r\n * Requires `version` as a parameter for _prebuilt_
rules\r\n * Allows `version` to be optional for custom rules\r\n *
calculates a proper `rule_source` (and `immutable`)\r\n\r\n\r\n###
Deprecation of `immutable`\r\nThe RFC (and thus I) had initially thought
that we'd be deprecating the\r\n`immutable` field as part of this
PR/Epic. However,
after\r\n[discussion](https://github.com/elastic/kibana/pull/190198#discussion_r1736021749)\r\nwe
have opted to continue supporting `immutable` until such time as
we\r\ncan drop it, compatibility-wise.\r\n\r\n\r\n## Steps to
Review\r\n1. Enable the Feature Flag:
`prebuiltRulesCustomizationEnabled`\r\n2. Install the prebuilt rules
package via fleet\r\n3. Create and export a custom rule to serve as a
template (or download\r\none:\r\n\r\ncurl -L -H 'Authorization:
8eef0fe5d7dfc52b' -o
'rules_export\r\n(1).ndjson'\r\nhttps://upload.elastic.co/d/4693e7fe4356ce7bcf7b7d6b72881a9fd189730c61bf5ef47c9930458d746979\r\n
)\r\n \r\n4. Install some prebuilt rules, and obtain a prebuilt rule's
`rule_id`,\r\ne.g. `ac8805f6-1e08-406c-962e-3937057fa86f`\r\n5. Edit the
`rules_export.ndjson` to contain only the first line, and\r\nmodify the
`rule_id` with the prebuilt rule's\r\n6. Import `rules_export.ndjson`
and then retrieve the rule via the
Dev\r\nConsole:\r\n\r\nGET\r\nkbn:api/detection_engine/rules?rule_id=ac8805f6-1e08-406c-962e-3937057fa86f\r\n\r\n7.
Observe that the rule has the expected `rule_source` and
`immutable`\r\nvalues\r\n8. Test other permutations of import by
modifying `rules_export.ndjson`\r\nand re-importing; see ([the
test\r\nplan](#191116) as well as
a\r\n[reference table
of\r\nscenarios](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md#importing-rules))\r\n\r\n###
Checklist\r\n\r\nDelete any items that are not applicable to this
PR.\r\n\r\n- [x] Any text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[
]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [ ] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<[email protected]>\r\nCo-authored-by:
Georgii Gorbachev
<[email protected]>","sha":"c0b1301a21b74e8b643fc0e898b1d982fd85d98e","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:Detections
and Resp","Team: SecuritySolution","Team:Detection Rule
Management","Feature:Prebuilt Detection
Rules","v8.16.0","backport:version"],"title":"[Security Solution] Allow
importing of prebuilt rules via the
API","number":190198,"url":"https://github.com/elastic/kibana/pull/190198","mergeCommit":{"message":"[Security
Solution] Allow importing of prebuilt rules via the API (#190198)\n\n##
Summary\r\n\r\nThis PR introduces the backend functionality necessary to
import\r\nprebuilt rules via our existing import API.
The\r\n[RFC](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md)\r\ngoes
into detail, and the import-specific issue is
described\r\n[here](#180168),
but at a high\r\nlevel we're adding two things in this PR:\r\n\r\n1. The
logic to calculate the new `rule_source` field on import,
which\r\ncontains the information about the rule's relationship to
existing\r\nprebuilt rules.\r\n2. A new code path for importing rules,
which respects the calculated\r\n`rule_source` field.\r\n\r\nIn order to
maintain backwards compatibility with the existing import\r\nlogic, and
because the existing import implementation is hard to\r\nmodify/extend,
I opted to add a top-level switch on the feature flag in\r\nthe import
route itself, which calls either the existing import function\r\n(now
named `importRulesLegacy`), or the new function, `importRules`,\r\nwhich
ultimately calls the new `DetectionRulesClient`
method,\r\n`importRules`. Neither knows about the feature flag, and
thanks to great\r\nsuggestions from @xcrzx there are nice, clean
boundaries between the\r\nimport functions and the client
methods.\r\n\r\nI went down the path of trying to write the new import
code by reusing\r\nthe outer `importRules` function, but after
discussion with the team we\r\ndecided it was simplest to simply
bifurcate the code at that point, so\r\nthat we have:\r\n\r\n1. The
legacy import code, which:\r\n * only supports custom rules (`immutable:
false`)\r\n * accepts `version` as an optional parameter\r\n* calculates
a legacy `rule_source` value based on the `immutable` field\r\n2. The
new import code, which\r\n * Installs the prebuilt rules assets as
necessary\r\n * Accepts both kinds of rules (`immutable:
true/false`)\r\n * Requires `version` as a parameter for _prebuilt_
rules\r\n * Allows `version` to be optional for custom rules\r\n *
calculates a proper `rule_source` (and `immutable`)\r\n\r\n\r\n###
Deprecation of `immutable`\r\nThe RFC (and thus I) had initially thought
that we'd be deprecating the\r\n`immutable` field as part of this
PR/Epic. However,
after\r\n[discussion](https://github.com/elastic/kibana/pull/190198#discussion_r1736021749)\r\nwe
have opted to continue supporting `immutable` until such time as
we\r\ncan drop it, compatibility-wise.\r\n\r\n\r\n## Steps to
Review\r\n1. Enable the Feature Flag:
`prebuiltRulesCustomizationEnabled`\r\n2. Install the prebuilt rules
package via fleet\r\n3. Create and export a custom rule to serve as a
template (or download\r\none:\r\n\r\ncurl -L -H 'Authorization:
8eef0fe5d7dfc52b' -o
'rules_export\r\n(1).ndjson'\r\nhttps://upload.elastic.co/d/4693e7fe4356ce7bcf7b7d6b72881a9fd189730c61bf5ef47c9930458d746979\r\n
)\r\n \r\n4. Install some prebuilt rules, and obtain a prebuilt rule's
`rule_id`,\r\ne.g. `ac8805f6-1e08-406c-962e-3937057fa86f`\r\n5. Edit the
`rules_export.ndjson` to contain only the first line, and\r\nmodify the
`rule_id` with the prebuilt rule's\r\n6. Import `rules_export.ndjson`
and then retrieve the rule via the
Dev\r\nConsole:\r\n\r\nGET\r\nkbn:api/detection_engine/rules?rule_id=ac8805f6-1e08-406c-962e-3937057fa86f\r\n\r\n7.
Observe that the rule has the expected `rule_source` and
`immutable`\r\nvalues\r\n8. Test other permutations of import by
modifying `rules_export.ndjson`\r\nand re-importing; see ([the
test\r\nplan](#191116) as well as
a\r\n[reference table
of\r\nscenarios](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md#importing-rules))\r\n\r\n###
Checklist\r\n\r\nDelete any items that are not applicable to this
PR.\r\n\r\n- [x] Any text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[
]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [ ] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<[email protected]>\r\nCo-authored-by:
Georgii Gorbachev
<[email protected]>","sha":"c0b1301a21b74e8b643fc0e898b1d982fd85d98e"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/190198","number":190198,"mergeCommit":{"message":"[Security
Solution] Allow importing of prebuilt rules via the API (#190198)\n\n##
Summary\r\n\r\nThis PR introduces the backend functionality necessary to
import\r\nprebuilt rules via our existing import API.
The\r\n[RFC](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md)\r\ngoes
into detail, and the import-specific issue is
described\r\n[here](#180168),
but at a high\r\nlevel we're adding two things in this PR:\r\n\r\n1. The
logic to calculate the new `rule_source` field on import,
which\r\ncontains the information about the rule's relationship to
existing\r\nprebuilt rules.\r\n2. A new code path for importing rules,
which respects the calculated\r\n`rule_source` field.\r\n\r\nIn order to
maintain backwards compatibility with the existing import\r\nlogic, and
because the existing import implementation is hard to\r\nmodify/extend,
I opted to add a top-level switch on the feature flag in\r\nthe import
route itself, which calls either the existing import function\r\n(now
named `importRulesLegacy`), or the new function, `importRules`,\r\nwhich
ultimately calls the new `DetectionRulesClient`
method,\r\n`importRules`. Neither knows about the feature flag, and
thanks to great\r\nsuggestions from @xcrzx there are nice, clean
boundaries between the\r\nimport functions and the client
methods.\r\n\r\nI went down the path of trying to write the new import
code by reusing\r\nthe outer `importRules` function, but after
discussion with the team we\r\ndecided it was simplest to simply
bifurcate the code at that point, so\r\nthat we have:\r\n\r\n1. The
legacy import code, which:\r\n * only supports custom rules (`immutable:
false`)\r\n * accepts `version` as an optional parameter\r\n* calculates
a legacy `rule_source` value based on the `immutable` field\r\n2. The
new import code, which\r\n * Installs the prebuilt rules assets as
necessary\r\n * Accepts both kinds of rules (`immutable:
true/false`)\r\n * Requires `version` as a parameter for _prebuilt_
rules\r\n * Allows `version` to be optional for custom rules\r\n *
calculates a proper `rule_source` (and `immutable`)\r\n\r\n\r\n###
Deprecation of `immutable`\r\nThe RFC (and thus I) had initially thought
that we'd be deprecating the\r\n`immutable` field as part of this
PR/Epic. However,
after\r\n[discussion](https://github.com/elastic/kibana/pull/190198#discussion_r1736021749)\r\nwe
have opted to continue supporting `immutable` until such time as
we\r\ncan drop it, compatibility-wise.\r\n\r\n\r\n## Steps to
Review\r\n1. Enable the Feature Flag:
`prebuiltRulesCustomizationEnabled`\r\n2. Install the prebuilt rules
package via fleet\r\n3. Create and export a custom rule to serve as a
template (or download\r\none:\r\n\r\ncurl -L -H 'Authorization:
8eef0fe5d7dfc52b' -o
'rules_export\r\n(1).ndjson'\r\nhttps://upload.elastic.co/d/4693e7fe4356ce7bcf7b7d6b72881a9fd189730c61bf5ef47c9930458d746979\r\n
)\r\n \r\n4. Install some prebuilt rules, and obtain a prebuilt rule's
`rule_id`,\r\ne.g. `ac8805f6-1e08-406c-962e-3937057fa86f`\r\n5. Edit the
`rules_export.ndjson` to contain only the first line, and\r\nmodify the
`rule_id` with the prebuilt rule's\r\n6. Import `rules_export.ndjson`
and then retrieve the rule via the
Dev\r\nConsole:\r\n\r\nGET\r\nkbn:api/detection_engine/rules?rule_id=ac8805f6-1e08-406c-962e-3937057fa86f\r\n\r\n7.
Observe that the rule has the expected `rule_source` and
`immutable`\r\nvalues\r\n8. Test other permutations of import by
modifying `rules_export.ndjson`\r\nand re-importing; see ([the
test\r\nplan](#191116) as well as
a\r\n[reference table
of\r\nscenarios](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md#importing-rules))\r\n\r\n###
Checklist\r\n\r\nDelete any items that are not applicable to this
PR.\r\n\r\n- [x] Any text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[
]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [ ] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<[email protected]>\r\nCo-authored-by:
Georgii Gorbachev
<[email protected]>","sha":"c0b1301a21b74e8b643fc0e898b1d982fd85d98e"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ryland Herrick <[email protected]>
rylnd added a commit that referenced this issue Nov 11, 2024
…191116)

## Summary

This PR introduces test plans for both [Prebuilt Rule
Import](#180168) (corresponding
[PR](#190198)) and [Prebuilt Rule
Export](#180167) (corresponding
[PR](#194498)). Import is
considerably more complicated as it is calculating new values (for
`rule_source`, `immutable`), while the export work is mainly removing
existing restrictions (which allowed only custom rules to be exported).

---------

Co-authored-by: Elastic Machine <[email protected]>
kibanamachine pushed a commit to kibanamachine/kibana that referenced this issue Nov 11, 2024
…lastic#191116)

## Summary

This PR introduces test plans for both [Prebuilt Rule
Import](elastic#180168) (corresponding
[PR](elastic#190198)) and [Prebuilt Rule
Export](elastic#180167) (corresponding
[PR](elastic#194498)). Import is
considerably more complicated as it is calculating new values (for
`rule_source`, `immutable`), while the export work is mainly removing
existing restrictions (which allowed only custom rules to be exported).

---------

Co-authored-by: Elastic Machine <[email protected]>
(cherry picked from commit e429849)
kibanamachine added a commit that referenced this issue Nov 11, 2024
…ort (#191116) (#199716)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[Security Solution] Test plans for prebuilt rule import and export
(#191116)](#191116)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ryland
Herrick","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-11T21:01:46Z","message":"[Security
Solution] Test plans for prebuilt rule import and export (#191116)\n\n##
Summary\r\n\r\nThis PR introduces test plans for both [Prebuilt
Rule\r\nImport](#180168)
(corresponding\r\n[PR](#190198))
and [Prebuilt
Rule\r\nExport](#180167)
(corresponding\r\n[PR](#194498)).
Import is\r\nconsiderably more complicated as it is calculating new
values (for\r\n`rule_source`, `immutable`), while the export work is
mainly removing\r\nexisting restrictions (which allowed only custom
rules to be exported).\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic
Machine
<[email protected]>","sha":"e4298492b5e48338396618d51168ea3e8427c103","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","test-plan","v9.0.0","Team:Detections
and Resp","Team: SecuritySolution","Team:Detection Rule
Management","Feature:Prebuilt Detection
Rules","backport:version","v8.17.0"],"title":"[Security Solution] Test
plans for prebuilt rule import and
export","number":191116,"url":"https://github.com/elastic/kibana/pull/191116","mergeCommit":{"message":"[Security
Solution] Test plans for prebuilt rule import and export (#191116)\n\n##
Summary\r\n\r\nThis PR introduces test plans for both [Prebuilt
Rule\r\nImport](#180168)
(corresponding\r\n[PR](#190198))
and [Prebuilt
Rule\r\nExport](#180167)
(corresponding\r\n[PR](#194498)).
Import is\r\nconsiderably more complicated as it is calculating new
values (for\r\n`rule_source`, `immutable`), while the export work is
mainly removing\r\nexisting restrictions (which allowed only custom
rules to be exported).\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic
Machine
<[email protected]>","sha":"e4298492b5e48338396618d51168ea3e8427c103"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/191116","number":191116,"mergeCommit":{"message":"[Security
Solution] Test plans for prebuilt rule import and export (#191116)\n\n##
Summary\r\n\r\nThis PR introduces test plans for both [Prebuilt
Rule\r\nImport](#180168)
(corresponding\r\n[PR](#190198))
and [Prebuilt
Rule\r\nExport](#180167)
(corresponding\r\n[PR](#194498)).
Import is\r\nconsiderably more complicated as it is calculating new
values (for\r\n`rule_source`, `immutable`), while the export work is
mainly removing\r\nexisting restrictions (which allowed only custom
rules to be exported).\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic
Machine
<[email protected]>","sha":"e4298492b5e48338396618d51168ea3e8427c103"}},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ryland Herrick <[email protected]>
tkajtoch pushed a commit to tkajtoch/kibana that referenced this issue Nov 12, 2024
…lastic#191116)

## Summary

This PR introduces test plans for both [Prebuilt Rule
Import](elastic#180168) (corresponding
[PR](elastic#190198)) and [Prebuilt Rule
Export](elastic#180167) (corresponding
[PR](elastic#194498)). Import is
considerably more complicated as it is calculating new values (for
`rule_source`, `immutable`), while the export work is mainly removing
existing restrictions (which allowed only custom rules to be exported).

---------

Co-authored-by: Elastic Machine <[email protected]>
CAWilson94 pushed a commit to CAWilson94/kibana that referenced this issue Nov 18, 2024
…lastic#191116)

## Summary

This PR introduces test plans for both [Prebuilt Rule
Import](elastic#180168) (corresponding
[PR](elastic#190198)) and [Prebuilt Rule
Export](elastic#180167) (corresponding
[PR](elastic#194498)). Import is
considerably more complicated as it is calculating new values (for
`rule_source`, `immutable`), while the export work is mainly removing
existing restrictions (which allowed only custom rules to be exported).

---------

Co-authored-by: Elastic Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.17 candidate enhancement New value added to drive a business result Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area 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.
Projects
None yet
Development

No branches or pull requests

4 participants