[imperva/securesphere] log.file.* fields mapped as long not keyword

[ebeahan]

log.file.device_id and log.file.inode are mapped as long in the imperva package. Other packages treat these values as identifiers and map the fields as keyword.

Also causing testing failures:

FAILURE DETAILS:
imperva/securesphere logfile:
[0] parsing field value failed: field "log.file.device_id"'s Go type, string, does not match the expected field type: long (field value: 68)
[1] parsing field value failed: field "log.file.inode"'s Go type, string, does not match the expected field type: long (field value: 98)

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[jamiehynds]

@piyush-elastic would you mind adding this to our backlog as it relates to the recent Imperva integration update?

[piyush-elastic]

@ebeahan - please find our analysis on this issue -

We checked the issue on the stack version 8.10.1 (As the minimum stack version for the Imperva SecureSphere is 8.10.1), and it's causing testing failure if we map the log.file.device_id and log.file.inode as keyword hence decided to put it as long.

Checked on the recent version 8.11.0 and found that it's causing testing failure for the same build if we use the log.file.device_id and log.file.inode as long.

Seems like the data types got updated to the keyword in the recent version. Please find attached response for bot versions
sample_event_8.11.json
sample_event_8.10.1.json

[ebeahan]

Beats recently added log.file.device_id and log.file.inode into the fields produced by the filestream input: elastic/beats#36065.

These field's weren't defined in the mappings of any integrations using the filestream input, and adding the mappings was tracked in #7687. I suspect since the work for #8237 was happening in parallel, the fields were added using long instead of keyword and missed in the work for #7687.

I propose we make a breaking change to the imperva package for these two fields to use keyword (to align with what's been done in other integrations). This will prevent a field type mismatch error when querying log.file.device_id or log.file.inode across imperva and other integration indices.

[piyush-elastic]

@ebeahan - We have raised PR for the same.

[elasticmachine]

Package imperva - 0.20.1 containing this change is available at https://epr.elastic.co/search?package=imperva