[Security Solution] Detection alerts are showing in raw events when click on show to modal under alerts page #121168
Assignees
Labels
bug
Fixes for quality problems that affect the customer experience
fixed
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
Team:Threat Hunting:Investigations
Security Solution Investigations Team
v8.0.0
Comments
ghost
added
bug
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
MadameSheema
added
Team:Threat Hunting:Investigations
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this issue
Dec 17, 2021
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 issue
Dec 17, 2021
) ## [Security Solution] Fixes issues with the Raw events Top N view 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 issue
Dec 17, 2021
…tic#121562) ## [Security Solution] Fixes issues with the Raw events Top N view 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 issue
Dec 17, 2021
…tic#121562) ## [Security Solution] Fixes issues with the Raw events Top N view 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
andrew-goldstein
pushed a commit
that referenced
this issue
Dec 18, 2021
) (#121583) ## [Security Solution] Fixes issues with the Raw events Top N view 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_
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this issue
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 issue
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 issue
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 issue
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 issue
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 issue
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
|
Fixed by: |
|
@deepikakeshav-qasource would you be willing to retest per the details above? |
|
Hi @andrew-goldstein , We have validated this ticket on 8.1.0 main branch and 8.0.0 PR. We are unable to test on 7.17. Look like PR has been deleted. Please find the below observations: 8.1.0
Screen-record raw-event.mp48.0.0
Screen-record 8.0.0_raw_events.mp4we will be keeping this issue open for final bug regress on cloud build once the BC build available and will close then. Thanks!! |
|
We have validated this issue on 8.0.0 RC2 and observed that issue is Fixed. 🟢 Please find below testing details: Build Details: Screenshot:
Thanks!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Detection alerts are showing in raw events when click on show to modal under alerts page
Build Details:
Browser Details:
N/A
Preconditions
Steps to Reproduce
Actual Result
Detection alerts are showing in raw events when click on show to modal under alerts page
Expected Result
Correct information should be displayed in raw events.
What's Working
What's Not Working
Screen-Shot
The text was updated successfully, but these errors were encountered: