[Security Solutions][Detection Engine] Changes wording for threat matches and rules

[FrankHassanabad]

Summary

Changes the wording for threat matches and rules

cc @marrasherrier @MikePaquette @paulewing

Before:

After:

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support

[shimonmodi]

@FrankHassanabad - following up on the updates for threat match rules UI. I have synced with @MikePaquette and we are aligned on there.

1. Descriptive text "Use indicators from intelligence sources to detect matching events and alerts."
2. Update tile title to "Indicator Match". Reasoning: we can address more use cases related to watch lists & block lists, by calling it Indicator Match rule type.
3. Change "Threat Index Patterns" -> "Indicator Index Patterns"
4. Change "Threat Index Query" -> "Indicator Index Query"
5. Change "Threat Mapping" -> "Indicator Mapping"

There is also a UI flow change we want to propose. Effectively its a repositioning of existing selections to make it easier to use the feature:

1. User selects Index Patterns and Threat Index Patterns
2. Next, User selects Threat Mapping Field (dropdown list) and Threat Index Field (dropdown list).
3. Next, user can fill in Custom query bar and Threat Index query bar. This would be for advanced users who want to further filter the datasets being matched.
   Reasoning: Most users will only want to specify Threat Mapping Field and Threat Index field as part of the rule definition. There could be advanced users who want to apply additional filters, but we want to avoid starting a user with an advanced rule workflow.
   If this would be better discussed over a quick call let me know.

[FrankHassanabad]

Next, user can fill in Custom query bar and Threat Index query bar. This would be for advanced users who want to further filter the datasets being matched.

@shimonmodi we currently require the custom query to be filled in for threat matching feature. Should we change that to be defaulted to *:* like we have threat lists so it's not required but rather defaulted when the user selects the card?

[MikePaquette]

Thanks @FrankHassanabad those screen shots look good, but there seems to be one more location where threat needs to be changed to indicator as shown here:

we currently require the custom query to be filled in for threat matching feature. Should we change that to be defaulted to : like we have threat lists so it's not required but rather defaulted when the user selects the card?

Yes, that would be fine, and should always work, but is a very broad query - guaranteed to return all events.

Could there also be an optimization, with a possible performance improvement, by waiting until the rule author selects the indicator mapping field(s), e.g., source.ip, and then populating the custom query with source.ip: * ? Of course, this would get a bit more complex if ANDs and ORs are specified.

[shimonmodi]

I would like to evaluate if Mike's suggested optimization is a possible way forward.

[FrankHassanabad]

Thanks for the catch on the fields missing a value, I will fix that and update the screenshots!

Yes, that would be fine, and should always work, but is a very broad query - guaranteed to return all events.

Ok, I will let you know if there's anything tricky or weird when I change it as it is a shared component but I think I can manage it without too much hassle.

Could there also be an optimization, with a possible performance improvement, by waiting until the rule author selects the indicator mapping field(s), e.g., source.ip, and then populating the custom query with source.ip: * ? Of course, this would get a bit more complex if ANDs and ORs are specified.

Yeah, that would be bug prone through ambiguity of DSL parsing, but I have good news already. When the filters from the threat list are applied along with any query against the indexes it turns into just one ES translated query that is just as optimal as something like, source.ip: * when it queries the events/logs.

For example if the user has a query of, *:* but and then specified source.ip -> source.ip against their threat mappings and the mappings return a source.ip of say, 127.0.0.1 then it will create a ES query that would become source.ip: 127.0.0.1 which is the exact match we're looking for so the source.ip: * won't add additional perf as we are as efficient as we can be against the large amount of events.

[FrankHassanabad]

It turns out that adding a default for the query and changing the UI flow are hard and risky things because of component coupling.

I am going to keep the naming separate from these two work items. I have created a new draft PR that already has the defaulting of the query done here but I don't think we should mix these harder things with renaming for 7.10.0 right now since they are showing to require more code than we want.

New PR for the defaulting of the query when selecting the indicator match:
#81727

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 65390bd

Metrics [docs]

async chunks size

id	before	after	diff
securitySolution	8.1MB	8.1MB	+25.0B

History

• 💔 Build #83536 failed ef0cf3b
• 💚 Build #83533 succeeded da62998
• 💔 Build #83498 failed 684c0f5
• 💚 Build #83087 succeeded fa7e558

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[yctercero]

LGTM! Super duper nit thing on wording. 👍

[yctercero]

Super duper nit:

Suggested change

	"name": "Query with a indicator mapping",
	"name": "Query with an indicator mapping",

[FrankHassanabad]

Crap missed this after the merge! Thanks though, this shows the level you're looking at the code. I appreciate it. Always nervous of making simple slip ups in the UI.