Standard Ontology and SIEM Field Mapping

HeyManishaPatil​ ,

I don’t have experience with Chronicle so I’d recommend first investigating if there are any native parsers thought I doubt they’d meet your requirements. Each table you’re ingesting from Sentinel is going to have its own unique schema. This why you see some KQL with join statements like ‘join <t> on $left.principaluseremail == $right.userprincipalname’

As for API/PowerShell module to help you build out automation, pick your preference: 

1. Rest API: https://learn.microsoft.com/en-us/rest/api/loganalytics/tables/get?view=rest-loganalytics-2025-02-01
2. PowerShell module: https://learn.microsoft.com/en-us/powershell/module/az.operationalinsights/get-azoperationalinsightstable?view=azps-14.3.0 

Either should help you get metadata on the tables and their columns that you need. 

Depending on the amount of data and/or  varying data connectors you have configured, you might want to consider normalizing the data before mapping. Not only could this effort help make your data easier to map over but it could great improve its operational effectiveness within Sentinel. https://learn.microsoft.com/en-us/azure/sentinel/normalization 

Best regards,

Dylan

hi ManishaPatil​  ​You're absolutely on point , mapping fields between Microsoft Sentinel and Google Chronicle (via Chronicle's Unified Data Model, or UDM) is critical for analytic portability and context. Let's break down your options for automating this:

Field Mapping: Sentinel → Google Chronicle (UDM)

Google Chronicle (SecOps) supports ingestion of Sentinel data via feeds that include built-in default parsers. These parsers map Sentinel log or alert fields into Chronicle’s UDM, including fields like principal, security_result, metadata, and more.For incidents and alerts, these are managed via feeds configured in the Chronicle UI, using e.g. webhook sources pointing to Sentinel

Automating & Customizing Field Mapping

Playbooks / Logic Apps

Use Sentinel playbooks (via Azure Logic Apps): These can be triggered by incidents or alerts and can extract Sentinel data using the Sentinel REST API, transform fields, and forward them—e.g., to Chronicle via HTTP webhooks or other feeds

In the Logic App, you can manipulate field names and hierarchy to align with Chronicle’s expected UDM field names

REST APIs

Sentinel offers REST API endpoints (List Incidents, Get Incident Entities, etc.) that you can call to retrieve structured incident and alert data

Combined with Logic Apps or PowerShell, these APIs let you pull data, transform/match fields like UserPrincipalName to Chronicle’s principal.user.email, then post to Chronicle feeds.

PowerShell Automation

Community-authored PowerShell scripts exist to extract Sentinel automation rules and incident metadata via Azure PowerShell or REST API, which you could adapt to extract raw log JSON and remap fields

You can script retrieval of alerts or incidents, process mappings, and push them to Chronicle’s ingestion endpoint.

Scheduled Feeds via Chronicle

Chronicle supports scheduled ingestion (e.g., pulling logs from Azure Blob Storage or via direct connectors) and field mapping as part of its parser logic

You could export relevant Sentinel data to Azure Blob Storage, and configure Chronicle to periodically ingest and map those fields.

Recommendations

Start with Chronicle’s built-in Sentinel parser, which handles standard mapping—ensure your log sources match supported types

If you need precise control or custom field mappings, build a Logic App playbook:

• Trigger on alert or incident creation.
• Extract with Sentinel API.
• Map fields (e.g., UserPrincipalName - principal.email).
• Send transformed log to Chronicle via webhook feed.

Alternatively, script with PowerShell or Azure Functions:

• Use Sentinel’s REST API to fetch incidents.
• Apply transformations.
• Forward to Chronicle.

For larger batches or offline scenarios, export to Blob Storage and let Chronicle poll/import with custom mapping rules