fix: Cleaning up the hashable content for the rule

[traut]

Pull Request

Issue link(s):

Summary - What I changed

• related_integrations field will be dropped from the dict that will be hashed to calculate the SHA256 hash of the rule.

How To Test

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[shashank-elastic]

When we ship this, all integrations will invariably get a version bump because the sha256 would change with dropping the related_integrations and the first time all of the integrations rules will see a bump.

[shashank-elastic]

We can use python -m detection_rules dev test-version-lock main to test this logic change

[Mikaayenson]

• Calculating both hashes to preserve backwards compatibility makes sense so im not sure where it's still bumping hashes in your testing. just remember, It may be legitimate rule changes.
• We should also think about how expensive the extra call (and to go one step further, even if we want to make adding related integrations optional at all) or just remove the field from calculation all together
• We'll want to make sure we refactor the other areas of sha256() in the test cases

[shashank-elastic]

Testing Updates During Release part

• We patched the code to 8.18 and 9.0 branches locally and tested lock versions

• We ran this command on 8.18 and 9.0 python -m detection_rules dev build-release --update-version-lock

• The resulting lock versions file was diffed with main to Identify double bumps

• We never double bumps due to integration changes at all and identified 4 double bumps during testing for rules
  - Windows Event Logs Cleared
  - User Added to Privileged Group
  - Active Directory Group Modification by SYSTEM
  - Execution of a Downloaded Windows Script

  • All the above rules have to be minstacked.

  Attaching the same diff of version lock file with main and the version lock file when tested.

git_diff_output.txt
version.lock.json

[github-actions]

Enhancement - Guidelines

These guidelines serve as a reminder set of considerations when addressing adding a feature to the code.

Documentation and Context

• Describe the feature enhancement in detail (alternative solutions, description of the solution, etc.) if not already documented in an issue.
• Include additional context or screenshots.
• Ensure the enhancement includes necessary updates to the documentation and versioning.

Code Standards and Practices

• Code follows established design patterns within the repo and avoids duplication.
• Code changes do not introduce new warnings or errors.
• Variables and functions are well-named and descriptive.
• Any unnecessary / commented-out code is removed.
• Ensure that the code is modular and reusable where applicable.
• Check for proper exception handling and messaging.

Testing

• New unit tests have been added to cover the enhancement.
• Existing unit tests have been updated to reflect the changes.
• Provide evidence of testing and validating the enhancement (e.g., test logs, screenshots).
• Validate that any rules affected by the enhancement are correctly updated.
• Ensure that performance is not negatively impacted by the changes.
• Verify that any release artifacts are properly generated and tested.

Additional Checks

• Ensure that the enhancement does not break existing functionality.
• Review the enhancement with a peer or team member for additional insights.
• Verify that the enhancement works across all relevant environments (e.g., different OS versions).
• Confirm that all dependencies are up-to-date and compatible with the changes.
• Confirm that the proper version label is applied to the PR patch, minor, major.

[Mikaayenson]

this lgtm based on all the local release branch testing. @traut when we merge, can we time a maintenance window and test version locks? If anything unexpected arises, we can safely revert this PR then. Note: @eric-forte-elastic is also bringing in a version lock PR that will test inadvertent double bumps so we could merge this one after his.