[Cases] Link cases to alerts #146864

cnasikas · 2022-12-02T10:32:24Z

Summary

Alerts can be attached to a case. You can see alerts' data from within a case but when viewing alerts in the alerts table it is not possible to understand if an alert is being investigated on a Case. The alerts table should have a column that shows the cases the alert is attached to.

Technical description

Schema

To link a case to an alert the alert's schema needs to be updated to store the cases to which the alert is being attached. The alert's schema should be extended to include:

kibana.alert.cases_ids: [<case_id>, <case_id>, ...]

To avoid leaking case information to users that do not have access to the case we will not save any other information (like the title for example) at the moment.

User flow

When a user attaches an alert to a case the alert's ID and index are stored in the case. Cases will update the alert's data to add the case ID to which the alert is attached. To do that, Cases will use the alert data client.

Permissions

A user to attach an alert to a case needs a) to have read access to the alert and b) to have write access to the case. The user that did the request should not have written access to the alert for Cases to add the case ID to the alert's data. The alert data client should be extended to cover this particular need: update an alert even if the user has read access. This scenario should only be used by system plugins like Cases and should not be exposed for public use.

~~### Short ID~~
To avoid taking up much space in the cases column in the alerts table, a short ID will be shown for each case. For the reasons described here #115808 (comment), #115808 (comment), and #115808 (comment) the first eight characters of the UUID of the case will be used as the short ID. For example, the short ID of a case with ID ffb0bc30-6031-11ed-9d7d-55e40a56bb38 will be ffb0bc30.

Fetching cases data

For privacy reasons, the alert will only contain the case IDs it is attached to. To show the title on the table and to construct the link (the link needs the owner of the case) we need to get the information of all cases shown in the table. To do that we will do one bulk get call to Cases to get all cases shown on the current page of the alerts table. The response will contain only the title and the owner of the case. If the user changes the total number of alerts shown on the table or the page of the table another bulk get call will be made.

Cases column on the alerts table

A new column that shows the cases the alert is attached to will be available to the users. The title of the first case will be shown. If more than one case is shown in the column, a + <remaining_cases> more button will be available for users to see the remaining cases. Users should be able to configure the display of the case columns in the "Columns" option and Solutions should decide if they want the column to be shown by default.

When hovering over a short ID a tooltip will be shown with all available information about the case. An HTTP call will be made to the Cases API to get all information regarding the case of interest. For example (design taken from #114378):

Guardrails

An alert cannot be attached to more than 10 cases

Edit history

We decided to not use the short ID and show the case title of the first case.
We decided to use an array of case ids and not an array of objects for the cases schema

Tasks

Extent alert's schema to store cases ([Cases] Add cases information to the alert's schema #147013)
Extend the alert data client to meet Cases needs ([Cases] Update cases ids in the alerts schema when attaching an alert to a case #147985)
Update the alert with cases information when attaching an alert to a case ([Cases] Update cases ids in the alerts schema when attaching an alert to a case #147985)
Create an internal bulk_get API for Cases ([Cases] Create Bulk get cases internal API #147674)
Show the cases column on the alerts table ([RAM] Show Cases column on the alerts table #150963, [RAM] Cases bulk actions & column improvements #151761)
Remove case id from the alert when removing alerts from a case ([Cases] Remove case info from alerts when deleting an alert attachment #154024, [Cases] Delete alerts when deleting all comments #154202)
Prevent users from attaching alerts to the same case ([Cases] Prevent users to attach the same alert to a case #145514, [Cases] Do not add already attached alerts to the case #154322, [Cases] Filter out alerts already attached to the case on the backend #154629)
Remove case id from alert when deleting a case ([Cases] Remove case id from alerts when deleting a case #154829)

Related issues: #114378, #115808, #132772, #140800

The text was updated successfully, but these errors were encountered:

elasticmachine · 2022-12-02T10:32:26Z

Pinging @elastic/response-ops-cases (Feature:Cases)

elasticmachine · 2022-12-02T10:32:26Z

Pinging @elastic/response-ops (Team:ResponseOps)

kobelb · 2022-12-05T20:29:43Z

Great write-up, @cnasikas! Everything you're planning on doing here looks great with the exception of the following:

For the reasons described here #115808 (comment), #115808 (comment), and #115808 (comment) the first eight characters of the UUID of the case will be used as the short ID.

There's nothing guaranteeing that the first eight characters of the UUID are sufficiently unique to be used as a short ID.

Git is using a short SHA-1 and then using the first few characters. It looks like they got away with using the first 7 digits for a while before having to make this configurable per git/git@dce9648. This seems like a reasonable precedent to rely on, but I think we should be open to others as well.

XavierM · 2022-12-05T21:18:02Z

I feel like we should show the name of the case and not just the ID or a subset because it does not mean anything to our user and if we worry about the length we should let the the cell rendering dealing with that.

kobelb · 2022-12-06T12:20:28Z

I feel like we should show the name of the case and not just the ID or a subset because it does not mean anything to our user and if we worry about the length we should let the the cell rendering dealing with that.

That's fine as well.

cnasikas · 2022-12-08T11:25:59Z

@kobelb You are right. I misused the term "short ID". The purpose was to save space in the table column and not use it as a way to refer to a case across Kibana. If we want a truly short ID we should hash the UUID (sha256(theCase.id)) and take the first n bits from the digest. The first 7 hex characters are not enough for our use case. If we want to be able to refer to a case globally across Kibana we need to support millions of documents without collisions. We would need around 12-16 hex characters as a short ID from the 64 hex characters of the sha256 digest for our use case.

@XavierM About the title, the reason I decided to not put it in the schema is for security/privacy reasons. If the user has access to the alert but not access to the case we leak sensitive information to the user about the case. The title may contain private information. If we are ok with leaking information then we can add it to the schema. Be aware that the title can be up to 160 characters and if an alert is attached to multiple cases the column may not fit everything. By the way, should we put a limit to the number of cases an alert can be attached to?

kobelb · 2022-12-08T14:29:24Z

I think we could make either option work, and we should defer to @shanisagiv1 on his preference:

Display the short ID as @cnasikas has proposed
Display the case titles as @XavierM has proposed

To work around the security concern, we don't necessarily have to put the Case title in the alert schema, and we can retrieve the case titles either when retrieving the alerts or when rendering the alerts table. Obviously, we'd need to limit the number of case titles that we retrieve per alert, but we'd likely want to do so anyway because we only have so much room in the UI to display them.

By the way, should we put a limit to the number of cases an alert can be attached to?

Absolutely! We shouldn't set this artificially low, but having reasonable bounds in place will allow us to make a much more resilient system.

cnasikas · 2022-12-08T19:06:53Z

I am not against displaying the title. @XavierM is right that the ids do not mean anything to our users but on the other hand, it is much simpler to use them. The initial designs proposed the short ID to be an incrementing ID (#2382 for example) which also does not mean anything. I think fetching case data will put a burden on the alerts table and make the code a bit more complex (handling case permissions on each solution etc). Do you think is ok to bulk get 1000 cases on the worst-case scenario (assuming a limit of 10 cases per alert and 100 alerts per page)?

Absolutely! We shouldn't set this artificially low, but having reasonable bounds in place will allow us to make a much more resilient system.

What do you think about 10 cases per alert?

kobelb · 2022-12-08T19:35:07Z

Do you think is ok to bulk get 1000 cases on the worst-case scenario (assuming a limit of 10 cases per alert and 100 alerts per page)?

My gut says this is tolerable. We don't need to load the entire case, just the title.

What do you think about 10 cases per alert?

Seems reasonable to me.

jonathan-buttner · 2022-12-08T19:35:31Z

By the way, should we put a limit to the number of cases an alert can be attached to?

If we put a limit on how many cases an alert can be attached to we'll probably need to introduce some reference counter so we can quickly determine if the attach alert API call should fail. The other option I can think of is to do an aggregation during that API call.

It gets worse for bulk attaching alerts although maybe we can still do the check using a single cardinality aggregation during the attach API call.

If we hit the limit, what do we expect the user to do if they really really want to attach that alert to another case? They'd have to go find a case where that alert is attached to and unattach it. Security solution provides the behavior to find the cases an alert is attached to so maybe that wouldn't be too bad.

An alternative would be to limit the number of cases we display in the alert table to say 10 and then if the user really wanted to see more they could view the alert details to see more. That way the user can attach the alert to as many cases as they want.

jonathan-buttner · 2022-12-08T19:37:52Z

Do you think is ok to bulk get 1000 cases on the worst-case scenario (assuming a limit of 10 cases per alert and 100 alerts per page)?

This request is going to be a bulk get right? That should be reasonably fast since we don't have to search.

cnasikas · 2022-12-12T10:10:58Z

If we put a limit on how many cases an alert can be attached to we'll probably need to introduce some reference counter so we can quickly determine if the attach alert API call should fail. The other option I can think of is to do an aggregation during that API call.

To avoid extra calls we can get the information from the alert's data. If kibana.alert.cases.length is more than 10 we can throw an error.

If we hit the limit, what do we expect the user to do if they really really want to attach that alert to another case? They'd have to go find a case where that alert is attached to and unattach it. Security solution provides the behavior to find the cases an alert is attached to so maybe that wouldn't be too bad.

An alternative would be to limit the number of cases we display in the alert table to say 10 and then if the user really wanted to see more they could view the alert details to see more. That way the user can attach the alert to as many cases as they want.

@shanisagiv1 What is your opinion on this?

This request is going to be a bulk get right? That should be reasonably fast since we don't have to search.

Yes, it will be a bulk get.

cnasikas · 2022-12-13T10:25:37Z

@kobelb @XavierM We discuss it with @shanisagiv1 and we decided to show the title of the Case in the table instead of the short ID. I updated the issue accordingly.

shanisagiv1 · 2022-12-13T10:45:38Z

yep^
Having the title name makes more sense, especially when there is more than one case. so the user won't have to guess which case is the right one.

Also, I asked Christos to check if it's possible to query how many alerts today are associated with more than one case. My gut feeling is that an alert should be associated with just one if it's a classic escalation of alerts to a case, but maybe I'm wrong... anyway having more context without asking the user to click is always preferred.

## Summary This PR adds case information to the alerts' schema. More information here: #146864. ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

## Summary This PR creates the bulk get cases internal API. The endpoint is needed for the alerts table to be able to get all cases the alerts are attached to with one call. Reference: #146864 ### Request - ids: (Required, array) An array of IDs of the retrieved cases. - fields: (Optional, array) The fields to return in the attributes key of the object response. ``` POST <kibana host>:<port>/internal/cases/_bulk_get { "ids": ["case-id-1", "case-id-2", "123", "not-authorized"], "fields": ["title"] } ``` ### Response ``` { "cases": [ { "title": "case1", "owner": "securitySolution", "id": "case-id-1", "version": "WzIzMTU0NSwxNV0=" }, { "title": "case2", "owner": "observability", "id": "case-id-2", "version": "WzIzMTU0NSwxNV0=" } ], "errors": [ { "error": "Not Found", "message": "Saved object [cases/123] not found", "status": 404, "caseId": "123" }, { "error": "Forbidden", "message": "Unauthorized to access case with owner: \"cases\"", "status": 403, "caseId": "not-authorized" } ] } ``` ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

## Summary This PR creates the bulk get cases internal API. The endpoint is needed for the alerts table to be able to get all cases the alerts are attached to with one call. Reference: elastic#146864 ### Request - ids: (Required, array) An array of IDs of the retrieved cases. - fields: (Optional, array) The fields to return in the attributes key of the object response. ``` POST <kibana host>:<port>/internal/cases/_bulk_get { "ids": ["case-id-1", "case-id-2", "123", "not-authorized"], "fields": ["title"] } ``` ### Response ``` { "cases": [ { "title": "case1", "owner": "securitySolution", "id": "case-id-1", "version": "WzIzMTU0NSwxNV0=" }, { "title": "case2", "owner": "observability", "id": "case-id-2", "version": "WzIzMTU0NSwxNV0=" } ], "errors": [ { "error": "Not Found", "message": "Saved object [cases/123] not found", "status": 404, "caseId": "123" }, { "error": "Forbidden", "message": "Unauthorized to access case with owner: \"cases\"", "status": 403, "caseId": "not-authorized" } ] } ``` ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

## Summary This PR adds a tooltip component (High OrderComponent) to @kbn/cases-components package. #146864 **Details of tooltip** ![image](https://user-images.githubusercontent.com/117571355/211531519-55c68e15-00ce-410d-9cd5-d23d4eb45287.png) **status: Open, tooltip position : Top** ![image](https://user-images.githubusercontent.com/117571355/211530420-d0c96461-1ce5-4344-8fcf-17907a7efe61.png) **status: In-progress, tooltip position: bottom, long title and description** ![image](https://user-images.githubusercontent.com/117571355/211530905-2df9b768-3181-481b-8234-43875301cbb4.png) ### Checklist Delete any items that are not applicable to this PR. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### How to Test: - run `yarn storybook cases` and test on http://localhost:9001/ Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

… to a case (#147985) ## Summary PR #147013 extended the alert's schema to be able to store the case id an alert is attached to. This PR adds the ability to update the `case_ids` field of the alert when an alert is attached to a case. It also limits the number of cases an alert can be attached to ten. ### Permissions A user to attach an alert to a case needs a) to have read access to the solution via the kibana feature privileges and b) to have write access to the case. The user that did the request should not need to have written access to the alert for Cases to add the case ID to the alert's data. For that reason, the alert data client is extended to cover this particular need: update an alert even if the user has read access. ## Alerts client aside For future reference, the alerts client uses the request to check the kibana feature authorization but uses the internal system user to perform any write and get operations on the alert indices themselves. For security solution this means that a user with only read access to the security solution kibana feature, write access to cases, and no read or write access to the alert indices could attach an alert to a case and have the case id stored in the alert. For observability, users intentionally do not have access to the alert indices so we want to bypass the authorization check on the indices which is why the current alerts client uses an es client that is an internal system user. Related issue: #146864 ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

## Summary This PR adds the cases column to the alerts table. Assumptions: - I will not change the label of the case column. I will do it on another PR. - The column will not be part of the default columns. The user has to add it from the fields. - If there are multiple cases they will be shown as a comma-separated list. It will change later to include a "show more" button or similar to show only the latest case in the column. - Due to circular dependencies, Cases types and utility functions were not imported. I duplicate the code. I opened two issues (#151648, #151649) to create packages that will contain the case types and utility functions. Issue: #146864 <img width="1649" alt="Screenshot 2023-02-17 at 7 37 25 PM" src="https://user-images.githubusercontent.com/7871006/219728708-a0922d32-8aaf-4433-88bb-5536f5e6b880.png"> ### Checklist Delete any items that are not applicable to this PR. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Adds the Cases column to the alerts table. The column shows, for each alert, all cases the alert is attached to.

#154024) ## Summary Users can remove alerts from a case by deleting the whole alert attachment. This PR removes the case id from the alerts when deleting an attachment of type alert. It does not remove the case info from all alerts attached to a case when deleting a case. It also fixes a bug where the success toaster will not show when deleting an attachment. Related: #146864, #140800 ## Testing 1. Create a case and attach some alerts to the case. 2. Verify that the alerts table (in security or in o11y) shows the case the alert is attached to. You can enable the cases column by pressing "Fields", searching for "Cases", and then selecting the field. 3. Go to the case and find the alerts' user activity. 4. Press the `...` and press "Remove alerts(s)" 5. Go back to the alert table and verify that the case is not shown in the Cases column for each alert. Please check that when you remove alert(s), attachments (ml, etc), and comments you get a success toaster with the correct text. ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

cnasikas added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Cases Cases feature labels Dec 2, 2022

cnasikas assigned XavierM and cnasikas Dec 2, 2022

cnasikas mentioned this issue Dec 14, 2022

[Cases] Add cases information to the alert's schema #147013

Merged

2 tasks

cnasikas mentioned this issue Dec 16, 2022

[Cases] Create Bulk get cases internal API #147674

Merged

2 tasks

js-jankisalvi mentioned this issue Jan 9, 2023

[Cases] add tooltip component to kbn-cases-components package #148561

Merged

5 tasks

cnasikas mentioned this issue Jan 12, 2023

[Cases] Update cases ids in the alerts schema when attaching an alert to a case #147985

Merged

2 tasks

cnasikas mentioned this issue Feb 17, 2023

[RAM] Show Cases column on the alerts table #150963

Merged

3 tasks

cnasikas mentioned this issue Mar 29, 2023

[Cases] Export bulk get API from the Cases UI client #153926

Closed

This was referenced Mar 30, 2023

[Cases] Remove case info from alerts when deleting an alert attachment #154024

Merged

[Cases] Prevent users to attach the same alert to a case #145514

Closed

nastasha-solomon mentioned this issue Apr 18, 2023

Changes to Security cases in 8.8 elastic/security-docs#3171

Closed

19 tasks

cnasikas closed this as completed Apr 18, 2023

This was referenced May 1, 2023

[DOCS] List privileges to add alerts to cases elastic/observability-docs#2898

Merged

[DOCS] List privileges to add alerts to cases #156278

Closed

nastasha-solomon mentioned this issue May 9, 2023

8.8.0 Release notes elastic/security-docs#3139

Closed

18 tasks

lcawl mentioned this issue May 18, 2023

[DOCS] Highlight cases links in alerts table #158097

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Cases] Link cases to alerts #146864

[Cases] Link cases to alerts #146864

cnasikas commented Dec 2, 2022 •

edited

Loading

elasticmachine commented Dec 2, 2022

elasticmachine commented Dec 2, 2022

kobelb commented Dec 5, 2022

XavierM commented Dec 5, 2022

kobelb commented Dec 6, 2022

cnasikas commented Dec 8, 2022 •

edited

Loading

kobelb commented Dec 8, 2022 •

edited

Loading

cnasikas commented Dec 8, 2022 •

edited

Loading

kobelb commented Dec 8, 2022

jonathan-buttner commented Dec 8, 2022 •

edited

Loading

jonathan-buttner commented Dec 8, 2022

cnasikas commented Dec 12, 2022

cnasikas commented Dec 13, 2022 •

edited

Loading

shanisagiv1 commented Dec 13, 2022

[Cases] Link cases to alerts #146864

[Cases] Link cases to alerts #146864

Comments

cnasikas commented Dec 2, 2022 • edited Loading

Summary

Technical description

Schema

User flow

Permissions

Fetching cases data

Cases column on the alerts table

Guardrails

Edit history

Tasks

elasticmachine commented Dec 2, 2022

elasticmachine commented Dec 2, 2022

kobelb commented Dec 5, 2022

XavierM commented Dec 5, 2022

kobelb commented Dec 6, 2022

cnasikas commented Dec 8, 2022 • edited Loading

kobelb commented Dec 8, 2022 • edited Loading

cnasikas commented Dec 8, 2022 • edited Loading

kobelb commented Dec 8, 2022

jonathan-buttner commented Dec 8, 2022 • edited Loading

jonathan-buttner commented Dec 8, 2022

cnasikas commented Dec 12, 2022

cnasikas commented Dec 13, 2022 • edited Loading

shanisagiv1 commented Dec 13, 2022

cnasikas commented Dec 2, 2022 •

edited

Loading

cnasikas commented Dec 8, 2022 •

edited

Loading

kobelb commented Dec 8, 2022 •

edited

Loading

cnasikas commented Dec 8, 2022 •

edited

Loading

jonathan-buttner commented Dec 8, 2022 •

edited

Loading

cnasikas commented Dec 13, 2022 •

edited

Loading