ES8 findings, intermediate findings, etc confusion!

The key thing I did not appreciate when I wrote the previous version of this post is that the Risk data model is now fed from index=notable (new in ES8) as well as index=risk (as it always has). Thanks to Haylee Mills for something I would otherwise probably never have noticed! This significantly invalidates my previous interpretation of how ES8 works, and I should have realised that weeks ago.

So let's start over with this new version.

Let's start with how the product appears to be working. I'll suggest improvements as we go, and we'll wrap this up in the conclusion.

Since the previous post, we have moved to 8.2, which has swapped sections 2 and 3 in the correlation_search_edit page, which makes more sense and is a welcome improvement. 

The entity field

As far as I can see, the entity field is just an alias for the good old risk_object field. In the rest of this post, I'm only talking about the risk_object field, but you can assume the entity field is a duplicate of it.

One entity - intermediate finding

This raises an event in index=risk with risk_object populated with what was configured (so here, the content of the user field).

This is what we call a risk-only rule. Straightforward.

The fact that the security domain is available to fill is a definite improvement over ES7, where all non-notable correlations' internal names matched the pattern  "Threat - * - Rule", which was annoying.

Even though the detection does not raise a finding/notable, it is super useful to be able to specify drilldowns. I've noticed these now appear in the "intermediate findings" popup that appears when the analyst clicks the number in the "intermediate findings" column in the analyst queue / mission control / incident_review / I wish they'd make their mind up. This is where the analyst can review the risk contributors (although in my tests it does NOT include notables... WTF) for a risk alert. The analyst can see a timeline and a list of all contributors. When expanding a contributor there is a tiny bit more information, as well as the opportunity to trigger the drilldowns. We have our own dashboard to do this better, but it's good to see it's improving. Next: please include workflow actions there too!

The title and description fields are not used anywhere (as far as I can tell). They are not recorded in the risk event, nor do I think they should. They should not be there at all.

One entity - finding

This raises an event in index=notable with risk_object populated with what was configured (so here the content of the user field).

I thought this was the equivalent of a notable-only rule, but since notables are included in the Risk data models, it effectively in some way becomes a notable AND risk rule.

I'm saying "in some ways" because:

• you need to query the Risk data model to see it. Any good old index=risk search will miss it

• it's not listed in the intermediate findings popup as mentioned above. That should be considered a bug and fixed urgently.

N/A entity- intermediate finding

This raises nothing, which is still a useful option to have if all you want to do is some other adaptive response action (section 9), such as sending an email etc. However, it is very confusing, as in this case most of section 2 and 3 is useless (except the security domain which impacts the internal name of the detection).

 N/A entity - finding

This raises an event in index=notable without risk_object populated.

This is a true notable-only rule. Straightforward.

Thank God this is an option. Not every detection should create a risk contributor. To start with, most of us still use event-based detections for the risk alert rules (at least until we figure out the new fancy but still "in preview" finding-based rules) and it makes no sense for one of these to add their own risk score. Besides that there are probably many other cases where a risk score just is not relevant. Some could be better implemented elsewhere than as a detection, but still the choice should be there. Don't presume you know better than the customer.

In this case, no need for the whole "entities and threat objects" section, they should not be there.

2 entities - both intermediate findings

This raises 2 identical events in index=risk but with different values for the risk_object, risk_score, etc, as configured.

This is basically a multi-risk rule. Straightforward.

Same comments apply as for "One entity - intermediate finding".

2 entities - both findings

This raises 2 identical events in index=notable, but with different values for the risk_object (and therefore 2 risk contributors in the Risk data model, kind of, depending on how you look)

It's really not clear why someone would ever want to do that. We spend an incredible amount of effort to REDUCE the number of alerts we have to deal with, we don't need a way to create more pointlessly. I thought maybe that could be useful if the two findings were to be dealt with by different teams (e.g. a use case that could be relevant to both the security team and the fraud team) but since the only difference between the two would be the risk_object I don't see how that would be a good way to do that.

+ same comments as for "One entity - finding"

2 entities - 1 finding, 1 intermediate finding

This raises one event in index=notable with the risk_object set to what the user field contains, and one event in index=risk with risk_object set to what the dest field contains. Effectively this is a notable + 2 risks rule (but the latter only when looking at the Risk data model).

I checked some of our existing rules that raised both a notable and multiple risks for what they are doing after the upgrade. Now that I understand the new system better, I would think it would do something like this (i.e. "2 entities - 1 finding, 1 intermediate finding"). Instead this is what it looks like:

Which actually maintains the exact same behaviour as before the upgrade (2 actual real events in index=risk).

2 entities - 1 finding, 2 intermediate findings

This raises one event in index=notable with risk_object set to what the user is, and two events in index=risk, one with risk_object set to the user and the other set to the dest.

This will introduce a duplicate when querying the Risk data model, so it's not a useful use case.

contributing_events_search

I've noticed this weird field in the events of index=risk. I can't figure out what it is for. All it does is rerun the detection and filter on the entity field (most often risk_object). It's clear it's not going to help find the events that contributed to the risk event. Maybe it would be better called "similar_events_search"?

Conclusion

There are some things I like, but also quite a bit of room for improvement.

I think it was a mistake to include notables in the Risk data model. It complicates the system a lot for no gain.

Here is how I would organise the correlation_search_edit page:

First I would put the security domain in section 1, because that impacts the name of the search and is completely irrelevant to what the rule does with findings, or intermediate findings, or even none of them.

Don't combine risks/entities and notables together.

Don't ingest notables in the Risk data model.

Instead, have a "raise a finding" switch, off by default. If enabled, the section to fill in things like title, description, next steps, etc, should then appear. Don't put things in this form that are not finding-related (e.g. the security domain) or that could be useful for both risks and notables (e.g. drilldowns).

Then have a "intermediate findings" switch, also off by default. If enabled, the section to fill risk_message, risk details (risk_object, risk_object_type, risk_score) as well as the threat object fields should appear.

Then have a section common to both/either findings and intermediate findings, only shown if either or both are enabled, where you put things like drilldowns, etc.

You might think the downside with this is "what is the analyst queue going to put in the entity column?", but I think that's an opportunity for better. The current system forces to choose only one entity per notable, even for rules that might raise multiple risks (e.g. typically one for user and one for dest). So instead the analyst queue should look at the config for the detection. If it's configured to raise a risk against both "user" and "dest" then put both of these in the entity (e.g. "gvasseur" and "lab_laptop1" ) with their risk score next to them (risk_score should NOT be a separate column).

Finally, regarding the "intermediate findings" popup that appears when the analyst clicks the number in the "intermediate findings" column:

• Good to see drilldowns in there, but workflow actions should also show up there.

• It should go without saying that the list of risk contributors should include... all the risk contributors. Included the misguided hopefully-soon-to-be-history index=notable risk contributors!