ASIM Parser in sentinel, I want to understand it and its typical usecases, for log ingestion and normalization

ASIM in Microsoft Sentinel is a normalization layer between diverse source telemetry and the analyst experience. It standardizes different products’ logs into common schemas and normalized field names so the same analytics rules, workbooks, hunting queries, and investigations can work across multiple data sources.

ASIM parsers are the main mechanism for this at query time:

• They are KQL user-defined functions.
• They transform data from existing tables such as CommonSecurityLog, Syslog, or custom tables into an ASIM normalized schema.
• They let queries use normalized fields instead of source-specific column names.
• Built-in parsers are available in every Microsoft Sentinel workspace.
• Workspace-deployed parsers can also be deployed with an ARM template and are mainly used for parser development, management, or modified versions of built-in parsers.

Typical ASIM use cases:

1. Cross-source detections
   One analytic can detect the same behavior across multiple products and environments. The documented examples include detections such as brute force or impossible travel across on-premises and cloud systems.
2. Source-agnostic content
   Queries and detections written against ASIM can automatically apply to any source that supports the same schema, including sources added later.
3. Custom source normalization
   Custom logs can be mapped to an ASIM schema so they can participate in built-in or custom analytics using the same normalized fields.
4. Simpler query authoring
   Analysts learn one field model per schema instead of different field names for each vendor or table.

Technically, ASIM is built from these components:

• Normalized schemas: standard event models such as Alert Event, Audit Event, Authentication Event, DHCP, DNS, File Activity, Network Session, Process Event, Registry Event, User Management, and Web Session.
• Query-time parsers: KQL functions that normalize existing data when queried.
• Ingest-time normalization: transforms events during ingestion into native normalized tables for better query performance.

About using ASIM functions in scheduled queries, NRTs, and other queries:

Yes—ASIM parsers are intended to be used in Microsoft Sentinel queries instead of table names to view data in normalized format and include all relevant data for that schema. The documentation explicitly states they are used in queries, and ASIM-normalized data can be used in analytics, rules, workbooks, and queries.

For example, the unifying parser pattern is:

• _Im_<schema>

Examples from the documented parser list include:

• _Im_Authentication
• _Im_Dns
• _Im_NetworkSession
• _Im_FileEvent
• _Im_RegistryEvent
• _Im_UserManagement
• _Im_WebSession
• _Im_ProcessCreate
• _Im_ProcessTerminate

A documented DNS example is:

_Im_Dns(starttime=ago(1d), responsecodename='NXDOMAIN')
  | summarize count() by SrcIpAddr, bin(TimeGenerated,15m)

That pattern is suitable anywhere a Sentinel KQL query is used, because the parser is a KQL function over normalized data.

Important technical guidance for using ASIM parsers effectively:

1. Prefer unifying parsers for schema-wide coverage
   Use _Im_<schema> when the goal is to query all sources mapped to that schema.
2. Use filtering parameters whenever available
   This is the main performance optimization. Many parsers support optional parameters so filtering happens before parsing rather than after parsing. The documentation recommends always using available filtering parameters for optimal performance. Better-performing pattern:

      _Im_Dns(starttime=ago(1d), responsecodename='NXDOMAIN')
   

   Less efficient pattern:

      _Im_Dns
      | where TimeGenerated > ago(1d)
      | where ResponseCodeName =~ "NXDOMAIN"
   

3. Understand the tradeoff of query-time normalization
   Query-time parsers are easy to develop and fix because they do not modify stored data, and fixes apply to existing data. But query-time parsing can slow queries, especially on large datasets.
4. Use ingest-time normalization for performance-sensitive scenarios
   If normalized queries are run frequently or over large volumes, ingest-time normalization can improve performance because data is stored already normalized. Supported native normalized destination tables include:
   • ASimAuditEventLogs
   • ASimAuthenticationEventLogs
   • ASimDhcpEventLogs
   • ASimDnsActivityLogs
   • ASimFileEventLogs
   • ASimNetworkSessionLogs
   • ASimProcessEventLogs
   • ASimRegistryEventLogs
5. Use the pack parameter when extra non-normalized fields are needed
   Some parsers support pack=true, which stores extra source-specific data in the AdditionalFields dynamic field while keeping the normalized schema as the main query surface.

When ASIM is most helpful:

• Multiple vendors produce the same event type, such as DNS, authentication, or network session logs.
• A single detection or workbook must work across cloud and on-premises sources.
• Custom tables need to be aligned with built-in Sentinel content.
• Teams want stable field names regardless of source product.

When to be cautious:

• Large-volume queries that rely heavily on query-time parsing can be slower.
• If the use case is performance-critical, ingest-time normalization is the better fit.
• Workspace-deployed parsers are mainly for development or modified parser management; built-in parsers are the recommended default for ASIM content development.

In short, ASIM functions are most useful as a technical abstraction layer: write once against a schema, then reuse the same query logic across many data sources. For scheduled analytics, NRT-style detections, hunting, and workbooks, they are valuable when consistency and cross-source coverage matter; for high-scale performance-sensitive scenarios, ingest-time normalization is the stronger design.

References:

• Normalization and the Advanced Security Information Model (ASIM)
• The Advanced Security Information Model (ASIM) parsers
• Using the Advanced Security Information Model (ASIM)
• Ingest time normalization