Import Sentinel ExtendedProperties in SecOps Incidents
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-11-2024 09:53 AM
We have been successfully importing Security Incidents from Sentinel through an integration, however, I am now trying to map new fields across. We want to start passing over metadata like the "Resolver Group" that the incident should be preassigned to, "Service" that the incident relates to, or other "Observables" that don't fit neatly into existing Sentinel Entities, like AWS account ID.
I have created an Analytic Rule in Sentinel that includes a test variable - Key=abc, Value=aaa in the picture below (I can't seem to make "Sentinel Entities" mapped into custom "entities" appear). According to documentation I've found, this should appear in the "extendedproperties", however, the data isn't available in the "Azure Sentinel Incident Field Mapping" page in ServiceNow, or the raw incidents that are ingested.
I have the sn_si.admin, but no elevated privileged outside of the SecOps Module, so I don't know what version of the integration we're running.
Any suggestions for where to turn next would be appreciated. Either how to get the ExtendedProperties available in ServiceNow, or if there is a better way to pass the information across.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-12-2024 05:08 AM
Hi Matt, I'm not able to view your screenshot.
I would not use the Custom variables. For the entities to be mapped, your analytics rules will need Entity mapping within the rule logic. For Sentinel Tables with Extended Properties/Entities, you will need to parse out the entities you want. Once a rule's entities are mapped they should show in the Incident Raw, which then is available to map into SIR.
For example if you extend ExtendedProperties or Entities from SecurityAlert to look for type = account, you can map that field from the query result to a Sentinel recognized entity. Once that rule is triggered, the incident is generated, then ingested into ServiceNow, the fields will map per your field mapping configuration. Below is an example of an Account entity mapping in Sentinel and what it can look like in the Incident Raw JSON.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-13-2024 07:31 AM - edited ‎06-13-2024 07:43 AM
Thanks for your speedy reply Martin,
I have tried Entity Mapping and have been able to add custom variables from KQL into Entities that are successfully passed across in the way that you' have demonstrated (using project to expose the variables I want).
However, none of the MS Entities (e.g. account that you showed) are suitable because I want to pass information like the "ServiceNow Resolver Group" that I expect the incident to be assigned to, or "environment" to say whether the incident is related to a Management/Prod/Non-Prod account.
I've tried:
- Using the "Sentinel Entities" option in "Entity Mapping", but the information doesn't appear in the Sentinel Incident like it does with one of the others (like Account).
- Using a custom key in "Custom Details" - which does show up in the Sentinel Incident, however, this information does not then appear in the Raw Incident in ServiceNow.
What am I missing, is there some additional incident importing code that I need to add to ServiceNow? Or is there something clever I need to do to get the custom entity to show up in the Sentinel Entity to show up in the Sentinel Incident?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-13-2024 11:05 AM
Per the Sentinel API docs, Custom Details is not available from the Incident, Alert, or Entity operations, so it won't be in the Incident Raw in ServiceNow. I do, however, see it in the Analytics Rules response - which isn't used in the ServiceNow Sentinel Integration.
To map say a ServiceNow Group to an entity field would not work since a group isn't recognized as a entity type. Something you could look at is put your custom requirements as tags or in the Alert Details.
Automation rule to set tag as "ServiceNow Resolver Group" : Map to ServiceNow Assignment Group
Alert Details; where you first extend your columns to whatever text and variables you need then call them in this section. This completely replaced the Alert Name and Description in the created Alert and Incident and reflects in the Incident Raw in ServiceNow
Alert Name: {{alert_env}} alert
Alert Description: Assign to {{alert_group}}