Customize Detection Columns?

Elastic Security SIEM
1

Is it possible to customize the columns in the detections alerts view? I'd like to incorporate some fields from the underlying events, if possible.

image
image1780×882 113 KB

2

Hi @ikiril01!

Both timeline and our alerts tables have the ability to customize the columns that are displayed; I'm guessing your screenshot is of timeline ! On alerts tables, the feature can be found here:

Detections_-_Kibana
Detections_-_Kibana1660×1288 199 KB

3

Right @RylandHerrick - the problem is that the current set of fields I see in "Customize Columns" doesn't include some specific event fields that I'm interested in being able to sort on.

Therefore, I need the ability to include some custom fields in this set. I saw that this was possible for the events table, but I'm not sure if the same is true for the alerts table.

Here's the post on customizing it for events: SIEM -- Event Columns (Only Default Category)

4

@ikiril01 thanks for clarifying! I was able to verify this behavior myself.

The source of the behavior is that while Events and Timeline are looking at both the source indexes and the internal alerts index to retrieve field data, the Alerts table is only looking at the alerts index. If the fields you're looking to display are not ECS fields, then the alerts index won't have mappings for them and thus they won't be available as columns.

Do you have examples of the fields that you're interested in displaying? I've reached out to the timeline team to see if this is expected behavior, but in the meantime I think the quickest solution would be to convert those fields to their ECS equivalents to get the behavior that you're looking for.

5

@RylandHerrick thanks for looking into it! It makes sense that it doesn't support the same set of fields as the events table since it only looks at the alerts index. I suppose there's no way to propagate specific fields from events to alerts?

As far as examples, we're basically just adding some custom labels to events that help us identify which enclave a machine belong to (e.g., "labels.enclave" = "lab", etc.), which would be useful to sort alerts by as well. Unfortunately there's no mapping to ECS since these are just labels.

6

Hey @ikiril01, I spoke with both Detections and Timeline folks and this is the expected behavior for the reasons discussed. However, if you really want those additional columns for alerts there is a way to do so:

Disclaimer: the following is not recommended nor supported, proceed at your own risk.

First, ensure that the fields you wish to add do not conflict with existing signals index. This means no conflicts with ECS fields, nor with the detections-specific signal fields. If these criteria are met, you can create a new signals index with your additional mappings in the following manner:

  1. Create a new index template based on the signals index template but with your additional mappings
    • This is most easily done through kibana's index management UI: cloning the existing signals index template, choosing a new name/pattern, and adding your additional mappings.
  2. Update your Detection Engine to use your new signals index:
    • Add/update your kibana.yml configuration to include xpack.securitySolution.signalsIndex: "NEW-SIGNALS-INDEX-NAME"

The next time your rules execute, they should begin populating your new signals index, and you should now be able to view/sort/investigate those additional signal fields in your alerts tables.

7

@RylandHerrick awesome! I'll give that a shot. Appreciate the quick response :slight_smile:

8

@ikiril01 the above being said, I would reiterate the suggestion of finding an appropriate ECS field for those labels as that's a much smoother, supported experience. For the labels.enclave example you provided, the host fields, particularly host.geo.name, seems appropriate. Here's an example of configuring that on an auditbeat agent.

If you do find that there is not an ECS field to support your use case, we'd love to hear it! We absolutely want to make ECS as useful as possible.

9

@RylandHerrick I tried the steps you provided above, namely cloning the elastic SIEM signals index, adding the mappings, and updating the kibana.yml config file to point to this index. Right now, this doesn't seem to be working - it looks like there are no alerts that are being loaded from the new index (it remains blank and just shows "loading alerts"). Anything else I should take a look at? Oh, and we're running 7.9.3 if that helps.

Update: I was able to get it working by simply updating the mappings for the default signals index. Go figure. It does what I want now (shows the labels field for sorting), so appreciate the help once again!

2 Likes
10

@ikiril01 that's great to hear! Would you mind detailing what mappings changes were necessary, in case others encounter your issue?

11

@RylandHerrick sure! The first thing I did to test things out was just update the SIEM signals index mapping directly:

PUT /.siem-signals-default-000001/_mapping
{
  "properties": {
    "labels": {
          "properties": {
            "foo": {
              "type": "keyword"
            }
          }
    }
  }
}

Once I tested that to make sure it was working, I created a new index template for the SIEM signals template (with an order of 1 so it doesn't conflict with the original):

PUT /_template/.siem-signals-custom
{
  "order" : 1,
  "index_patterns" : [".siem-signals-default-*"],
  "mappings" : {
    "properties": {
       "labels": {
          "properties": {
            "foo": {
              "type": "keyword"
            }
          }
      }
    }
  }
}
12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.