Normalize Third-Party EDR Alert Severity to Elastic’s Severity Scale

[raqueltabuyo]

Normalize Third-Party EDR Alert Severity to Elastic’s Severity Scale

Summary

Currently, third-party EDR integrations (e.g., Microsoft Defender for Endpoint, SentinelOne, CrowdStrike) use different severity scales. However, when their data is ingested into Elastic Security, there have been inconsistencies in how severity values are mapped, leading to incorrect severity assignments instead of aligning with Elastic's predefined scale.

This issue proposes applying a standardized transformation to normalize severity values before parsing data into ECS, ensuring consistency across all alerts.

---

Problem Statement

Elastic Security assigns fixed numeric values for event.severity, as defined in the official Elastic Security detection rules:

• 21 = Low
• 47 = Medium
• 73 = High
• 99 = Critical

Risk Score

However, each third-party EDR uses its own severity scale, and there is no uniform approach to parsing these values into ECS. In some cases, severity has been incorrectly assigned or inconsistently mapped instead of following Elastic’s standardized scale.

For example:

• Microsoft Defender for Endpoint (MDE) and M365 Defender use a Informational, Low, Medium, High scale. MDE Severity
• SentinelOne: uses Low, Medium, High, and Critical.

• CrowdStrike: uses Info, Low, Medium, High, and Critical. Crowdstrike Severity mapping

• These integrations have assigned default values or mapped severities in a way that does not align with Elastic’s scale.

As a result, alerts from these sources may not reflect their actual severity, impacting prioritization and response workflows.

---

Proposed Solution

Apply severity transformation rules to normalize third-party severity values before parsing them into ECS, ensuring they align with Elastic’s official severity scale.

Implementation Steps

1. Analyze current mappings used for MDE, SentinelOne, and CrowdStrike.
2. Define a standardized transformation for each integration, ensuring alignment with the official Elastic event.severity scale.
3. Implement transformation logic in the ingestion pipeline to convert third-party severity names (String) to Elastic’s numeric scale.
4. Test severity mappings with sample alerts to validate accuracy.
5. Document the severity mappings to ensure consistency for future integrations.

Example Mapping for SentinelOne

SentinelOne Severity	Elastic Severity	event.severity
Low	21 (Low)	event.severity=21
Medium	47 (Medium)	event.severity=47
High	73 (High)	event.severity=73
Critical	99 (Critical)	event.severity=99

Similar mappings will be created for Microsoft Defender for Endpoint (MDE) and CrowdStrike once their scales are validated. In the case there are Informational and Low severity levels, use the same value (21) for both.

---

Acceptance Criteria

• Identify and correct inconsistencies in severity mapping for MDE, SentinelOne, and CrowdStrike.
• Standardize transformation rules to align third-party severities with Elastic’s event.severity scale, as referenced in Elastic Detection Rules.
• Implement the transformation logic in the ingestion pipeline.
• Validate the mapping using test alerts to ensure proper severity classification.
• Document severity mappings for future reference.

---

Future actions

• Identify and correct inconsistencies in severity mapping for other integrations.
• Follow the same process as above for new inconsistencies.

---

Examples

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)