Satisnet Ltd, Basepoint Innovation Centre, 110 Butterfield Great Marlings, Luton, Bedfordshire, LU2 8DL
+44 (0) 1582 434320

QRadar Technical Blog: Adding Custom eMail formats

QRadar Technical Blog: Adding Custom eMail formats

QRadar Technical Blog: Adding Custom eMail formats

With the release of 7.2.6 the ability to create multiple eMail formats was implemented as an extension of the existing method for providing user-written versions.

Prior to this release, QRadar allowed multiple formats but only one was allowed to be active at any one time. This meant that there was one format for event rules and one for flow rules. The method of switching was to change a tagged parameter:

<active>false</active> to <active>true</active>.

There could only be one set to ‘true’ but if more than one was set, the first format was applied.

The first step is to copy the file /opt/qradar/conf/templates/custom_alerts/alert-config.xml to a specific directory which will be used later from which to stage the changed file.

As an example call the directory My_Mail_Template.

The default file contains two sections, one called Default Event and one called Default Flow. Both are treated exactly the same.

                <templatename>Default Event</templatename>

The First Section:










End of First Section

The Second Section

<![CDATA[The following is an automated response sent to you by the {AppName} event custom rules engine:


                Rule Name: ${RuleName}
                Rule Description: ${RuleDescription}

                Source IP: ${SourceIP}
                Source Port: ${SourcePort}
                Source Username (from event): ${UserName}
                Source Network: ${SourceNetwork}

                Destination IP: ${DestinationIP}                                                  
                Destination Port: ${DestinationPort}
                Destination Username (from Asset Identity): ${DestinationUserName}
                Destination Network: ${DestinationNetwork}

                Protocol: ${Protocol}
                QID: ${Qid}

                Event Name: ${EventName}
                Event Description: ${EventDescription}
                Category: ${Category}

                Log Source ID: ${LogSourceId}                                                                           
                Log Source Name: ${LogSourceName}

                Payload: ${Payload}

End of Second Section


The first section represents using default replacement values which correspond to the fieldnames as displayed in the second section.

For example, ${sem_ruleResponse_email_default_01} will be replaced with the value found in ${RuleName}, the first element in the second section.

${sem_ruleResponse_email_default_18} will be replaced with the value in the eighteenth element in the second section, ${Payload}.

The two entries in the first section could therefore be re-written just using the named value.

The copied file can either be downloaded to a PC editor or edited using vi or vim in the Linux command line interface. Care should be taken to preserve any changes already made to the template file.

In order to build a new format, the complete sections between the tads should be copied and placed after the last tag and before the final tag.

The format should be given a meaningful template name and the type set to event or flow. The tag should be set to true.

The text of the eMail should be laid out in a way that reflects the format required, as an example, the following is the complete format:

                <templatename>Mail Format Name</templatename>
                <subject><![CDATA[Subject Name Required]]>

Breach reported by ${body.CustomProperty("App_Title")} on an event named ${body.CustomProperty("Sample_Event")}.

This is a response to a breach indicated by the rule, "${RuleName}", being triggered by an event from ${body.CustomProperty("App_Name")}.

The breach was caused by ${UserName} working on workstation ${SourceIP} and occurred at ${StartTime}.

The severity of this breach is recorded as ${Severity} with a credibility of ${Credibility}.


This layout displays both types of data replacement, ‘body.CustomProperty’ indicates a user written property while entries without this prefix are properties provided by QRadar.

Having completed the layout, the file alert-config.xml should either be saved to the directory created earlier (vi or vim), example My_Mail_Template, or uploaded to the directory (PC editor).

The shell script /opt/qradar/bin/ should now be run, pointing to My_Mail_Template.

This will respond with: File alert-config.xml was deployed successfully to staging!

Now the change must be deployed from the Admin tab and when complete the email format will be available in the rules wizard.

We are currently offering a Free IBM QRadar Health Check, if this is something you are interested in then please get in touch today!