[sentinel_one] Enhance ECS Mappings and Unify Field Structures across all Data Streams

[mohitjha-elastic]

Proposed commit message

sentinel_one: Enhance ECS mappings and unify fields across all data streams.

Refined and expanded ECS field mappings to ensure consistency across all data streams. 
Aligned field names and structures with the latest ECS standards to improve interoperability, 
data quality, and search normalization in Elastic SIEM.

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.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

How to test this PR locally

• Clone integrations repo.
• Install elastic package locally.
• Start elastic stack using elastic-package.
• Move to integrations/packages/sentinel_one directory.
• Run the following command to run tests.

elastic-package test -v

Related Issue

• Closing Sentinel One: ECS compatibility #15723

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 3628d67

cc @mohitjha-elastic

[kcreddy]

@cpascale43 can you confirm if this requires a dashboard changes as well?

[kcreddy]

I don't like that we are copying same value into 2 different fields with this change:
sentinel_one.activity.data.threat.classification.source and sentinel_one.threat_classification.source
Same with: sentinel_one.activity.site.name, and sentinel_one.site.name and several others.
Is this to avoid breaking-change?

It is mentioned here that this is worthy to be considered as a breaking-change, with updates to dashboards. @cpascale43 can you confirm if its still the case?

If its going to be a breaking-change, then we should ideally remove the previous fields sentinel_one.activity.data.threat.classification.source, sentinel_one.activity.site.name, etc. unless preserve_duplicate_custom_fields is true.

I checked the pre-built detection rules for sentinel_one and there is no effect there if its a breaking-change.

[mohitjha-elastic]

Yes, only a few fields are currently being copied into the sentinel_one.* namespace. We decided to keep the existing fields to avoid introducing breaking changes that could impact existing users.

I’ll wait for @cpascale43's suggestion on this. If we can treat it as a breaking change, we can proceed with removing the old fields and updating the dashboards if needed.

[kcreddy]

Can you add this to changelog and commit message?

[mohitjha-elastic]

It was added here to avoid CI failures since the related PR hadn’t been merged yet. As that PR has been merged today, this change will disappear once I sync the latest updates.

[kcreddy]

Can you confirm if site.id and site.name is not available in all data streams as per API reference, or if we just ignored adding to the pipeline and hence ignored here as well ?

[mohitjha-elastic]

We had ignored this since it’s not present in the pipeline neither in the test samples. I’ll review the API documentation again to verify whether these fields exist in the data streams and will update both the pipeline and this if needed.