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] Implement isCustomized calculation #186988

Merged
merged 1 commit into from
Jul 9, 2024

Conversation

xcrzx
Copy link
Contributor

@xcrzx xcrzx commented Jun 26, 2024

Resolves: #180145
Resolves: #184364

Note

This PR doesn't include isCustomized recalculation when bulk editing rules. This should be addressed separately as it might require first changing the RulesClient.bulkEdit method signature.

Summary

This PR implements the calculation of ruleSource.isCustomized inside the DetectionRulesClient. The recalculation of the isCustomized field is performed on every rule patch and update operation, including rule upgrades. See the ticket for more information: #180145 and detection_rules_client/mergers/rule_source/calculate_is_customized.ts for implementation details.

The isCustomized calculation is based on the calculateRuleFieldsDiff method used inside the prebuilt rules domain for calculating changed fields during rule upgrades. This ensures that the diff calculation logic is unified and reused to avoid any discrepancies in different paths of rule management.

The recalculation and saving of the field is done in the following endpoints:

  • Update Rule - PUT /rules
  • Patch Rule - PATCH /rules
  • Bulk Update Rules - PUT /rules/_bulk_update
  • Bulk Patch Rules - PATCH /rules/_bulk_update
  • Import Rules - POST /rules/_import
  • Perform Rule Upgrade - POST /prebuilt_rules/upgrade/_perform

This PR also partially addresses refactoring mentioned here: #184364. Namely:

  • Splits the rule converters into smaller single-responsibility functions.
    • Separate methods to convert RuleResponse to AlertingRule and back
    • Separate methods to apply rule patches, updates, or set defaults
    • Separate case converters
  • Migrates methods to work with RuleResponse instead of alerting type wherever possible.
  • Adds new methods for fetching rules by id or rule id and deprecates the readRules. Although new methods are not exposed yet in the public client interface, this is something that needs to be addressed separately.

@xcrzx xcrzx self-assigned this Jun 26, 2024
@xcrzx xcrzx requested review from a team as code owners June 26, 2024 13:53
@xcrzx xcrzx requested review from e40pud and dplumlee June 26, 2024 13:53
@xcrzx xcrzx marked this pull request as draft June 26, 2024 13:53
@xcrzx xcrzx force-pushed the is-customized branch 10 times, most recently from 9805884 to 1e1fbea Compare July 3, 2024 09:31
@elastic elastic deleted a comment from kibana-ci Jul 3, 2024
Copy link
Contributor

@dhurley14 dhurley14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Holding until we can better understand how to resolve expected code conflicts brought up here: #183937 (review)

cc: @jpdjere

@xcrzx
Copy link
Contributor Author

xcrzx commented Jul 3, 2024

Holding until we can better understand how to resolve expected code conflicts brought up here: #183937 (review)

cc: @jpdjere

Hey @dhurley14, the rule customization epic is a super high priority right now. It would be great if you don't hold this PR for too long.

cc @banderror @peluja1012

@dhurley14
Copy link
Contributor

I agree, it would be great if we don't hold up these PR's for too long. You have done a lot of work to determine how best to migrate the logic from the rule converter code into the separate areas you created here. Considering this, you have the best knowledge for determining how, after the system actions code is merged, those changes can then also be added into the new files you created to maintain parity, as you have already done.

I think we can both work together to determine the best path forward to reduce code conflicts.

@dhurley14
Copy link
Contributor

Mentioned it here but posting for posterity, please let me know how I can make changes to my PR to lessen the impact it will have on yours!

@dhurley14 dhurley14 dismissed their stale review July 3, 2024 14:53

setting up a meeting instead

@elastic elastic deleted a comment from elasticmachine Jul 3, 2024
@banderror
Copy link
Contributor

banderror commented Jul 3, 2024

@xcrzx Could you please add a PR description and open it for review? I don't want it to be perceived as a draft / something not very urgent for our team.

@xcrzx xcrzx marked this pull request as ready for review July 3, 2024 16:49
@xcrzx xcrzx added Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area v8.16.0 labels Jul 3, 2024
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

@xcrzx
Copy link
Contributor Author

xcrzx commented Jul 3, 2024

buildkite test this

@elasticmachine
Copy link
Contributor

⏳ Build in-progress, with failures

Failed CI Steps

cc @xcrzx

@banderror banderror requested review from jpdjere and banderror July 4, 2024 08:38
Copy link
Contributor

@jpdjere jpdjere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing my comments, and for the whole refactor! ✅

@banderror banderror removed their request for review July 8, 2024 15:30
@yctercero yctercero requested review from nkhristinin and removed request for e40pud July 8, 2024 15:49
},
});
expect(transformedParams).toEqual(
expect.objectContaining({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we in this type of converters tests for the whole objects and fields present?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit opposed to creating snapshot tests for the whole function output because snapshots have proven to be too flaky without providing any extra quality assurance.

Anyway, this test existed before, and my goal here was not to provide additional test coverage of the existing code. During the refactoring, I transferred the already existing tests to new locations and added new tests only for the newly introduced functionality, like the isCustomized calculation.

const {
hits: {
hits: [{ _source: ruleSO }],
},
} = await getRuleSOById(es, ruleWithLegacyInvestigationField.id);
const isInvestigationFieldMigratedInSo = await checkInvestigationFieldSoValue(ruleSO, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, why this logic was removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, the legacy investigation field migration happens much earlier. With this refactoring, we convert data to our internal representation RuleResponse immediately after reading a rule from RulesClient. This means that instead of transforming the data only before returning it in the response, we transform it as soon as we read it.

This approach ensures that in our API handlers, the data is always in the new format and thus gets migrated on any write or update. This is much more straightforward than migrating the data only on certain writes as before.

@@ -237,6 +239,8 @@ export const previewRulesRoute = (
createdAt: new Date(),
createdBy: username ?? 'preview-created-by',
producer: 'preview-producer',
consumer: SERVER_APP_ID,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this consumer affect behaviour, or it's just type thing here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field was previously added with the convertCreateAPIToInternalSchema function. Now that I have split that function into multiple single-purpose functions, we have to add it manually here. There should be no changes in the resulting rule passed to Alerting.

@xcrzx xcrzx requested a review from nkhristinin July 9, 2024 09:21
Copy link
Contributor

@nkhristinin nkhristinin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@xcrzx xcrzx merged commit 045aafc into elastic:main Jul 9, 2024
40 of 41 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jul 9, 2024
@xcrzx xcrzx deleted the is-customized branch July 10, 2024 12:33
@xcrzx xcrzx restored the is-customized branch July 10, 2024 12:33
@xcrzx xcrzx deleted the is-customized branch July 10, 2024 12:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area release_note:skip Skip the PR/issue when compiling release notes 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.16.0
Projects
None yet
7 participants