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.

Sign up for GitHub

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

Jump to bottom

[Security Solution] fix from-to values investigate in timeline pulled from timestamp instead of @timestamp field #156884

Merged
merged 1 commit into from May 8, 2023
Merged

[Security Solution] fix from-to values investigate in timeline pulled from timestamp instead of @timestamp field #156884

merged 1 commit into from May 8, 2023

Conversation

PhilippeOberti
Copy link
Contributor

@PhilippeOberti PhilippeOberti commented May 5, 2023 •
edited by kibanamachine

Summary

In Kibana 8.8 we've done a huge refactor of the alert table (see PR).
The new table's trigger actions are no longer some of the Security Solution server side methods that were adding a timestamp field to the response (see here). That timestamp field was basically a duplication of the @timestamp field (done via this helper function)

Running the stack locally, you would see that clicking on the Investigate in timeline icon button or ANY alerts in the alerts table (pretty new or months/years old) would bring the timeline flyout with always the to value being the current date, and the from value being the current date - kibana.alert.rule.from.
The timetamp field here does not exists, so we always fall back to new Date() (unless you're looking at an alert generated by a threshold rule, a new terms rule or a suppressed alert).

This PR fixes the issue by retrieving the @timestamp field instead of the unwanted timestamp field.

More work will be done in the future to actually entirely remove and cleanup the timestamp field (see this WIP ticket).

Checklist

Before (recorded on May 4th and we're looking at an alert generated on May 3rd)

Screen.Recording.2023-05-04.at.4.57.07.PM.mov

After

Screen.Recording.2023-05-04.at.4.58.06.PM.mov

Closes #126077

@PhilippeOberti PhilippeOberti requested review from a team as code owners May 5, 2023 16:06
@PhilippeOberti PhilippeOberti added Team:Threat Hunting Security Solution Threat Hunting Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Threat Hunting:Investigations Security Solution Investigations Team v7.17.2 v8.8.1 labels May 5, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

@elasticmachine
Copy link
Contributor

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

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Security Solution Tests #3 / timeline flyout button the (+) button popover menu owns focus

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
securitySolution 9.1MB 9.1MB -24.0B
Unknown metric groups

ESLint disabled line counts

id before after diff
enterpriseSearch 19 21 +2
securitySolution 398 401 +3
total +5

Total ESLint disabled count

id before after diff
enterpriseSearch 20 22 +2
securitySolution 478 481 +3
total +5

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

michaelolo24
michaelolo24 approved these changes May 8, 2023
View reviewed changes
Copy link
Contributor

@michaelolo24 michaelolo24 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 fixing, works great, thanks!

@michaelolo24 michaelolo24 merged commit 114c98d into main May 8, 2023
34 checks passed
@michaelolo24 michaelolo24 deleted the alerts-investigate-timeline-from-to branch May 8, 2023 23:44
@kibanamachine kibanamachine mentioned this pull request May 8, 2023
Merged
kibanamachine pushed a commit to kibanamachine/kibana that referenced this pull request May 8, 2023
@PhilippeOberti
[Security Solution] fix from-to values investigate in timeline pulled…
52cfb47 
… from timestamp instead of @timestamp field (elastic#156884)

## Summary

In Kibana 8.8 we've done a huge refactor of the alert table (see
[PR](elastic#149128)).
The new table's trigger actions are no longer some of the Security
Solution server side methods that were adding a `timestamp` field to the
response (see
[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/format_timeline_data.ts#L28)).
That `timestamp` field was basically a duplication of the `@timestamp`
field (done via [this helper
function](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/get_timestamp.ts#L12))

Running the stack locally, you would see that clicking on the
`Investigate in timeline` icon button or ANY alerts in the alerts table
(pretty new or months/years old) would bring the timeline flyout with
always the `to` value being the `current date`, and the `from` value
being the `current date - kibana.alert.rule.from`.
The `timetamp` field
[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/detections/components/alerts_table/actions.tsx#L158)
does not exists, so we always fall back to `new Date()` (unless you're
looking at an alert generated by a threshold rule, a new terms rule or a
suppressed alert).

This PR fixes the issue by retrieving the `@timestamp` field instead of
the unwanted `timestamp` field.

More work will be done in the future to actually entirely remove and
cleanup the `timestamp` field (see [this WIP
ticket](elastic#156879)).

### Checklist

- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

Before (recorded on May 4th and we're looking at an alert generated on
May 3rd)

https://user-images.githubusercontent.com/17276605/236509848-a5b0a363-c9c5-4d80-a139-84e3df3a1bd6.mov

After

https://user-images.githubusercontent.com/17276605/236509884-74805cef-ccf2-4b09-a174-2fcb6b75d4bb.mov

Closes elastic#126077

(cherry picked from commit 114c98d)
@kibanamachine
Copy link
Contributor

💚 All backports created successfully

Status Branch Result
✅ 8.8

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

kibanamachine added a commit that referenced this pull request May 9, 2023
@kibanamachine @PhilippeOberti
[8.8] [Security Solution] fix from-to values investigate in timeline …
26c3fbe 
…pulled from timestamp instead of @timestamp field (#156884) (#157114)

# Backport

This will backport the following commits from `main` to `8.8`:
- [[Security Solution] fix from-to values investigate in timeline pulled
from timestamp instead of @timestamp field
(#156884)](#156884)

<!--- Backport version: 8.9.7 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Philippe
Oberti","email":"philippe.oberti@elastic.co"},"sourceCommit":{"committedDate":"2023-05-08T23:44:14Z","message":"[Security
Solution] fix from-to values investigate in timeline pulled from
timestamp instead of @timestamp field (#156884)\n\n## Summary\r\n\r\nIn
Kibana 8.8 we've done a huge refactor of the alert table
(see\r\n[PR](#149128 new
table's trigger actions are no longer some of the Security\r\nSolution
server side methods that were adding a `timestamp` field to
the\r\nresponse
(see\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/format_timeline_data.ts#L28)).\r\nThat
`timestamp` field was basically a duplication of the
`@timestamp`\r\nfield (done via [this
helper\r\nfunction](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/get_timestamp.ts#L12))\r\n\r\nRunning
the stack locally, you would see that clicking on the\r\n`Investigate in
timeline` icon button or ANY alerts in the alerts table\r\n(pretty new
or months/years old) would bring the timeline flyout with\r\nalways the
`to` value being the `current date`, and the `from` value\r\nbeing the
`current date - kibana.alert.rule.from`.\r\nThe `timetamp`
field\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/detections/components/alerts_table/actions.tsx#L158)\r\ndoes
not exists, so we always fall back to `new Date()` (unless
you're\r\nlooking at an alert generated by a threshold rule, a new terms
rule or a\r\nsuppressed alert).\r\n\r\nThis PR fixes the issue by
retrieving the `@timestamp` field instead of\r\nthe unwanted `timestamp`
field.\r\n\r\nMore work will be done in the future to actually entirely
remove and\r\ncleanup the `timestamp` field (see [this
WIP\r\nticket](#156879
Checklist\r\n\r\n- [ ] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\nBefore
(recorded on May 4th and we're looking at an alert generated on\r\nMay
3rd)\r\n\r\n\r\nhttps://user-images.githubusercontent.com/17276605/236509848-a5b0a363-c9c5-4d80-a139-84e3df3a1bd6.mov\r\n\r\nAfter\r\n\r\n\r\nhttps://user-images.githubusercontent.com/17276605/236509884-74805cef-ccf2-4b09-a174-2fcb6b75d4bb.mov\r\n\r\nCloses
#126077
Hunting","Team: SecuritySolution","Team:Threat
Hunting:Investigations","v8.8.0","v8.9.0"],"number":156884,"url":"#156884
Solution] fix from-to values investigate in timeline pulled from
timestamp instead of @timestamp field (#156884)\n\n## Summary\r\n\r\nIn
Kibana 8.8 we've done a huge refactor of the alert table
(see\r\n[PR](#149128 new
table's trigger actions are no longer some of the Security\r\nSolution
server side methods that were adding a `timestamp` field to
the\r\nresponse
(see\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/format_timeline_data.ts#L28)).\r\nThat
`timestamp` field was basically a duplication of the
`@timestamp`\r\nfield (done via [this
helper\r\nfunction](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/get_timestamp.ts#L12))\r\n\r\nRunning
the stack locally, you would see that clicking on the\r\n`Investigate in
timeline` icon button or ANY alerts in the alerts table\r\n(pretty new
or months/years old) would bring the timeline flyout with\r\nalways the
`to` value being the `current date`, and the `from` value\r\nbeing the
`current date - kibana.alert.rule.from`.\r\nThe `timetamp`
field\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/detections/components/alerts_table/actions.tsx#L158)\r\ndoes
not exists, so we always fall back to `new Date()` (unless
you're\r\nlooking at an alert generated by a threshold rule, a new terms
rule or a\r\nsuppressed alert).\r\n\r\nThis PR fixes the issue by
retrieving the `@timestamp` field instead of\r\nthe unwanted `timestamp`
field.\r\n\r\nMore work will be done in the future to actually entirely
remove and\r\ncleanup the `timestamp` field (see [this
WIP\r\nticket](#156879
Checklist\r\n\r\n- [ ] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\nBefore
(recorded on May 4th and we're looking at an alert generated on\r\nMay
3rd)\r\n\r\n\r\nhttps://user-images.githubusercontent.com/17276605/236509848-a5b0a363-c9c5-4d80-a139-84e3df3a1bd6.mov\r\n\r\nAfter\r\n\r\n\r\nhttps://user-images.githubusercontent.com/17276605/236509884-74805cef-ccf2-4b09-a174-2fcb6b75d4bb.mov\r\n\r\nCloses
#126077
Solution] fix from-to values investigate in timeline pulled from
timestamp instead of @timestamp field (#156884)\n\n## Summary\r\n\r\nIn
Kibana 8.8 we've done a huge refactor of the alert table
(see\r\n[PR](#149128 new
table's trigger actions are no longer some of the Security\r\nSolution
server side methods that were adding a `timestamp` field to
the\r\nresponse
(see\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/format_timeline_data.ts#L28)).\r\nThat
`timestamp` field was basically a duplication of the
`@timestamp`\r\nfield (done via [this
helper\r\nfunction](https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/server/search_strategy/timeline/factory/helpers/get_timestamp.ts#L12))\r\n\r\nRunning
the stack locally, you would see that clicking on the\r\n`Investigate in
timeline` icon button or ANY alerts in the alerts table\r\n(pretty new
or months/years old) would bring the timeline flyout with\r\nalways the
`to` value being the `current date`, and the `from` value\r\nbeing the
`current date - kibana.alert.rule.from`.\r\nThe `timetamp`
field\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/detections/components/alerts_table/actions.tsx#L158)\r\ndoes
not exists, so we always fall back to `new Date()` (unless
you're\r\nlooking at an alert generated by a threshold rule, a new terms
rule or a\r\nsuppressed alert).\r\n\r\nThis PR fixes the issue by
retrieving the `@timestamp` field instead of\r\nthe unwanted `timestamp`
field.\r\n\r\nMore work will be done in the future to actually entirely
remove and\r\ncleanup the `timestamp` field (see [this
WIP\r\nticket](#156879
Checklist\r\n\r\n- [ ] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\nBefore
(recorded on May 4th and we're looking at an alert generated on\r\nMay
3rd)\r\n\r\n\r\nhttps://user-images.githubusercontent.com/17276605/236509848-a5b0a363-c9c5-4d80-a139-84e3df3a1bd6.mov\r\n\r\nAfter\r\n\r\n\r\nhttps://user-images.githubusercontent.com/17276605/236509884-74805cef-ccf2-4b09-a174-2fcb6b75d4bb.mov\r\n\r\nCloses
#126077"}}]}]
BACKPORT-->

Co-authored-by: Philippe Oberti <philippe.oberti@elastic.co>
@PhilippeOberti PhilippeOberti mentioned this pull request Jun 26, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@michaelolo24 michaelolo24 michaelolo24 approved these changes

Assignees
No one assigned
Labels
release_note:fix Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Threat Hunting:Investigations Security Solution Investigations Team Team:Threat Hunting Security Solution Threat Hunting Team v8.8.0 v8.9.0
Projects
None yet
Milestone
No milestone
5 participants
@PhilippeOberti @elasticmachine @kibana-ci @kibanamachine @michaelolo24