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:
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][“device.name”]}} |
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 |
{{$.SystemField.HostName}} |
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:
- Ingesting different alert structures from different data sources.
- Ingesting different alert structures from the same data source.
- 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.
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.
Two event sources, one from default and the other from machine learning detections.
Conditional search for detection source value. Wildcard searches are also possible.
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.
Conclusion
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.
