Description in ESA SMTP Template

[MaximMarchenko]

Hello.

How can I include Description Field of ESA Rule in ESA SMTP Template.

I've tried ${description} and ${description?html} - Health&Wellness generates error.

Is there the list of variables/fields/metas that I can Include in SMTP Template.

[JoshRandall]

Maxim Marchenko‌

Unfortunately, the ESA rule's description is not included in the raw alert data, so there is no way to add this information to SMTP (or any other) ESA outputs.

The fields included in any ESA alert can be seen within Respond-->Alerts by clicking on any of the alert name hyperlinks and viewing the JSON in the Raw Alert pane:

Alternatively, you can output all the available variables with a simple template like this:

<#list .data_model?keys as key>
  ${key}
</#list>‍‍‍

...which you can use in any of the alert notification outputs:

For simple reference, these are:

• events
• statement
• moduleName
• id
• engineUri
• instanceId
• time
• severity
• notificationReasons
• respondEnabled
• eventSourceId
• actualEventsCount
• suppressNotification
• suppressMessageBus
• transientAlert
• moduleType
• moduleId

[MaximMarchenko]

Thank you for the answer.

Appears that Description Field in ESA Rule is pretty useless as it can be.

For Respond team: it neither appears in Respond - Alert nor in Alert Email, it only can be seen in ESA Rules list.

I really wish it can be added in SMTP Template, cause it can be especially be useful for non-English speaking Respond team members.

[JoshRandall]

One option for you, if you're able to put the extra time in to adjust your existing ESA rules, is to convert any/all alerts you want to have a description field to Advanced Rules, and add a @Name annotation to each of them. Alerting: ESA Annotations 

Note: You can specify any number of meta keys in the statement for dynamic statement name generation.
The length of individual meta key is limited to 64, after which the value is truncated and appended with “…”.
The length of the dynamic generation of statement name is limited to 128, after which the value is truncated to 128 and appended with “…”. All the remaining values post truncation will be treated as static values.

While this annotation is not intended for long descriptions (128 character max length), I don't see why it can't be repurposed to meet (most of) your need.

As an example, I have rule like this:

...which generates alerts like this:

...where the ESA Rule Name becomes the alert moduleName field, and the @Name annotation becomes the statement field....and the statement field is already part of the default SMTP template:

We can do more with that statement field, like incident aggregation, but I'll leave that aside for now.

[MaximMarchenko]

Thank you for reply.

I know about using {statement} in Rule's Name and it's very useful.

But I use it to insert some important meta to see it first in email.

Description field are more detailed and tells about rule itself for the Respond team(SOC Analysts) in Russian(in my case).

So it would pretty useful to use content of Description field, because I can't use Cyrillic symbol in Rule Name: can't deploy such rule or it even doesn't appear(and work) in Services tab of ESA Rule..