[Attack discovery] Optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries#225029
Merged
andrew-goldstein merged 11 commits intoelastic:mainfrom Jun 25, 2025
Conversation
andrew-goldstein
added
the
Team: SecuritySolution
andrew-goldstein
added
the
release_note:feature
Contributor
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
Contributor
Author
Files by Code Ownerelastic/obs-ux-management-team
elastic/response-ops
elastic/security-detection-engine
elastic/security-detections-response
elastic/security-generative-ai
elastic/security-solution
|
andrew-goldstein
force-pushed
the
attack_discovery_close_related_alerts
branch
from
7b1d12c to
cdacea7
Compare
shahzad31
approved these changes
Jun 24, 2025
ymao1
approved these changes
Jun 24, 2025
PhilippeOberti
requested changes
Jun 24, 2025
Contributor
PhilippeOberti
left a comment
PhilippeOberti
left a comment
There was a problem hiding this comment.
This is a cool feature! Desk tested and things work nicely!
I left a couple of comments though: unless I'm mistaken, either some code is missing or we can undo the changes in a few files are they are not used anywhere.
If I'm correct and those changes are unused, you won't need approval from the @elastic/security-threat-hunting-investigations team anymore 😄
...ecurity/plugins/security_solution/public/detections/components/alert_summary/table/table.tsx
Show resolved
Hide resolved
...c/attack_discovery/pages/results/attack_discovery_panel/tabs/alerts_tab/ai_for_soc/table.tsx
Show resolved
Hide resolved
...attack_discovery/pages/results/attack_discovery_panel/tabs/alerts_tab/ai_for_soc/wrapper.tsx
Show resolved
Hide resolved
e40pud
approved these changes
Jun 24, 2025
Contributor
e40pud
left a comment
e40pud
left a comment
There was a problem hiding this comment.
Looks great! Thank you for pairing on review and testing it together 🚀
andrew-goldstein
force-pushed
the
attack_discovery_close_related_alerts
branch
2 times, most recently
from
5681b31 to
04d6844
Compare
PhilippeOberti
approved these changes
Jun 24, 2025
Contributor
PhilippeOberti
left a comment
PhilippeOberti
left a comment
There was a problem hiding this comment.
Thanks for undoing the unnecessary changes!
dhurley14
reviewed
Jun 24, 2025
Contributor
dhurley14
left a comment
dhurley14
left a comment
There was a problem hiding this comment.
Fields need to be added to the alert schema for 8.19.
Comment on lines
+74
to
+82
| // kibana.alert.updated_at - timestamp when the alert was last updated | ||
| const ALERT_UPDATED_AT = `${ALERT_NAMESPACE}.updated_at` as const; | ||
|
|
||
| // kibana.alert.updated_by.user.id - user id of the user that last updated the alert | ||
| const ALERT_UPDATED_BY_USER_ID = `${ALERT_NAMESPACE}.updated_by.user.id` as const; | ||
|
|
||
| // kibana.alert.updated_by.user.name - user name of the user that last updated the alert | ||
| const ALERT_UPDATED_BY_USER_NAME = `${ALERT_NAMESPACE}.updated_by.user.name` as const; | ||
|
|
Contributor
There was a problem hiding this comment.
I think these fields should also be added and updated in https://github.com/elastic/kibana/blob/e3976c9c0f53cdeb6b4a8fdd05c9f691b898e120/x-pack/solutions/security/plugins/security_solution/common/api/detection_engine/model/alerts/index.ts if you need them in 8.19.x too.
Contributor
There was a problem hiding this comment.
@andrew-goldstein it looks like we will need to add these common alert fields here
Contributor
Author
There was a problem hiding this comment.
Thank you @dhurley14 and @e40pud!
The new fields were added to x-pack/solutions/security/plugins/security_solution/common/api/detection_engine/model/alerts/8.19.0/index.ts in commit 693ca30
andrew-goldstein
force-pushed
the
attack_discovery_close_related_alerts
branch
2 times, most recently
from
99c834e to
8fd395a
Compare
…schemas/generated/streams_schema.ts` via output from running `node scripts/functional_test_runner --config=x-pack/platform/test/alerting_api_integration/spaces_only/tests/alerting/group4/config.ts --grep "check alert schemas"`
andrew-goldstein
force-pushed
the
attack_discovery_close_related_alerts
branch
from
f43eddd to
ebc1355
Compare
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
|
Contributor
|
Starting backport for target branches: 8.19 https://github.com/elastic/kibana/actions/runs/15864637000 |
Contributor
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
akowalska622
pushed a commit
to akowalska622/kibana
that referenced
this pull request
Jun 25, 2025
…s` of alerts associated with Attack discoveries (elastic#225029) ## [Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries This PR introduces a new UI to optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries, as illustrated by the animated gif below:  Users may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:  When multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:  ### Alert document enhancements Attack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents. To support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields: 1) `kibana.alert.start` - timestamp when Attack discoveries are created 2) `kibana.alert.workflow_status_updated_at` - timestamp when the `kibana.alert.workflow_status` was last updated This PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future: 1) `kibana.alert.updated_at` - timestamp when the alert was last updated 2) `kibana.alert.updated_by.user.id` - user id of the user that last updated the alert 3) `kibana.alert.updated_by.user.name` - user name of the user that last updated the alert The three new alert fields above are updated when Attack discovery users update: - The `kibana.alert.workflow_status` status of Attack discoveries - The visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) The three new fields above were added to the [alert_field_map](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts) and [alert_schema](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/schemas/generated/alert_schema.ts). Using the `default` space as an example, the fields above may be observed in the `.adhoc.alerts-security.attack.discovery.alerts-default` data stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the `.alerts-security.attack.discovery.alerts-default` data stream. ### @timestamp updated when sharing status changes To ensure newly-shared Attack discoveries are bumped to the top of search results, the `@timestamp` field is updated when the visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) is updated. (The original time an Attack discovery was generated is represented by the `kibana.alert.start` field, which is not mutated.) ### Visibility menu changes This PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:  The disabled menu has a tooltip that reads: ``` The visibility of shared discoveries cannot be changed ``` Note: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries. ### `kibana.alert.workflow_status` added to default `Alerts` tab columns The `kibana.alert.workflow_status` field was added to default `Alerts` tab columns, as illustrated by the screenshot below:  ### Summary of field updates The following table describes when fields are updated (via this PR): | Field | Updated when | Description | |-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------| | `kibana.alert.start` | - Attack discoveries are created | timestamp when Attack discoveries are created | | `kibana.alert.workflow_status_updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated | timestamp when `kibana.alert.workflow_status` was last updated | | `kibana.alert.updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | timestamp when the alert was last updated | | `kibana.alert.updated_by.user.id` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user id of the user that last updated the alert | | `kibana.alert.updated_by.user.name` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user name of the user that last updated the alert | | `@timestamp` | - Attack discoveries are created<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | ECS [`@timestamp`](https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp) field | ### Feature flags The _required_ feature flag below is necessary to desk test with Ad hoc attack discoveries. The _recommended_ feature flag below enables testing with scheduled Attack discoveries. ### required: `securitySolution.attackDiscoveryAlertsEnabled` Enable the required `securitySolution.attackDiscoveryAlertsEnabled` feature flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true ``` ### recommended: `securitySolution.assistantAttackDiscoverySchedulingEnabled: true` Also enable the recommended `assistantAttackDiscoverySchedulingEnabled` feature flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ```
2 tasks
andrew-goldstein
added
backport:version
Contributor
|
Starting backport for target branches: 8.19 https://github.com/elastic/kibana/actions/runs/15883285163 |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jun 25, 2025
…s` of alerts associated with Attack discoveries (elastic#225029) ## [Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries This PR introduces a new UI to optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries, as illustrated by the animated gif below:  Users may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:  When multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:  ### Alert document enhancements Attack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents. To support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields: 1) `kibana.alert.start` - timestamp when Attack discoveries are created 2) `kibana.alert.workflow_status_updated_at` - timestamp when the `kibana.alert.workflow_status` was last updated This PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future: 1) `kibana.alert.updated_at` - timestamp when the alert was last updated 2) `kibana.alert.updated_by.user.id` - user id of the user that last updated the alert 3) `kibana.alert.updated_by.user.name` - user name of the user that last updated the alert The three new alert fields above are updated when Attack discovery users update: - The `kibana.alert.workflow_status` status of Attack discoveries - The visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) The three new fields above were added to the [alert_field_map](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts) and [alert_schema](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/schemas/generated/alert_schema.ts). Using the `default` space as an example, the fields above may be observed in the `.adhoc.alerts-security.attack.discovery.alerts-default` data stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the `.alerts-security.attack.discovery.alerts-default` data stream. ### @timestamp updated when sharing status changes To ensure newly-shared Attack discoveries are bumped to the top of search results, the `@timestamp` field is updated when the visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) is updated. (The original time an Attack discovery was generated is represented by the `kibana.alert.start` field, which is not mutated.) ### Visibility menu changes This PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:  The disabled menu has a tooltip that reads: ``` The visibility of shared discoveries cannot be changed ``` Note: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries. ### `kibana.alert.workflow_status` added to default `Alerts` tab columns The `kibana.alert.workflow_status` field was added to default `Alerts` tab columns, as illustrated by the screenshot below:  ### Summary of field updates The following table describes when fields are updated (via this PR): | Field | Updated when | Description | |-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------| | `kibana.alert.start` | - Attack discoveries are created | timestamp when Attack discoveries are created | | `kibana.alert.workflow_status_updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated | timestamp when `kibana.alert.workflow_status` was last updated | | `kibana.alert.updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | timestamp when the alert was last updated | | `kibana.alert.updated_by.user.id` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user id of the user that last updated the alert | | `kibana.alert.updated_by.user.name` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user name of the user that last updated the alert | | `@timestamp` | - Attack discoveries are created<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | ECS [`@timestamp`](https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp) field | ### Feature flags The _required_ feature flag below is necessary to desk test with Ad hoc attack discoveries. The _recommended_ feature flag below enables testing with scheduled Attack discoveries. ### required: `securitySolution.attackDiscoveryAlertsEnabled` Enable the required `securitySolution.attackDiscoveryAlertsEnabled` feature flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true ``` ### recommended: `securitySolution.assistantAttackDiscoverySchedulingEnabled: true` Also enable the recommended `assistantAttackDiscoverySchedulingEnabled` feature flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` (cherry picked from commit ea7d174)
Contributor
💚 All backports created successfully
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
Jun 25, 2025
…w_status` of alerts associated with Attack discoveries (#225029) (#225349) # Backport This will backport the following commits from `main` to `8.19`: - [[Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries (#225029)](#225029) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Andrew Macri","email":"andrew.macri@elastic.co"},"sourceCommit":{"committedDate":"2025-06-25T00:47:10Z","message":"[Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries (#225029)\n\n## [Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries\n\nThis PR introduces a new UI to optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries, as illustrated by the animated gif below:\n\n\n\nUsers may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:\n\n\n\nWhen multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:\n\n\n\n### Alert document enhancements\n\nAttack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents.\n\nTo support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields:\n\n1) `kibana.alert.start` - timestamp when Attack discoveries are created\n\n2) `kibana.alert.workflow_status_updated_at` - timestamp when the `kibana.alert.workflow_status` was last updated\n\nThis PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future:\n\n1) `kibana.alert.updated_at` - timestamp when the alert was last updated\n\n2) `kibana.alert.updated_by.user.id` - user id of the user that last updated the alert\n\n3) `kibana.alert.updated_by.user.name` - user name of the user that last updated the alert\n\nThe three new alert fields above are updated when Attack discovery users update:\n\n- The `kibana.alert.workflow_status` status of Attack discoveries\n- The visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`)\n\nThe three new fields above were added to the [alert_field_map](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts) and [alert_schema](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/schemas/generated/alert_schema.ts).\n\nUsing the `default` space as an example, the fields above may be observed in the `.adhoc.alerts-security.attack.discovery.alerts-default` data stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the `.alerts-security.attack.discovery.alerts-default` data stream.\n\n### @timestamp updated when sharing status changes\n\nTo ensure newly-shared Attack discoveries are bumped to the top of search results, the `@timestamp` field is updated when the visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) is updated.\n\n(The original time an Attack discovery was generated is represented by the `kibana.alert.start` field, which is not mutated.)\n\n### Visibility menu changes\n\nThis PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:\n\n\n\nThe disabled menu has a tooltip that reads:\n\n```\nThe visibility of shared discoveries cannot be changed\n```\n\nNote: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries.\n\n### `kibana.alert.workflow_status` added to default `Alerts` tab columns\n\nThe `kibana.alert.workflow_status` field was added to default `Alerts` tab columns, as illustrated by the screenshot below:\n\n\n\n### Summary of field updates\n\nThe following table describes when fields are updated (via this PR):\n\n| Field | Updated when | Description |\n|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|\n| `kibana.alert.start` | - Attack discoveries are created | timestamp when Attack discoveries are created |\n| `kibana.alert.workflow_status_updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated | timestamp when `kibana.alert.workflow_status` was last updated |\n| `kibana.alert.updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | timestamp when the alert was last updated |\n| `kibana.alert.updated_by.user.id` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user id of the user that last updated the alert |\n| `kibana.alert.updated_by.user.name` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user name of the user that last updated the alert |\n| `@timestamp` | - Attack discoveries are created<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | ECS [`@timestamp`](https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp) field |\n\n### Feature flags\n\nThe _required_ feature flag below is necessary to desk test with Ad hoc attack discoveries. The _recommended_ feature flag below enables testing with scheduled Attack discoveries.\n\n### required: `securitySolution.attackDiscoveryAlertsEnabled`\n\nEnable the required `securitySolution.attackDiscoveryAlertsEnabled` feature flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n```\n\n### recommended: `securitySolution.assistantAttackDiscoverySchedulingEnabled: true`\n\nAlso enable the recommended `assistantAttackDiscoverySchedulingEnabled` feature flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```","sha":"ea7d174e3c5c80ff74c70c4d9bdc7a9825e7c135","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team: SecuritySolution","release_note:feature","Team:Security Generative AI","backport:version","v9.1.0","v8.19.0"],"title":"[Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries","number":225029,"url":"https://github.com/elastic/kibana/pull/225029","mergeCommit":{"message":"[Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries (#225029)\n\n## [Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries\n\nThis PR introduces a new UI to optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries, as illustrated by the animated gif below:\n\n\n\nUsers may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:\n\n\n\nWhen multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:\n\n\n\n### Alert document enhancements\n\nAttack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents.\n\nTo support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields:\n\n1) `kibana.alert.start` - timestamp when Attack discoveries are created\n\n2) `kibana.alert.workflow_status_updated_at` - timestamp when the `kibana.alert.workflow_status` was last updated\n\nThis PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future:\n\n1) `kibana.alert.updated_at` - timestamp when the alert was last updated\n\n2) `kibana.alert.updated_by.user.id` - user id of the user that last updated the alert\n\n3) `kibana.alert.updated_by.user.name` - user name of the user that last updated the alert\n\nThe three new alert fields above are updated when Attack discovery users update:\n\n- The `kibana.alert.workflow_status` status of Attack discoveries\n- The visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`)\n\nThe three new fields above were added to the [alert_field_map](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts) and [alert_schema](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/schemas/generated/alert_schema.ts).\n\nUsing the `default` space as an example, the fields above may be observed in the `.adhoc.alerts-security.attack.discovery.alerts-default` data stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the `.alerts-security.attack.discovery.alerts-default` data stream.\n\n### @timestamp updated when sharing status changes\n\nTo ensure newly-shared Attack discoveries are bumped to the top of search results, the `@timestamp` field is updated when the visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) is updated.\n\n(The original time an Attack discovery was generated is represented by the `kibana.alert.start` field, which is not mutated.)\n\n### Visibility menu changes\n\nThis PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:\n\n\n\nThe disabled menu has a tooltip that reads:\n\n```\nThe visibility of shared discoveries cannot be changed\n```\n\nNote: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries.\n\n### `kibana.alert.workflow_status` added to default `Alerts` tab columns\n\nThe `kibana.alert.workflow_status` field was added to default `Alerts` tab columns, as illustrated by the screenshot below:\n\n\n\n### Summary of field updates\n\nThe following table describes when fields are updated (via this PR):\n\n| Field | Updated when | Description |\n|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|\n| `kibana.alert.start` | - Attack discoveries are created | timestamp when Attack discoveries are created |\n| `kibana.alert.workflow_status_updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated | timestamp when `kibana.alert.workflow_status` was last updated |\n| `kibana.alert.updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | timestamp when the alert was last updated |\n| `kibana.alert.updated_by.user.id` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user id of the user that last updated the alert |\n| `kibana.alert.updated_by.user.name` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user name of the user that last updated the alert |\n| `@timestamp` | - Attack discoveries are created<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | ECS [`@timestamp`](https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp) field |\n\n### Feature flags\n\nThe _required_ feature flag below is necessary to desk test with Ad hoc attack discoveries. The _recommended_ feature flag below enables testing with scheduled Attack discoveries.\n\n### required: `securitySolution.attackDiscoveryAlertsEnabled`\n\nEnable the required `securitySolution.attackDiscoveryAlertsEnabled` feature flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n```\n\n### recommended: `securitySolution.assistantAttackDiscoverySchedulingEnabled: true`\n\nAlso enable the recommended `assistantAttackDiscoverySchedulingEnabled` feature flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```","sha":"ea7d174e3c5c80ff74c70c4d9bdc7a9825e7c135"}},"sourceBranch":"main","suggestedTargetBranches":["8.19"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/225029","number":225029,"mergeCommit":{"message":"[Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries (#225029)\n\n## [Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries\n\nThis PR introduces a new UI to optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries, as illustrated by the animated gif below:\n\n\n\nUsers may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:\n\n\n\nWhen multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:\n\n\n\n### Alert document enhancements\n\nAttack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents.\n\nTo support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields:\n\n1) `kibana.alert.start` - timestamp when Attack discoveries are created\n\n2) `kibana.alert.workflow_status_updated_at` - timestamp when the `kibana.alert.workflow_status` was last updated\n\nThis PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future:\n\n1) `kibana.alert.updated_at` - timestamp when the alert was last updated\n\n2) `kibana.alert.updated_by.user.id` - user id of the user that last updated the alert\n\n3) `kibana.alert.updated_by.user.name` - user name of the user that last updated the alert\n\nThe three new alert fields above are updated when Attack discovery users update:\n\n- The `kibana.alert.workflow_status` status of Attack discoveries\n- The visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`)\n\nThe three new fields above were added to the [alert_field_map](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts) and [alert_schema](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/schemas/generated/alert_schema.ts).\n\nUsing the `default` space as an example, the fields above may be observed in the `.adhoc.alerts-security.attack.discovery.alerts-default` data stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the `.alerts-security.attack.discovery.alerts-default` data stream.\n\n### @timestamp updated when sharing status changes\n\nTo ensure newly-shared Attack discoveries are bumped to the top of search results, the `@timestamp` field is updated when the visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) is updated.\n\n(The original time an Attack discovery was generated is represented by the `kibana.alert.start` field, which is not mutated.)\n\n### Visibility menu changes\n\nThis PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:\n\n\n\nThe disabled menu has a tooltip that reads:\n\n```\nThe visibility of shared discoveries cannot be changed\n```\n\nNote: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries.\n\n### `kibana.alert.workflow_status` added to default `Alerts` tab columns\n\nThe `kibana.alert.workflow_status` field was added to default `Alerts` tab columns, as illustrated by the screenshot below:\n\n\n\n### Summary of field updates\n\nThe following table describes when fields are updated (via this PR):\n\n| Field | Updated when | Description |\n|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|\n| `kibana.alert.start` | - Attack discoveries are created | timestamp when Attack discoveries are created |\n| `kibana.alert.workflow_status_updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated | timestamp when `kibana.alert.workflow_status` was last updated |\n| `kibana.alert.updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | timestamp when the alert was last updated |\n| `kibana.alert.updated_by.user.id` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user id of the user that last updated the alert |\n| `kibana.alert.updated_by.user.name` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user name of the user that last updated the alert |\n| `@timestamp` | - Attack discoveries are created<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | ECS [`@timestamp`](https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp) field |\n\n### Feature flags\n\nThe _required_ feature flag below is necessary to desk test with Ad hoc attack discoveries. The _recommended_ feature flag below enables testing with scheduled Attack discoveries.\n\n### required: `securitySolution.attackDiscoveryAlertsEnabled`\n\nEnable the required `securitySolution.attackDiscoveryAlertsEnabled` feature flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n```\n\n### recommended: `securitySolution.assistantAttackDiscoverySchedulingEnabled: true`\n\nAlso enable the recommended `assistantAttackDiscoverySchedulingEnabled` feature flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```","sha":"ea7d174e3c5c80ff74c70c4d9bdc7a9825e7c135"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Andrew Macri <andrew.macri@elastic.co>
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this pull request
Jul 9, 2025
… user to update the `kibana.alert.workflow_status` of alerts This PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](elastic#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated ### All other serverless projects All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Elastic Cloud and self manged Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Feature flags Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` ### AI4DSOC - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` ### Desk testing 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ |
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this pull request
Jul 10, 2025
…oes NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](elastic#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ |
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this pull request
Jul 11, 2025
…oes NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](elastic#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ |
andrew-goldstein
added a commit
that referenced
this pull request
Jul 11, 2025
…er to update the `kibana.alert.workflow_status` of alerts (#227326) ## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts This PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated ### All other serverless projects All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Elastic Cloud and self manged Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Feature flags Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` ### AI4DSOC - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` ### Desk testing 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jul 11, 2025
…er to update the `kibana.alert.workflow_status` of alerts (elastic#227326) ## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts This PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](elastic#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated ### All other serverless projects All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Elastic Cloud and self manged Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Feature flags Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` ### AI4DSOC - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` ### Desk testing 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | (cherry picked from commit a4aa6a0)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jul 11, 2025
…er to update the `kibana.alert.workflow_status` of alerts (elastic#227326) ## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts This PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](elastic#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated ### All other serverless projects All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Elastic Cloud and self manged Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Feature flags Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` ### AI4DSOC - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` ### Desk testing 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | (cherry picked from commit a4aa6a0)
kibanamachine
added a commit
that referenced
this pull request
Jul 11, 2025
…the user to update the `kibana.alert.workflow_status` of alerts (#227326) (#227721) # Backport This will backport the following commits from `main` to `9.1`: - [[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)](#227326) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Andrew Macri","email":"andrew.macri@elastic.co"},"sourceCommit":{"committedDate":"2025-07-11T20:16:59Z","message":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)\n\n## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts\n\nThis PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:\n\n\n\n_Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_\n\nThe animated gif above illustrates that in AI4DSOC projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed\n- Only the workflow status of the Attack discovery is updated\n\n### All other serverless projects\n\nAll other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for all other serverless projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Elastic Cloud and self manged\n\nElastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: Self managed: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for Elastic cloud and self manged:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Feature flags\n\nEnable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```\n\n### AI4DSOC\n\n- To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`:\n\n```yaml\nxpack.securitySolutionServerless.productTypes:\n[\n { product_line: 'ai_soc', product_tier: 'search_ai_lake' },\n]\n```\n\n### Desk testing\n\n1) Navigate to Security > Attack discovery\n\n2) Click `Generate` to generate attack discoveries\n\n3) Click the `Take action` dropdown on an Attack discovery\n\n4) Click `Mark as acknowledged`\n\n**Expected result**\n\nThe modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |\n\n5) Select (at least) 2 discoveries via their checkboxes\n\n6) Click the `Selected 2 Attack discoveries` popover menu\n\n7) Click `Mark as closed` from the popover menu\n\n**Expected result**\n\nOnce again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |","sha":"a4aa6a04c3db7d793e334fd1b38273cfca141c09","branchLabelMapping":{"^v9.2.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team: SecuritySolution","Team:Security Generative AI","backport:version","v9.1.0","v8.19.0","v9.2.0"],"title":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts","number":227326,"url":"https://github.com/elastic/kibana/pull/227326","mergeCommit":{"message":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)\n\n## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts\n\nThis PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:\n\n\n\n_Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_\n\nThe animated gif above illustrates that in AI4DSOC projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed\n- Only the workflow status of the Attack discovery is updated\n\n### All other serverless projects\n\nAll other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for all other serverless projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Elastic Cloud and self manged\n\nElastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: Self managed: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for Elastic cloud and self manged:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Feature flags\n\nEnable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```\n\n### AI4DSOC\n\n- To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`:\n\n```yaml\nxpack.securitySolutionServerless.productTypes:\n[\n { product_line: 'ai_soc', product_tier: 'search_ai_lake' },\n]\n```\n\n### Desk testing\n\n1) Navigate to Security > Attack discovery\n\n2) Click `Generate` to generate attack discoveries\n\n3) Click the `Take action` dropdown on an Attack discovery\n\n4) Click `Mark as acknowledged`\n\n**Expected result**\n\nThe modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |\n\n5) Select (at least) 2 discoveries via their checkboxes\n\n6) Click the `Selected 2 Attack discoveries` popover menu\n\n7) Click `Mark as closed` from the popover menu\n\n**Expected result**\n\nOnce again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |","sha":"a4aa6a04c3db7d793e334fd1b38273cfca141c09"}},"sourceBranch":"main","suggestedTargetBranches":["9.1","8.19"],"targetPullRequestStates":[{"branch":"9.1","label":"v9.1.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.2.0","branchLabelMappingKey":"^v9.2.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/227326","number":227326,"mergeCommit":{"message":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)\n\n## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts\n\nThis PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:\n\n\n\n_Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_\n\nThe animated gif above illustrates that in AI4DSOC projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed\n- Only the workflow status of the Attack discovery is updated\n\n### All other serverless projects\n\nAll other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for all other serverless projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Elastic Cloud and self manged\n\nElastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: Self managed: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for Elastic cloud and self manged:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Feature flags\n\nEnable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```\n\n### AI4DSOC\n\n- To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`:\n\n```yaml\nxpack.securitySolutionServerless.productTypes:\n[\n { product_line: 'ai_soc', product_tier: 'search_ai_lake' },\n]\n```\n\n### Desk testing\n\n1) Navigate to Security > Attack discovery\n\n2) Click `Generate` to generate attack discoveries\n\n3) Click the `Take action` dropdown on an Attack discovery\n\n4) Click `Mark as acknowledged`\n\n**Expected result**\n\nThe modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |\n\n5) Select (at least) 2 discoveries via their checkboxes\n\n6) Click the `Selected 2 Attack discoveries` popover menu\n\n7) Click `Mark as closed` from the popover menu\n\n**Expected result**\n\nOnce again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |","sha":"a4aa6a04c3db7d793e334fd1b38273cfca141c09"}}]}] BACKPORT--> Co-authored-by: Andrew Macri <andrew.macri@elastic.co>
kibanamachine
added a commit
that referenced
this pull request
Jul 14, 2025
… the user to update the `kibana.alert.workflow_status` of alerts (#227326) (#227720) # Backport This will backport the following commits from `main` to `8.19`: - [[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)](#227326) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Andrew Macri","email":"andrew.macri@elastic.co"},"sourceCommit":{"committedDate":"2025-07-11T20:16:59Z","message":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)\n\n## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts\n\nThis PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:\n\n\n\n_Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_\n\nThe animated gif above illustrates that in AI4DSOC projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed\n- Only the workflow status of the Attack discovery is updated\n\n### All other serverless projects\n\nAll other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for all other serverless projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Elastic Cloud and self manged\n\nElastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: Self managed: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for Elastic cloud and self manged:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Feature flags\n\nEnable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```\n\n### AI4DSOC\n\n- To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`:\n\n```yaml\nxpack.securitySolutionServerless.productTypes:\n[\n { product_line: 'ai_soc', product_tier: 'search_ai_lake' },\n]\n```\n\n### Desk testing\n\n1) Navigate to Security > Attack discovery\n\n2) Click `Generate` to generate attack discoveries\n\n3) Click the `Take action` dropdown on an Attack discovery\n\n4) Click `Mark as acknowledged`\n\n**Expected result**\n\nThe modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |\n\n5) Select (at least) 2 discoveries via their checkboxes\n\n6) Click the `Selected 2 Attack discoveries` popover menu\n\n7) Click `Mark as closed` from the popover menu\n\n**Expected result**\n\nOnce again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |","sha":"a4aa6a04c3db7d793e334fd1b38273cfca141c09","branchLabelMapping":{"^v9.2.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team: SecuritySolution","Team:Security Generative AI","backport:version","v9.1.0","v8.19.0","v9.2.0"],"title":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts","number":227326,"url":"https://github.com/elastic/kibana/pull/227326","mergeCommit":{"message":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)\n\n## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts\n\nThis PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:\n\n\n\n_Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_\n\nThe animated gif above illustrates that in AI4DSOC projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed\n- Only the workflow status of the Attack discovery is updated\n\n### All other serverless projects\n\nAll other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for all other serverless projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Elastic Cloud and self manged\n\nElastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: Self managed: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for Elastic cloud and self manged:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Feature flags\n\nEnable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```\n\n### AI4DSOC\n\n- To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`:\n\n```yaml\nxpack.securitySolutionServerless.productTypes:\n[\n { product_line: 'ai_soc', product_tier: 'search_ai_lake' },\n]\n```\n\n### Desk testing\n\n1) Navigate to Security > Attack discovery\n\n2) Click `Generate` to generate attack discoveries\n\n3) Click the `Take action` dropdown on an Attack discovery\n\n4) Click `Mark as acknowledged`\n\n**Expected result**\n\nThe modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |\n\n5) Select (at least) 2 discoveries via their checkboxes\n\n6) Click the `Selected 2 Attack discoveries` popover menu\n\n7) Click `Mark as closed` from the popover menu\n\n**Expected result**\n\nOnce again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |","sha":"a4aa6a04c3db7d793e334fd1b38273cfca141c09"}},"sourceBranch":"main","suggestedTargetBranches":["9.1","8.19"],"targetPullRequestStates":[{"branch":"9.1","label":"v9.1.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.2.0","branchLabelMappingKey":"^v9.2.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/227326","number":227326,"mergeCommit":{"message":"[AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts (#227326)\n\n## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts\n\nThis PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](#225029), as illustrated by the animated gif below:\n\n\n\n_Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_\n\nThe animated gif above illustrates that in AI4DSOC projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed\n- Only the workflow status of the Attack discovery is updated\n\n### All other serverless projects\n\nAll other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for all other serverless projects:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Elastic Cloud and self manged\n\nElastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:\n\n\n\n_Above: Self managed: The modal is displayed, and the associated alerts are updated_\n\nThe animated gif above illustrates that for Elastic cloud and self manged:\n\n- The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed\n- The workflow status of the Attack discovery is (optionally) updated\n\n### Feature flags\n\nEnable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`:\n\n```yaml\nfeature_flags.overrides:\n securitySolution.attackDiscoveryAlertsEnabled: true\n securitySolution.assistantAttackDiscoverySchedulingEnabled: true\n```\n\n### AI4DSOC\n\n- To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`:\n\n```yaml\nxpack.securitySolutionServerless.productTypes:\n[\n { product_line: 'ai_soc', product_tier: 'search_ai_lake' },\n]\n```\n\n### Desk testing\n\n1) Navigate to Security > Attack discovery\n\n2) Click `Generate` to generate attack discoveries\n\n3) Click the `Take action` dropdown on an Attack discovery\n\n4) Click `Mark as acknowledged`\n\n**Expected result**\n\nThe modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |\n\n5) Select (at least) 2 discoveries via their checkboxes\n\n6) Click the `Selected 2 Attack discoveries` popover menu\n\n7) Click `Mark as closed` from the popover menu\n\n**Expected result**\n\nOnce again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below:\n\n| Deployment | Modal displayed | Alerts (optionally) updated |\n|-------------------------------|-----------------|-----------------------------|\n| AI4DSOC | ❌ | ❌ |\n| All other serverless projects | ✅ | ✅ |\n| Elastic Cloud and self manged | ✅ | ✅ |","sha":"a4aa6a04c3db7d793e334fd1b38273cfca141c09"}}]}] BACKPORT--> Co-authored-by: Andrew Macri <andrew.macri@elastic.co> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
kertal
pushed a commit
to kertal/kibana
that referenced
this pull request
Jul 25, 2025
…er to update the `kibana.alert.workflow_status` of alerts (elastic#227326) ## [AI4DSOC] [Attack discovery] In AI4DSOC projects, don't prompt the user to update the `kibana.alert.workflow_status` of alerts This PR updates Attack discovery for AI4DSOC projects, such that it does NOT prompt the user with a modal to [optionally update the kibana.alert.workflow_status of alerts associated with Attack discoveries](elastic#225029), as illustrated by the animated gif below:  _Above: AI4DSOC: The modal is NOT displayed, and the associated alerts are NOT updated_ The animated gif above illustrates that in AI4DSOC projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is NOT displayed - Only the workflow status of the Attack discovery is updated ### All other serverless projects All other (non-AI4DSOC) serverless projects display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: All other serverless projects: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for all other serverless projects: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Elastic Cloud and self manged Elastic Cloud and self manged deployments display the modal, and optionally update the workflow status of the alerts, as illustrated by the animated gif below:  _Above: Self managed: The modal is displayed, and the associated alerts are updated_ The animated gif above illustrates that for Elastic cloud and self manged: - The modal prompting the user to update the `kibana.alert.workflow_status` of alerts is displayed - The workflow status of the Attack discovery is (optionally) updated ### Feature flags Enable the required and recommended `assistantAttackDiscoverySchedulingEnabled` features flag in `config/kibana.dev.yml`: ```yaml feature_flags.overrides: securitySolution.attackDiscoveryAlertsEnabled: true securitySolution.assistantAttackDiscoverySchedulingEnabled: true ``` ### AI4DSOC - To test with an AI4DSOC project, add the following setting to `config/serverless.security.dev.yaml`: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'ai_soc', product_tier: 'search_ai_lake' }, ] ``` ### Desk testing 1) Navigate to Security > Attack discovery 2) Click `Generate` to generate attack discoveries 3) Click the `Take action` dropdown on an Attack discovery 4) Click `Mark as acknowledged` **Expected result** The modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ | 5) Select (at least) 2 discoveries via their checkboxes 6) Click the `Selected 2 Attack discoveries` popover menu 7) Click `Mark as closed` from the popover menu **Expected result** Once again, the modal is displayed, and alerts are (optionally) updated for the deployment, for the deployment-type in the table below: | Deployment | Modal displayed | Alerts (optionally) updated | |-------------------------------|-----------------|-----------------------------| | AI4DSOC | ❌ | ❌ | | All other serverless projects | ✅ | ✅ | | Elastic Cloud and self manged | ✅ | ✅ |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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.
[Attack discovery] Optionally update the
kibana.alert.workflow_statusof alerts associated with Attack discoveriesThis PR introduces a new UI to optionally update the
kibana.alert.workflow_statusof alerts associated with Attack discoveries, as illustrated by the animated gif below:Users may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:
When multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:
Alert document enhancements
Attack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents.
To support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields:
kibana.alert.start- timestamp when Attack discoveries are createdkibana.alert.workflow_status_updated_at- timestamp when thekibana.alert.workflow_statuswas last updatedThis PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future:
kibana.alert.updated_at- timestamp when the alert was last updatedkibana.alert.updated_by.user.id- user id of the user that last updated the alertkibana.alert.updated_by.user.name- user name of the user that last updated the alertThe three new alert fields above are updated when Attack discovery users update:
kibana.alert.workflow_statusstatus of Attack discoverieskibana.alert.attack_discovery.users)The three new fields above were added to the alert_field_map and alert_schema.
Using the
defaultspace as an example, the fields above may be observed in the.adhoc.alerts-security.attack.discovery.alerts-defaultdata stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the.alerts-security.attack.discovery.alerts-defaultdata stream.@timestamp updated when sharing status changes
To ensure newly-shared Attack discoveries are bumped to the top of search results, the
@timestampfield is updated when the visibility (sharing) status of Attack discoveries (kibana.alert.attack_discovery.users) is updated.(The original time an Attack discovery was generated is represented by the
kibana.alert.startfield, which is not mutated.)Visibility menu changes
This PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:
The disabled menu has a tooltip that reads:
Note: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries.
kibana.alert.workflow_statusadded to defaultAlertstab columnsThe
kibana.alert.workflow_statusfield was added to defaultAlertstab columns, as illustrated by the screenshot below:Summary of field updates
The following table describes when fields are updated (via this PR):
kibana.alert.startkibana.alert.workflow_status_updated_atkibana.alert.workflow_status) is updatedkibana.alert.workflow_statuswas last updatedkibana.alert.updated_atkibana.alert.workflow_status) is updated- Sharing status (
kibana.alert.attack_discovery.users) is updatedkibana.alert.updated_by.user.idkibana.alert.workflow_status) is updated- Sharing status (
kibana.alert.attack_discovery.users) is updatedkibana.alert.updated_by.user.namekibana.alert.workflow_status) is updated- Sharing status (
kibana.alert.attack_discovery.users) is updated@timestamp- Sharing status (
kibana.alert.attack_discovery.users) is updated@timestampfieldFeature flags
The required feature flag below is necessary to desk test with Ad hoc attack discoveries. The recommended feature flag below enables testing with scheduled Attack discoveries.
required:
securitySolution.attackDiscoveryAlertsEnabledEnable the required
securitySolution.attackDiscoveryAlertsEnabledfeature flag inconfig/kibana.dev.yml:recommended:
securitySolution.assistantAttackDiscoverySchedulingEnabled: trueAlso enable the recommended
assistantAttackDiscoverySchedulingEnabledfeature flag inconfig/kibana.dev.yml: