UNABLE to filter the fields in the security alerts window

[frank_rib]

Hello every body,
Many alerts are generated in the security Alerts window of elastic 8.3.1, Especially attempts of brute force:

The winlog. event_data. The TargetUserName field is the user-specific field.

I'm not able to filter through this field in the alerts window. I still receive blank results, even if the value exists.

Can you please assist me to resolve the issue?

Best regards,

[frank_rib]

Hello,
Can i find any expert to help me to resolve this issue?
Best regards,

[Venkata_Raja]

Hi frank,

are you filtering that data view in discover page ?

[frank_rib]

Hello Venkata,
Thank you for your feedback, Yes the filter has been applied on Discover, the results are well displayed unlike the security part. Regards,

[willemdh]

This a common issue with Elastic Security... In fact, Elastic will by default only allow you to filter on common ECS fields... Data in winlog.event_data is not usable in filters in Elastic security.

I think you could add these fields you need to the siem templates, but I fear these get overwritten every update..... In the good old times overriding a builtin template was peanuts, but with the new index and component templates a lot of problems were introduced taking away flexibility, because the builtin templates are overwritten when updating Elastic and there is no way to configure order anymore.

Personally I have no idea who came up with this implementation. We are running daily into this issue with several different non ECS fields... Some of them are really unlogic, for example SubjectUserName and TargetUserName are not converted to ECS fields and then used in the Security rules without allowing us to filter on them...

[elkn00b]

Hi frank_rib,

We had the same issue.

This is because the fields you want to search against aren't mapped in the Elastic Security alerts index.

You would have to update the .internal.alerts-security.alerts-<space-id>-NNNNNN index template to add the fields you want to be searched.

Note that to have the template update apply retrospectively, you'd have to re-index the .internal.alerts-security.alerts-<space-id>-NNNNNN index(es). If that's not a requirement and having the searchability apply from the time/date of change moving forward, just roll the index to it inherits the updates settings/mappings.

Hope that helps!

Best,

Matt

[willemdh]

@elkn00b
Does the template change survive updates?

[elkn00b]

@willemdh
We haven't tested that yet, but we're planning to make the custom settings/mappings defined in component templates and then just reference those component templates in the .internal.alerts-security index template.

We also think the direct edit to the system/hidden index might get lost in the update, but it'll be an easy re-add for the component template references. In theory...

Best,

Matt

[willemdh]

Thanks for your feedback. Imho Elastic really missed the ball while moving to component templates and taking away the ability to override builtin templates. Ive been trying to explain this problem to them for years, even before component templates were generally introduced, but for some reason, the choose to continue on this pad. I so miss the legacy templates...

[frank_rib]

Thanks elkn00b.This solve the problem