[RFC][Stage 0] Risk Input fields

[rylnd]

Summary

This RFC aims to add a few general fields that, when defined on a document, will allow that document containing them to be consumed by Kibana's Risk Engine for the purposes of entity analytics.

Broadly, we need two fields to enable this behavior:

• risk_score, a "base" risk score (numeric, float) defined by the data producer that is used as the basis for calculating risk for the entity represented in the document
• risk_category, a keyword field defining to which of the five proposed categories

[rylnd]

@ajosh0504 is there any overlap between the existing static_score field and the concept defined here?

[ajosh0504]

So we've defined static_score as follows:

A risk classification score obtained from outside the system, such as from some external Threat Intelligence Platform

Given the above definition, I think there could potentially be an overlap between the two, specifically if the data producer in the risk_score definition could be an external system. Might be good to clarify what data producer here entails.

[rylnd]

By "data producer" I mean "mechanism producing documents that intend to be scored by the risk engine." Did you intend for static_score to be used somehow in subsequent calculations, or is the intention more "display whatever is here as an auxiliary data point?"

I was mainly asking the original intention to make sure that I wasn't misinterpreting/ignoring the static_score field. If it has a distinct use case from the one I'm proposing in this RFC with risk_score, I think we should keep them separate.

[ajosh0504]

I want to say it's the latter i.e. auxiliary data point, but @MikePaquette was the one who proposed the static_risk_score field when I was working on the Risk Fields RFC so tagging him for confirmation.

[rylnd]

I spoke with @MikePaquette and he confirmed that static_score is broadly intended as we've described/assumed. Even if we incorporate it into future calculations, its purpose is distinct enough from the one I'm proposing that I think they both make sense 👍

[SourinPaul]

@rylnd What do we need to move this forward to the next stage?

[rylnd]

@rylnd What do we need to move this forward to the next stage?

@SourinPaul I think the main thing for stage 0 is just finding a sponsor, here.

There are broader questions about exactly which fields we would need, and validating those against current/future features (and future data sources, e.g. https://github.com/elastic/security-team/issues/3408), but I think that we can address those in Stage 1.

[SourinPaul]

I think the main thing for stage 0 is just finding a sponsor, here.

@rylnd Unless its a conflict of interest, please list me as a sponsor. Let me know if there are any concerns to proceed.

exactly which fields we would need, and validating those against current/future features (and future data sources, e.g. elastic/security-team#3408), but I think that we can address those in Stage 1.

👍 and agree.

[ebeahan]

LGTM for stage 0 ✅

Having a sponsor listed isn't necessary until later stages. I'll merge the PR as-is and a sponsor can be added in the next PR.