[Security Solution] Remove extra rule fields from kibana.alert.rule #121135
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
marshallmain
force-pushed
the
remove-extra-rule-fields
branch
from
4b752ff to
c929144
Compare
marshallmain
added
auto-backport
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
kqualters-elastic
approved these changes
Dec 17, 2021
💔 Backport failed
To backport manually run: |
marshallmain
added a commit
to marshallmain/kibana
that referenced
this pull request
Dec 17, 2021
…lastic#121135) * Remove kibana.alert.rule.risk_score and severity * Fix tests related to risk_score and severity * Make translation a template * Can't use expression in template literal * Remove commented line added by bad merge * Fix linting Co-authored-by: Kibana Machine <[email protected]> # Conflicts: # x-pack/plugins/security_solution/public/common/components/event_details/overview/__snapshots__/index.test.tsx.snap # x-pack/plugins/security_solution/public/common/components/event_details/overview/index.test.tsx # x-pack/plugins/security_solution/public/common/components/event_details/overview/index.tsx # x-pack/plugins/security_solution/public/detections/configurations/examples/observablity_alerts/render_cell_value.tsx # x-pack/plugins/security_solution/public/detections/configurations/examples/security_solution_rac/render_cell_value.tsx # x-pack/plugins/timelines/server/search_strategy/timeline/factory/events/all/constants.ts
marshallmain
added a commit
that referenced
this pull request
Dec 17, 2021
…121135) (#121571) * Remove kibana.alert.rule.risk_score and severity * Fix tests related to risk_score and severity * Make translation a template * Can't use expression in template literal * Remove commented line added by bad merge * Fix linting Co-authored-by: Kibana Machine <[email protected]> # Conflicts: # x-pack/plugins/security_solution/public/common/components/event_details/overview/__snapshots__/index.test.tsx.snap # x-pack/plugins/security_solution/public/common/components/event_details/overview/index.test.tsx # x-pack/plugins/security_solution/public/common/components/event_details/overview/index.tsx # x-pack/plugins/security_solution/public/detections/configurations/examples/observablity_alerts/render_cell_value.tsx # x-pack/plugins/security_solution/public/detections/configurations/examples/security_solution_rac/render_cell_value.tsx # x-pack/plugins/timelines/server/search_strategy/timeline/factory/events/all/constants.ts
This was referenced Dec 18, 2021
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this pull request
Dec 18, 2021
…edux) This PR contains the same fixes described below from elastic#121562 , but doesn't depend on the following constants deleted from `@kbn/rule-data-utils` by elastic#121135 ``` ALERT_RULE_RISK_SCORE ALERT_RULE_RISK_SCORE_MAPPING ALERT_RULE_SEVERITY ALERT_RULE_SEVERITY_MAPPING ``` This PR fixes the following issues with the Raw events Top N view: - Fixes an issue <elastic#121168> where the Sourcerer context included detection alerts in the Raw events view, per the before screenshot below: ### Before  _Above: Before - the Raw events view includes detection alerts_ ### After  _Above: After - The Raw events view does NOT include detection alerts_ - Fixes an issue <elastic#121381> where when inspecting Raw events, `Sorry about that, something went wrong` is displayed when the Sourcerer context does not match the current selection: ### Before  _Above: Before - When users `Inspect` the Raw events view, `Sorry about that, something went wrong` is displayed_ ### After  _Above: After - When users `Inspect` the raw events view, the expected Index pattern reflects the current Sourcerer selection_ - Fixes an issue where the following filters in the `Security > Alerts` and `Security > Rule > Details` views: - `kibana.alert.building_block_type`: an "Additional filters" option on the alerts table - `kibana.alert.rule.rule_id`: filters alerts to a single rule on the `Security > Rules > Details` views - `kibana.alert.rule.name`: not a built-in view filter, but frequently applied via the `Filter In` and `Filter Out` actions - `kibana.alert.rule.threat_mapping`: an "Additional filters" option on the alerts table - `kibana.alert.workflow_status`: The `open | acknowledged | closed` status filter were incorrectly applied to the Raw events view, per the screenshots below: ### Before Inspecting the Raw events query reveals the alert filters are applied as filter criteria, per the screenshot below:  _Above: Before - The alert filters are applied to the Raw events view_ ### After After the fix, the alert filters are NOT applied to the raw events view, per the screenshot below:  _Above: After - The alert filters are NOT applied to the Raw events view_
andrew-goldstein
added a commit
that referenced
this pull request
Dec 20, 2021
…x) (#121590) ## [Security Solution] Fixes issues with the Raw events Top N view (redux) This PR contains the same fixes described below from #121562 , but doesn't depend on the following constants deleted from `@kbn/rule-data-utils` by #121135 ``` ALERT_RULE_RISK_SCORE ALERT_RULE_RISK_SCORE_MAPPING ALERT_RULE_SEVERITY ALERT_RULE_SEVERITY_MAPPING ``` This PR fixes the following issues with the Raw events Top N view: - Fixes an issue <#121168> where the Sourcerer context included detection alerts in the Raw events view, per the before screenshot below: ### Before  _Above: Before - the Raw events view includes detection alerts_ ### After  _Above: After - The Raw events view does NOT include detection alerts_ - Fixes an issue <#121381> where when inspecting Raw events, `Sorry about that, something went wrong` is displayed when the Sourcerer context does not match the current selection: ### Before  _Above: Before - When users `Inspect` the Raw events view, `Sorry about that, something went wrong` is displayed_ ### After  _Above: After - When users `Inspect` the raw events view, the expected Index pattern reflects the current Sourcerer selection_ - Fixes an issue where the following filters in the `Security > Alerts` and `Security > Rule > Details` views: - `kibana.alert.building_block_type`: an "Additional filters" option on the alerts table - `kibana.alert.rule.rule_id`: filters alerts to a single rule on the `Security > Rules > Details` views - `kibana.alert.rule.name`: not a built-in view filter, but frequently applied via the `Filter In` and `Filter Out` actions - `kibana.alert.rule.threat_mapping`: an "Additional filters" option on the alerts table - `kibana.alert.workflow_status`: The `open | acknowledged | closed` status filter were incorrectly applied to the Raw events view, per the screenshots below: ### Before Inspecting the Raw events query reveals the alert filters are applied as filter criteria, per the screenshot below:  _Above: Before - The alert filters are applied to the Raw events view_ ### After After the fix, the alert filters are NOT applied to the raw events view, per the screenshot below:  _Above: After - The alert filters are NOT applied to the Raw events view_
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Dec 20, 2021
…x) (elastic#121590) ## [Security Solution] Fixes issues with the Raw events Top N view (redux) This PR contains the same fixes described below from elastic#121562 , but doesn't depend on the following constants deleted from `@kbn/rule-data-utils` by elastic#121135 ``` ALERT_RULE_RISK_SCORE ALERT_RULE_RISK_SCORE_MAPPING ALERT_RULE_SEVERITY ALERT_RULE_SEVERITY_MAPPING ``` This PR fixes the following issues with the Raw events Top N view: - Fixes an issue <elastic#121168> where the Sourcerer context included detection alerts in the Raw events view, per the before screenshot below: ### Before  _Above: Before - the Raw events view includes detection alerts_ ### After  _Above: After - The Raw events view does NOT include detection alerts_ - Fixes an issue <elastic#121381> where when inspecting Raw events, `Sorry about that, something went wrong` is displayed when the Sourcerer context does not match the current selection: ### Before  _Above: Before - When users `Inspect` the Raw events view, `Sorry about that, something went wrong` is displayed_ ### After  _Above: After - When users `Inspect` the raw events view, the expected Index pattern reflects the current Sourcerer selection_ - Fixes an issue where the following filters in the `Security > Alerts` and `Security > Rule > Details` views: - `kibana.alert.building_block_type`: an "Additional filters" option on the alerts table - `kibana.alert.rule.rule_id`: filters alerts to a single rule on the `Security > Rules > Details` views - `kibana.alert.rule.name`: not a built-in view filter, but frequently applied via the `Filter In` and `Filter Out` actions - `kibana.alert.rule.threat_mapping`: an "Additional filters" option on the alerts table - `kibana.alert.workflow_status`: The `open | acknowledged | closed` status filter were incorrectly applied to the Raw events view, per the screenshots below: ### Before Inspecting the Raw events query reveals the alert filters are applied as filter criteria, per the screenshot below:  _Above: Before - The alert filters are applied to the Raw events view_ ### After After the fix, the alert filters are NOT applied to the raw events view, per the screenshot below:  _Above: After - The alert filters are NOT applied to the Raw events view_
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this pull request
Dec 20, 2021
…x) (elastic#121590) ## [Security Solution] Fixes issues with the Raw events Top N view (redux) This PR contains the same fixes described below from elastic#121562 , but doesn't depend on the following constants deleted from `@kbn/rule-data-utils` by elastic#121135 ``` ALERT_RULE_RISK_SCORE ALERT_RULE_RISK_SCORE_MAPPING ALERT_RULE_SEVERITY ALERT_RULE_SEVERITY_MAPPING ``` This PR fixes the following issues with the Raw events Top N view: - Fixes an issue <elastic#121168> where the Sourcerer context included detection alerts in the Raw events view, per the before screenshot below: ### Before  _Above: Before - the Raw events view includes detection alerts_ ### After  _Above: After - The Raw events view does NOT include detection alerts_ - Fixes an issue <elastic#121381> where when inspecting Raw events, `Sorry about that, something went wrong` is displayed when the Sourcerer context does not match the current selection: ### Before  _Above: Before - When users `Inspect` the Raw events view, `Sorry about that, something went wrong` is displayed_ ### After  _Above: After - When users `Inspect` the raw events view, the expected Index pattern reflects the current Sourcerer selection_ - Fixes an issue where the following filters in the `Security > Alerts` and `Security > Rule > Details` views: - `kibana.alert.building_block_type`: an "Additional filters" option on the alerts table - `kibana.alert.rule.rule_id`: filters alerts to a single rule on the `Security > Rules > Details` views - `kibana.alert.rule.name`: not a built-in view filter, but frequently applied via the `Filter In` and `Filter Out` actions - `kibana.alert.rule.threat_mapping`: an "Additional filters" option on the alerts table - `kibana.alert.workflow_status`: The `open | acknowledged | closed` status filter were incorrectly applied to the Raw events view, per the screenshots below: ### Before Inspecting the Raw events query reveals the alert filters are applied as filter criteria, per the screenshot below:  _Above: Before - The alert filters are applied to the Raw events view_ ### After After the fix, the alert filters are NOT applied to the raw events view, per the screenshot below:  _Above: After - The alert filters are NOT applied to the Raw events view_ # Conflicts: # x-pack/plugins/security_solution/public/common/components/top_n/top_n.tsx
kibanamachine
added a commit
that referenced
this pull request
Dec 20, 2021
…x) (#121590) (#121607) ## [Security Solution] Fixes issues with the Raw events Top N view (redux) This PR contains the same fixes described below from #121562 , but doesn't depend on the following constants deleted from `@kbn/rule-data-utils` by #121135 ``` ALERT_RULE_RISK_SCORE ALERT_RULE_RISK_SCORE_MAPPING ALERT_RULE_SEVERITY ALERT_RULE_SEVERITY_MAPPING ``` This PR fixes the following issues with the Raw events Top N view: - Fixes an issue <#121168> where the Sourcerer context included detection alerts in the Raw events view, per the before screenshot below: ### Before  _Above: Before - the Raw events view includes detection alerts_ ### After  _Above: After - The Raw events view does NOT include detection alerts_ - Fixes an issue <#121381> where when inspecting Raw events, `Sorry about that, something went wrong` is displayed when the Sourcerer context does not match the current selection: ### Before  _Above: Before - When users `Inspect` the Raw events view, `Sorry about that, something went wrong` is displayed_ ### After  _Above: After - When users `Inspect` the raw events view, the expected Index pattern reflects the current Sourcerer selection_ - Fixes an issue where the following filters in the `Security > Alerts` and `Security > Rule > Details` views: - `kibana.alert.building_block_type`: an "Additional filters" option on the alerts table - `kibana.alert.rule.rule_id`: filters alerts to a single rule on the `Security > Rules > Details` views - `kibana.alert.rule.name`: not a built-in view filter, but frequently applied via the `Filter In` and `Filter Out` actions - `kibana.alert.rule.threat_mapping`: an "Additional filters" option on the alerts table - `kibana.alert.workflow_status`: The `open | acknowledged | closed` status filter were incorrectly applied to the Raw events view, per the screenshots below: ### Before Inspecting the Raw events query reveals the alert filters are applied as filter criteria, per the screenshot below:  _Above: Before - The alert filters are applied to the Raw events view_ ### After After the fix, the alert filters are NOT applied to the raw events view, per the screenshot below:  _Above: After - The alert filters are NOT applied to the Raw events view_ Co-authored-by: Andrew Goldstein <[email protected]>
andrew-goldstein
added a commit
that referenced
this pull request
Dec 20, 2021
…x) (#121590) (#121608) ## [Security Solution] Fixes issues with the Raw events Top N view (redux) This PR contains the same fixes described below from #121562 , but doesn't depend on the following constants deleted from `@kbn/rule-data-utils` by #121135 ``` ALERT_RULE_RISK_SCORE ALERT_RULE_RISK_SCORE_MAPPING ALERT_RULE_SEVERITY ALERT_RULE_SEVERITY_MAPPING ``` This PR fixes the following issues with the Raw events Top N view: - Fixes an issue <#121168> where the Sourcerer context included detection alerts in the Raw events view, per the before screenshot below: ### Before  _Above: Before - the Raw events view includes detection alerts_ ### After  _Above: After - The Raw events view does NOT include detection alerts_ - Fixes an issue <#121381> where when inspecting Raw events, `Sorry about that, something went wrong` is displayed when the Sourcerer context does not match the current selection: ### Before  _Above: Before - When users `Inspect` the Raw events view, `Sorry about that, something went wrong` is displayed_ ### After  _Above: After - When users `Inspect` the raw events view, the expected Index pattern reflects the current Sourcerer selection_ - Fixes an issue where the following filters in the `Security > Alerts` and `Security > Rule > Details` views: - `kibana.alert.building_block_type`: an "Additional filters" option on the alerts table - `kibana.alert.rule.rule_id`: filters alerts to a single rule on the `Security > Rules > Details` views - `kibana.alert.rule.name`: not a built-in view filter, but frequently applied via the `Filter In` and `Filter Out` actions - `kibana.alert.rule.threat_mapping`: an "Additional filters" option on the alerts table - `kibana.alert.workflow_status`: The `open | acknowledged | closed` status filter were incorrectly applied to the Raw events view, per the screenshots below: ### Before Inspecting the Raw events query reveals the alert filters are applied as filter criteria, per the screenshot below:  _Above: Before - The alert filters are applied to the Raw events view_ ### After After the fix, the alert filters are NOT applied to the raw events view, per the screenshot below:  _Above: After - The alert filters are NOT applied to the Raw events view_ # Conflicts: # x-pack/plugins/security_solution/public/common/components/top_n/top_n.tsx
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
kibana.alert.rule.risk_scoreandkibana.alert.rule.severitywere used to store the static defaultrisk_scoreandseverityvalues associated with a rule. Now thatkibana.alert.rule.parameterscontains all the rule parameters, we don't need separate fields to store the default values from the rule. It's important to remove these fields before we ship in 8.0 since we can't remove fields from existing mappings later on.kibana.alert.risk_scoreandkibana.alert.severitystill contain therisk_scoreandseverityvalues for the specific alert document. These values may be different from the default values on the rule ifrisk_score_mappingorseverity_mappingparameters are used, as those mappings define overrides for risk score and severity based on fields found in the alert document.In general, when displaying risk score and severity values throughout the app, we'll want to use
kibana.alert.risk_scoreandkibana.alert.severitymoving forward.