Detailed Explanation of the Alert Template Table
The Alert Template Table plays a critical role in the alert processing phase. Each alert requires a corresponding template to define how the system extracts observables from the raw payload. Without a predefined template, the system cannot process the alert and causes disruption to the execution of the remaining workflow processes.
The Alert Template Table contains the following fields- Vendor name, Alert Name, Template, Description, and the Case Type. This structure ensures that the system knows how to process different types of alerts from various vendors. Please do not change this table scheme to maintain system functionality.
The alert name parameter is mutually exclusive with the other parameters in the Deduplication Table
If the Name
parameter is selected as a deduplication parameter, it will cancel any other parameter and be used exclusively for the deduplication rule.
The %
symbol can be used as a wildcard in alert names. This means that you can substitute %
for any sequence of characters. This allows you to match multiple alert names without needing to specify each one exactly.
When the *
symbol is used in alert names, it indicates that the deduplication rule must be applied to all alerts that include *
in their name.
Here’s how the templates work:
Unique Template for Each Alert
Templates are Defined Using JSON
Template JSON Format Example
device.external_ip
) represents the location of the observable in the alert payload, while the value (e.g., "IP Address"
) specifies the type of observable.In this example, the alert payload looks like this:
Identify the Observable
In this example, we want to extract the email address (frodo@middleearth.com
) from the alert payload and store it as an observable of type User Email.
The email address can be found under:
Define the Observable Type
"User Email"
.Create the Path in the JSON Template
Build the Custom JSON Template
Apply the Template for Other Observables
"sender.emailAddress.name"
) and define the appropriate type (e.g., "User Name"
).Fill in the rest of the parameters
After creating the template, test it, using the Extract Observables Subflow, to ensure that the system correctly extracts the observables based on the path and type you defined in the template table.
For this example, the final JSON template looks like this:
In the “Alert Processed” widget within Case Management, if you receive a notification about “unmapped alerts,” it indicates that certain alerts need to be manually mapped. To resolve this, follow the steps outlined above to create custom templates based on the alert payloads.
Detailed Explanation of the Alert Template Table
The Alert Template Table plays a critical role in the alert processing phase. Each alert requires a corresponding template to define how the system extracts observables from the raw payload. Without a predefined template, the system cannot process the alert and causes disruption to the execution of the remaining workflow processes.
The Alert Template Table contains the following fields- Vendor name, Alert Name, Template, Description, and the Case Type. This structure ensures that the system knows how to process different types of alerts from various vendors. Please do not change this table scheme to maintain system functionality.
The alert name parameter is mutually exclusive with the other parameters in the Deduplication Table
If the Name
parameter is selected as a deduplication parameter, it will cancel any other parameter and be used exclusively for the deduplication rule.
The %
symbol can be used as a wildcard in alert names. This means that you can substitute %
for any sequence of characters. This allows you to match multiple alert names without needing to specify each one exactly.
When the *
symbol is used in alert names, it indicates that the deduplication rule must be applied to all alerts that include *
in their name.
Here’s how the templates work:
Unique Template for Each Alert
Templates are Defined Using JSON
Template JSON Format Example
device.external_ip
) represents the location of the observable in the alert payload, while the value (e.g., "IP Address"
) specifies the type of observable.In this example, the alert payload looks like this:
Identify the Observable
In this example, we want to extract the email address (frodo@middleearth.com
) from the alert payload and store it as an observable of type User Email.
The email address can be found under:
Define the Observable Type
"User Email"
.Create the Path in the JSON Template
Build the Custom JSON Template
Apply the Template for Other Observables
"sender.emailAddress.name"
) and define the appropriate type (e.g., "User Name"
).Fill in the rest of the parameters
After creating the template, test it, using the Extract Observables Subflow, to ensure that the system correctly extracts the observables based on the path and type you defined in the template table.
For this example, the final JSON template looks like this:
In the “Alert Processed” widget within Case Management, if you receive a notification about “unmapped alerts,” it indicates that certain alerts need to be manually mapped. To resolve this, follow the steps outlined above to create custom templates based on the alert payloads.