[Security Solution] [RAC] Local storage and the `Reset Fields` button are not working as expected for the `Security > Alerts` view

[andrew-goldstein]

Describe the bug:

Local storage and the Reset Fields button are not working as expected for the Security > Alerts view. As a result:

• The fields selected by a user in the Security > Alerts view are always (unexpectedly) reset to the defaults when a browser tab is closed and re-opened, because local storage is not working as-expected
• The only way to reset the Security > Alerts view to the default set of columns is to close and re-open the browser tab, because Reset Fields is not working as-expected

Noted while desk testing the (unrelated) fix for #110043 in #110464

Kibana/Elasticsearch Stack version:

7.15 BC3

Steps to reproduce:

To Reproduce:

1. Close all browser tabs connected to the Kibana instance you're using for testitng

2. Use your browser's cache management to delete both cookies and local storage related to your Kibana instance (note: this may be localhost if you're running Kibana locally)

3. Open a new browser tab and navigate to the root of your Kibana instance, e.g. http://localhost:5601, and ensure there is no URL query state in the address bar

4. Navigate to the Security > Alerts page

Expected results:

• Per the screenshot below, the following default columns are displayed
  • @timestamp
  • Rule
  • Severity
  • Risk Score
  • Reason
  • host.name
  • user.name
  • process.name
  • file.name
  • source.ip
  • destination.ip

Above: the default columns in the Security Solution Alerts table

5. Open the browser's dev tools (Inspect the page in Chrome), and navigate to the dev tools tab that displays local storage (e.g. the Application tab in Chrome), as shown in the screenshot below:

Above: The initial state of local storage, as viewed in the Application tab of Chrome dev tools

6. Click the Fields button in the Alerts table to display the Fields browser modal

Expected result

• The Fields browser is displayed

7. Click the cloud category in the Fields browser to select it

8. Click the View all clouds fields button

Expected result:

• All the fields in the cloud category are selected, as shown in the screenshot below:

Above: all fields in the cloud category are selected

9. Click Close to close the Fields browser

Expected results:

• The alerts table displays the @timestamp field, followed by all the cloud fields, as shown in the screenshot below:

Above: all cloud fields in the alerts table

10. Once again, examine the dev tools tab (Application in Chrome) that displays local storage, as shown in the screenshot below for the persisted state of the columns:

Expected results:

• To ensure the state of perisisted columns is maintained after the browser tab is closed and re-opened, a local storage key named timelines has been created in local storage, as shown in the screenshot below (taken from an eariler version of Kibana, 7.12 in this example, because this functionality is not working as expected in the 7.14 release):

• The Value of the timelines local storage key includes persistence for all of cloud fields added to the Security > Alerts table, as shown in the following JSON snippit (from a 7.12 instance):

{
   "detections-page":{
      "id":"detections-page",
      "activeTab":"query",
      "prevActiveTab":"query",
      "columns":[
         {
            "category":"base",
            "columnHeaderType":"not-filtered",
            "description":"Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events.",
            "example":"2016-05-23T08:05:34.853Z",
            "id":"@timestamp",
            "type":"date",
            "aggregatable":true,
            "width":190
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier.",
            "example":"666777888999",
            "id":"cloud.account.id",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"Availability zone in which this host is running.",
            "example":"us-east-1c",
            "id":"cloud.availability_zone",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         // ...
         }
      ],
      // ...
   }
}

Above: in 7.12, the value of the timelines key includes persistence of the cloud fields that were added to the Alerts table

Actual results:

• The timelines key was NOT created in local storage
• The cloud fields are NOT persisted as JSON for the alerts page (under the missing timelines local storage key)

11. Close the browser tab displaying Kibana

12. Once again, open a new browser tab and navigate to root Kibana, e.g. http://localhost:5601, ensuring there is no URL state in the address bar

13. Once again, navigate to the Security > Alerts page

Expected result

• The alerts table displays the @timestamp field and all the fields from the cloud category, because the fields were read from local storage (as seen in the 7.12 release used in this example)

Actual result

• The alerts table does NOT display the cloud fields. Instead, it (incorrectly) displays the default columns as noted in step 4, because the persisted column configuration was not read from local storage

14. Once again, click the Fields button

Expected result

• The Fields browser is displayed

15. Once again, click the cloud category

16. Once again, click the View all cloud fields button

Expected result:

• All the fields in the cloud category are selected

17. Click Close to close the Fields browser

Expected results:

• The alerts table displays the @timestamp field, followed by all the cloud fields

18. Now, (one last time), click the Fields button in the Alerts table to display the Fields browser modal

Expected result

• The Fields browser is displayed

19. Click the Reset Fields button

Expected result

• The Fields browser is closed

• The following default columns are displayed

  • @timestamp
  • Rule
  • Severity
  • Risk Score
  • Reason
  • host.name
  • user.name
  • process.name
  • file.name
  • source.ip
  • destination.ip

  Actual results

• The Fields browser is closed

• Instead of restoring the expected default columns (including Reason), a different column set that includes message, event.category, event.action... is displayed, per the following screenshot:

Above: The alerts table is reset to non-default fields (e.g. there's no Reason field)

Other observations / notes

• After performing similar steps to the ones described above, the Host > Events view does create the expected timelines key in local storage

• The Local storage of selected columns and Reset fields functionality should be verified in the following views:

  • Alerts table on the Detections page
  • Alerts table on the Rule Details page
  • Events and External alerts tables on the Host Details page
  • Events and External alerts tables on the Host Page
  • External alerts on the Network page

[elasticmachine]

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

[elasticmachine]

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

[MadameSheema]

@karanbirsingh-qasource can you please validate the fix of this issue on 7.15BC5? Thanks :)

[MadameSheema]

This issue looks fixed on 7.15 branch (dae544a).

Pending to close the ticket once the issue is validated by @karanbirsingh-qasource on 7.15BC5