[Enhancement] Clarify event.severity Description to Recommend Elastic Security Scale

[raqueltabuyo]

Clarify event.severity Description to Recommend Elastic Security Scale

Summary

The current description of event.severity does not clearly specify a recommended scale, leading to inconsistent mappings across third-party integrations. This issue proposes updating the event.severity description to explicitly recommend following Elastic Security’s standardized severity scale:

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

Risk score

This clarification will help ensure consistency in severity representation across Elastic Security environments.

---

Motivation

Currently, the lack of a standardized reference in the event.severity description has led to inconsistent implementations across different integrations. Developers working on third-party data ingestion have mapped severity values based on their own interpretations, leading to misaligned severities across alerts.

For example, some integrations have been assigned a different numeric scale (e.g., Microsoft Defender for Endpoint currently has 1-4, while SentinelOne and CrowdStrike have assigned other different scales), which results in incorrect severity representations in Kibana.

By explicitly recommending the Elastic Security severity scale, developers will have a clear reference to correctly map third-party severities, ensuring a consistent experience across all sources.

---

Detailed Design

Proposed Changes to event.severity Description:

Current Description:

The numeric severity of the event according to your event source.

What the different severity values mean can be different between sources and use cases. It’s up to the implementer to make sure severities are consistent across events from the same source.

The Syslog severity belongs in log.syslog.severity.code. event.severity is meant to represent the severity according to the event source (e.g. firewall, IDS). If the event source does not publish its own severity, you may optionally copy the log.syslog.severity.code to event.severity.

---

Proposed Updated Description:

The numeric severity of the event according to your event source.

To ensure consistency across Elastic Security, it is recommended to map severity values to the Elastic Security severity scale:

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

This ensures uniform severity representation across different event sources. Implementers should normalize third-party severities to this scale when possible.

The Syslog severity belongs in log.syslog.severity.code. event.severity is meant to represent the severity according to the event source (e.g. firewall, IDS). If the event source does not publish its own severity, you may optionally copy the log.syslog.severity.code to event.severity.

---

Example Values:

Third-Party Source	Original Severity	Recommended event.severity Mapping
Microsoft Defender for Endpoint	Informational	21 (Low)
Microsoft Defender for Endpoint	Low	21 (Low)
Microsoft Defender for Endpoint	Medium	47 (Medium)
Microsoft Defender for Endpoint	High	73 (High)
SentinelOne	Low	21 (Low)
SentinelOne	Medium	47 (Medium)
SentinelOne	High	73 (High)
SentinelOne	Critical	99 (Critical)

---

This update will provide clear guidance to developers, reducing mapping inconsistencies and ensuring a standardized severity approach across Elastic Security.

[approksiu]

I think there is a confusion here between severity and risk score. Severity options: low, medium, high, critical. Risk score - scale from 1 to 100. In the prebuilt detection rules we use the following mapping:

• low - 21
• medium - 47
• high - 73
• critical - 99

[raqueltabuyo]

Thanks @approksiu , sorry if it was not clear enough. The issue here is that severity is a numerical value so we are proposing adding a recommendation in the ECS documentation inside the event.severity description to follow the same mapping as the prebuilt detection rules, in that way we can avoid future issues due to inconsistencies between the data ingested and the rules.

[MikePaquette]

Thanks team, I think a standard way to map the provided data source severity value to event.severity is a good enhancement to ECS, and updating all our integrations to follow this standard mapping would be a good improvement to our users' experience.

A few suggestions:

1. Let's consider adding this as a recommendation, rather than a breaking change. There is a precedent for ECS making a recommendation (e.g., event.dataset)
2. We should provide guidance for when the source severity field is numeric - do we pass it along to event.severity (this seems like the original intent of event.severity.) Or do we "round up" numeric values to the next defined value? (See the diagram below for the impact to detection alerts when the detection rule severity override is set if we don't do this "round up.")

[approksiu]

Thanks @approksiu , sorry if it was not clear enough. The issue here is that severity is a numerical value so we are proposing adding a recommendation in the ECS documentation inside the event.severity description to follow the same mapping as the prebuilt detection rules, in that way we can avoid future issues due to inconsistencies between the data ingested and the rules.

I see I looked at the alert severity.

[raqueltabuyo]

@MikePaquette great points, below my answers.

Thanks team, I think a standard way to map the provided data source severity value to event.severity is a good enhancement to ECS, and updating all our integrations to follow this standard mapping would be a good improvement to our users' experience.

A few suggestions:

1. Let's consider adding this as a recommendation, rather than a breaking change. There is a precedent for ECS making a recommendation (e.g., event.dataset)

The breaking change is not for the description but the fact that some customers might use the current values of event.severity for some integrations. For example, the current value of event.severity for high alerts in Microsoft defender for Endpoint integration is 4, a customer could have already created a custom rule with the value of 4. If we modify that value from 4 to 73, that specific custom rule will be affected by this change.

3. We should provide guidance for when the source severity field is numeric - do we pass it along to event.severity (this seems like the original intent of event.severity.) Or do we "round up" numeric values to the next defined value? (See the diagram below for the impact to detection alerts when the detection rule severity override is set if we don't do this "round up.")>
   

Great point, definitely we need to transform those numeric values too. I think it would be more exceptional but it would be good to know the scale of that specific third party in advance, before any mapping. Usually if the scale is from 0-10, they would probably follow CVSS scale. Therefore, if we have numeric values as the original source, we can:

• Consider CVSS if the scale is 0-10 and match it to the corresponding CVSS 3x/4x Severity, after that, transform it to the corresponding Elastic severity. Example: source severity=7.8--> cvss_severity=High --> event.severity=73.
• If it is a different scale, refer to the third party documentation and map event.severity to the corresponding severity.
• If it is a different scale and there is no documentation, round up event.severity to the nearest value.

[MikePaquette]

The breaking change is not for the description but the fact that some customers might use the current values of event.severity for some integrations. For example, the current value of event.severity for high alerts in Microsoft defender for Endpoint integration is 4, a customer could have already created a custom rule with the value of 4. If we modify that value from 4 to 73, that specific custom rule will be affected by this change.

OK, so there is no breaking change to ECS, but each integration that changes its behavior may constitute a breaking change for the integration, right?

[raqueltabuyo]

The breaking change is not for the description but the fact that some customers might use the current values of event.severity for some integrations. For example, the current value of event.severity for high alerts in Microsoft defender for Endpoint integration is 4, a customer could have already created a custom rule with the value of 4. If we modify that value from 4 to 73, that specific custom rule will be affected by this change.

OK, so there is no breaking change to ECS, but each integration that changes its behavior may constitute a breaking change for the integration, right?

Yes, that's exactly the issue.