Map entities from Sentinel to ServiceNow

[theabb]

Hi ServiceNow Community,

I am currently working with mapping entities from Sentinel to ServiceNow using the plugin called Microsoft Sentinel (x_mioms_azsentinel). The problem is that the entities on the Sentinel tickets are being mapped to Work notes on ServiceNow SIR incidents instead of on the blade "Investigation" and then the related list called "Associated observables". 

The mapping is on the sn_si_incident table and we have been working with the following resources:

- Script Include called SentinelIncident

- Business rule called custom_mapping

All ideas are much apprecitated.

Kind regards,

Thea

[VaranAwesomenow]

@theabb looks like x_mioms_azsentinel is a custom scoped app and not one from store. You can refer to OOB sn_sec_sentinel and understand how the mapping is done and align to the same approach accordingly, to add little more insight this is the OOB scriptinclude and its functions

AzureSentinelSampleIncidentsAndEntities

This script includes a class named `AzureSentinelSampleIncidentsAndEntities` that inherits from `AbstractAjaxProcessor`. It's designed to interact with Microsoft Azure Sentinel, an advanced cloud-native SIEM, to fetch sample incidents and associated entities. Here's a breakdown of the script:

1. **Class Definition**: The class is defined with a constructor that initializes properties and extends the `AbstractAjaxProcessor`.

2. **getSampleIncidentsAndEntities Method**: This method fetches sample incidents and their associated entities from Azure Sentinel based on a provided profile ID. It first validates the profile ID and retrieves necessary configuration details. Then, it fetches an access token for authentication.

3. **Fetching Incidents**: The `_getSampleIncidents` method constructs a query to fetch incidents within a specified time frame and limits the result to a certain number (`max_incident`). It sends a REST API call to Azure Sentinel and returns the response.

4. **Fetching Entities**: The `_getEntitiesForIncident` method fetches entity data related to a specific incident. It first calls the `_alertsOrEntitiesRestCall` method to get entities or alerts and processes the response accordingly.

5. **Fetching Alerts**: The `_fetchAlertsForIncident` method fetches alerts associated with an incident. It determines the earliest alert and includes it in the payload.

6. **Determining Earliest Alert**: The `_getEarliestAlert` method finds the earliest alert from a list of alerts based on the timeGenerated property.

7. **Rest Call**: The `_alertsOrEntitiesRestCall` method constructs and executes a REST API call to Azure Sentinel for fetching alerts or entities.

8. **Mapping Entities**: Throughout the script, entities are mapped to a flat structure using the `flatten` method from `AzureSentinelUtils`. This structure is then included in the final output (`incidents`).

9. **Output**: The final output is a JSON string containing incidents and their associated entities, with a status indicating whether the operation was successful, incomplete, or resulted in an error.

In summary, this script connects to Azure Sentinel, fetches sample incidents, and their associated entities, and maps them into a structured format for further processing or display. The class and its methods work together to handle the entire process, from authentication and data retrieval to data mapping and output generation.

[AJ_UK]

If you have the SIR Module and are integrating with the SIR table, have you looked at the ServiceNow published integration:
Microsoft Azure Sentinel Incident Ingestion Integration For Security Operations - ServiceNow Store
https://store.servicenow.com/store/app/093bab2a1b246a50a85b16db234bcb97
It sounds like this integration would fit your use case more simply.
You can then configure what fields of the Entities map to what type of Observable in the Profile Mapping. Note that the Observables are not related by default though - it is structured as a 'flat table'