[Enhancement] Add ".caseless" fields to process events

[w0rk3r]

Proposed commit message

This PR adds .caseless fields for the process name and executable to improve compatibility with our Elastic Defend integration. This enables us to handle language limitations in KQL more effectively.

I'm also specifying the .text field as it was being removed from the markdown file otherwise.

Elastic Defend Mapping:

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

How to test this PR locally

Build the integration, ingest sysmon or windows security logs.

Related issues

• Resolves [Enhancement] Field adjusts to better compatibility with Detection Rules #9234
• Resolves Add process.name.caseless to logs-system.* mapping #8913

Screenshots

[elasticmachine]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[ishleenk17]

@w0rk3r : Can we please get the CI green here ?

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 966e61c

History

• 💚 Build #11560 succeeded b46da49
• 💔 Build #11507 failed 8552c3a
• 💚 Build #11394 succeeded ef874f1

cc @w0rk3r

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[andrewkroh]

This introduces a new field into an ECS controlled namespace that is not defined in ECS. We need to commit this to the schema first so that it becomes standardized. This will allow us to use a uniform definition everywhere and it's easily importable.

# fields.yml
- name: process.executable
  external: ecs

This additional multi-field will end up in the Elasticsearch ecs@mappings template meaning that all users of data streams can have a consistent mapping for these fields (even if they aren't using an integration).

Probably one reason that we have incompatibility with detection rules (#9234) is that the rule(s) are using fields which have not been defined in ECS. So if we can align ECS then any future integrations will just work.

---

I also think we should debate alternative naming. My initial reaction was that calling this "lowercase" would be more clear because it conveys the fact that the value is being converted to lowercase.