[Detection Engine] Alert status auditing (kibana.alert.workflow_user and kibana.alert.workflow_status_updated_at)
#4325
Assignees
Comments
6 tasks
marshallmain
added a commit
to elastic/kibana
that referenced
this issue
Dec 5, 2023
This PR populates the existing `kibana.alert.workflow_user` field in the alerts-as-data mappings with the `profile_uid` of the last user to modify the status of the alert. It also adds a new field, `kibana.alert.workflow_status_updated_at`, to track the last time the workflow status was updated and populates it with a timestamp. Similar to the alert assignment PR, `workflow_user` renders in the table with a user avatar instead of the raw `profile_uid` value stored in the alert. The filter in/out buttons on the row cell automatically add a filter that uses the raw value so that filtering works correctly. Due to limitations of Kibana's user profile implementation, `workflow_user` is only populated if a user changes the alert status using the alert status route (`POST /api/detection_engine/signals/status`) within an interactive session, i.e. logs in rather than passes credentials with each API request ([related issue](#167459)). ## Alerts table  ## Alert details  ### Checklist - [ ] Functional changes are hidden behind a feature flag. If not hidden, the PR explains why these changes are being implemented in a long-living feature branch. - [x] Functional changes are covered with a test plan and automated tests. - [x] Stability of new and changed tests is verified using the [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner). - Flaky test run: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4130 - [ ] Comprehensive manual testing is done by two engineers: the PR author and one of the PR reviewers. Changes are tested in both ESS and Serverless. - [x] Mapping changes are accompanied by a technical design document. It can be a GitHub issue or an RFC explaining the changes. The design document is shared with and approved by the appropriate teams and individual stakeholders. - elastic/security-team#4820 - [x] Functional changes are communicated to the Docs team. A ticket or PR is opened in https://github.com/elastic/security-docs. The following information is included: any feature flags used, affected environments (Serverless, ESS, or both). - elastic/security-docs#4325
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
In elastic/kibana#171589, we will start populating
kibana.alert.workflow_userwith the user ID of the last user to update an alert's status (kibana.alert.workflow_status). We'll also start populatingkibana.alert.workflow_status_updated_atwith a timestamp of the last time the alert's status was updated. These columns will not display by default in the alerts table, however, the alert details flyout will show who updated the status last and when even if those columns are not in the table (flyout screenshot in PR).If
kibana.alert.workflow_useris added to the alerts table, it will render as a user avatar, the same as how assigned users display in the table in elastic/kibana#170579. The filter in/out buttons work onkibana.alert.workflow_userin the table, but automatically create a filter based on the underlying profile ID value - not the username/avatar that is rendered in the cell.There should be no differences between Serverless and ESS for this feature. It's slated for release in 8.12 for ESS. We don't know yet exactly when it will be available in Serverless production.
kibana.alert.workflow_useris only populated if the alert status is updated using the UI or through/api/detection_engine/signals/statusas part of an interactive session. If the API is used by providing credentials directly to the API route rather than logging in and using the returned token to authenticate, then the profile ID is not available andkibana.alert.workflow_userwill not be populated.kibana.alert.workflow_status_updated_atis populated any time a user updates alert statuses through the/api/detection_engine/signals/statusAPI, even outside of interactive sessions (i.e. logging in to start a session).There are no privilege changes or license requirements. The fields can be viewed by anyone who can view alerts, and will be populated any time a user updates alert statuses through the API (with the caveats above) or UI.
Acceptance Test Criteria
kibana.alert.workflow_userandkibana.alert.workflow_status_updated_atshould be populated with the correct ID and timestamp, respectivelyNotes
Screenshots
The text was updated successfully, but these errors were encountered: