-
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] Implement isCustomized calculation #186988
Conversation
9805884
to
1e1fbea
Compare
There was a problem hiding this 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
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. |
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. |
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! |
@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. |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
buildkite test this |
⏳ Build in-progress, with failures
Failed CI Stepscc @xcrzx |
.../rule_management/logic/detection_rules_client/mergers/rule_source/calculate_is_customized.ts
Outdated
Show resolved
Hide resolved
...ver/lib/detection_engine/rule_management/logic/detection_rules_client/methods/import_rule.ts
Outdated
Show resolved
Hide resolved
...b/detection_engine/rule_management/logic/detection_rules_client/mergers/apply_rule_update.ts
Show resolved
Hide resolved
...ib/detection_engine/rule_management/logic/detection_rules_client/mergers/apply_rule_patch.ts
Show resolved
Hide resolved
...ment/logic/detection_rules_client/converters/convert_prebuilt_rule_asset_to_rule_response.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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! ✅
...management/logic/detection_rules_client/converters/convert_rule_response_to_alerting_rule.ts
Outdated
Show resolved
Hide resolved
}, | ||
}); | ||
expect(transformedParams).toEqual( | ||
expect.objectContaining({ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
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 theRulesClient.bulkEdit
method signature.Summary
This PR implements the calculation of
ruleSource.isCustomized
inside theDetectionRulesClient
. The recalculation of theisCustomized
field is performed on every rule patch and update operation, including rule upgrades. See the ticket for more information: #180145 anddetection_rules_client/mergers/rule_source/calculate_is_customized.ts
for implementation details.The
isCustomized
calculation is based on thecalculateRuleFieldsDiff
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:
PUT /rules
PATCH /rules
PUT /rules/_bulk_update
PATCH /rules/_bulk_update
POST /rules/_import
POST /prebuilt_rules/upgrade/_perform
This PR also partially addresses refactoring mentioned here: #184364. Namely:
readRules
. Although new methods are not exposed yet in the public client interface, this is something that needs to be addressed separately.