# Keep ASIM parser normalization separate from event correlation

> Can a custom ASIM parser join, expand or aggregate event records while normalizing them?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-420-keep-asim-parser-normalization-separate-from-event-correlation/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:56+00:00
- Modified: 2026-09-10T02:04:57+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Can a custom ASIM parser join, expand or aggregate event records while normalizing them?

## Potentially affected

Custom source-specific Advanced Security Information Model parsers in Microsoft Sentinel.

## DSE recommendation

Review each parser operation against a zero-or-one output record contract before adding enrichment or correlation.

## Article

## Source facts

Microsoft’s ASIM development guidance requires independent normalization of each source record, producing either no record after filtering or one normalized record. It prohibits event joins, extra table reads, watchlists, external tabular enrichment, expansion and event aggregation inside the parser. A locally defined static mapping used with lookup is allowed only with unique keys. When one source record contains several logical events, the guidance calls for correcting the source or connector rather than expanding it in the parser. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/sentinel/isv/normalization-develop-parsers).

## Applicability

Apply this contract to a source-specific ASIM parser under development or review. Do not treat an arbitrary analytical KQL query as an appropriate normalization function merely because its final columns resemble the schema.

## DSE recommendation

Review each parser operation against a zero-or-one output record contract before adding enrichment or correlation. Ask the connector owner to resolve missing source identity or bundled event shapes at their origin. Keep detection-stage correlation outside the normalization implementation. For a permitted static mapping, review key uniqueness alongside the field mapping so an apparently simple lookup does not obscure the intended record relationship.

## Verification

Use representative source samples with different outcomes and identifier formats. Trace each retained output to its individual input and account for intentional filtering. Include duplicate mapping-key and bundled-event cases in the design review, recording how they are corrected rather than silently accepted. Preserve both schema checks and record-count evidence; correctly named columns alone do not demonstrate that the parser preserves event identity.

## Official references

[Microsoft Learn: Develop ASIM parsers](https://learn.microsoft.com/en-us/azure/sentinel/isv/normalization-develop-parsers). Source reviewed September 9, 2026.

## Primary reference

- Name: Develop Microsoft Sentinel Advanced Security Information Model (ASIM) parsers | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/sentinel/isv/normalization-develop-parsers
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Keep ASIM parser normalization separate from event correlation,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-420-keep-asim-parser-normalization-separate-from-event-correlation/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.