Alert Normalization the Smart Way

Normalization plays a key role in the automation process for enterprise incident response and MSSP service delivery. How (or if) your SOAR tool converts different alert structures into a standard format can make or break your automation project.

Here is an example that illustrates why: Say you are building a playbook to get extra information on a machine. You want to extract the machine name from the alert and then run it through an Active Directory command to get related information. In this case, you have three different data sources that include machine names in their alerts. The structure of the ingested JSON object from each data source is as follows:

An screenshot illustrating the structure of sample JSON objects that include hostnames from three different data sources

Configuration Required Without Normalization

To extract the machine names from the alerts from all three data sources in one playbook, you would need to configure the same command requiring hostnames as an input parameter three times, each with the corresponding JSON path as summarized in the table below.

Input JSON Path for the Hostnames Input Parameter
Alert 1    {{$.[“Alert 1”].hostname}}
Alert 2    {{$.[“Alert 2”].value.hostname}}
Alert 3    {{$.[“Alert 3”].evidence[0][“”]}}

Configuration Required With Normalization

All three data sources can be configured to send the hostname value to a system field in D3 called HostName. For example, the data source for Alert 1 will be configured to map the source field .hostname to the HostName system field. For Alert 2 the source field would be .value.hostname. The same logic applies to Alert 3.

With the normalization configured, you would only need to configure one command in your playbook that requires hostnames as an input parameter by defining it with the system field JSON path:

   Input JSON Path for the Hostnames Input Parameter
All mapped HostName
system fields

The value of properly configured normalization increases with the number of data sources and playbooks you need to manage for your use cases, or in the case of MSSPs, your clients.

There are some common scenarios that not many vendors tell you about during your SOAR procurement process:

  1. Ingesting different alert structures from different data sources.
  2. Ingesting different alert structures from the same data source.
  3. Ingesting alerts from the same data source with variable formats.

If your SOAR tool cannot handle these scenarios, and you are forced to create unique automation workflows for each one, you will run into a wall of complexity six months into the implementation and your SOAR solution will become a barrier to, rather than an enabler of, growth.
There are three ways to configure normalization in Smart SOAR to address these scenarios, each with varying complexity. It’s best to use the easiest for your use case. Below, I’ll go into detail about each method.

Ingesting Different Alert Structures from Different Data Sources

This is the easiest issue to solve, and one that most SOAR vendors will be able to handle. All integrations that are used as data sources have static field mapping that comes out of the box, and can be changed by the platform engineers. Important fields from the data source are pre-mapped to Smart SOAR’s data model.
Event field mapping from SentinelOne in Smart SOAR
For each data source, the Source Field can be customized to the data point’s location, while the Field Name value can remain consistent. This will ensure that artifacts from your different data sources will be mapped to the same field.

Ingesting Different Alert Structures from the Same Data Source

If the data source you’re pulling from has different types of detection rules, or tables that store your alerts, you may see alerts from the same data sources that are different. In this case, you can use D3’s Event Source feature in the field mapping. For example, Elastic SIEM has standard detections and others that are generated from Elastic’s machine learning logic. Depending on the detection source, the alerts will look different. In Smart SOAR, you can define a new Event Source for the Elastic integration, as well as a conditional search that will be checked on ingestion. Depending on the result of this check, the appropriate field mapping will be applied.
Using Smart SOAR's Event Source feature in the field mapping
Two event sources, one from default and the other from machine learning detections.

Conditional search for detection source value. Wildcard searches are also possible.

Event field mapping for machine learning detections in Smart SOAR

Unique event field mapping for machine learning detections

Ingesting Alerts from the Same Data Source with Variable Formats

In some cases, values you’re looking for may appear in one of two or three different places inside your data. In this case, static event field mapping wont work. You’ll need to dynamically select the path on ingestion and add it to D3’s data model before it reaches the incident playbook. This is a unique use case for Smart SOAR’s event playbook, the automation layer that runs on ingestion.

Here, you can see three different paths for the hostname value, then an “if” statement to populate a standard field with the correct value. Once the alert passes through the event playbook, the data will be standardized and ready to be processed by one of your central incident response playbooks.


The effectiveness of your SOAR solution is intrinsically tied to the power of its normalization capabilities. The way your SOAR tool standardizes disparate alert structures into a unified format is a critical factor for the success of the implementation.
When properly executed, normalization drastically reduces the number of playbooks you have to manage. It facilitates extraction of key information from alerts and optimizes the execution of playbook commands, while maintaining a consistent structure across different data sources.

As we demonstrated, Smart SOAR’s advanced normalization features address various scenarios that can stall an MSSP’s automation project. SOAR is not just about automation. It’s about smart, strategic automation that makes your security operations more efficient and effective.

Social Icon
Pierre Noujeim

Pierre Noujeim is a Product Marketing Manager with a cyber security engineering background. Having implemented SOAR at enterprise organizations as well as for D3's MSSP partners, Pierre has rich and varied insight into integrations, use cases and the cyber security vendor landscape. A dedicated product marketer, Pierre represents D3 at analyst briefings, webinar workshops and industry conferences such as RSA and Black Hat.