The Advanced Security Information Model (ASIM) parsers (Public preview)
In Microsoft Sentinel, parsing and normalizing happen at query time. Parsers are built as KQL user-defined functions that transform data in existing tables, such as CommonSecurityLog, custom logs tables, or Syslog, into the normalized schema.
Users use Advanced Security Information Model (ASIM) parsers instead of table names in their queries to view data in a normalized format, and to include all data relevant to the schema in your query.
To understand how parsers fit within the ASIM architecture, refer to the ASIM architecture diagram.
Important
ASIM is currently in PREVIEW. The Azure Preview Supplemental Terms include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
Built-in ASIM parsers and workspace-deployed parsers
Many ASIM parsers are built in and available out-of-the-box in every Microsoft Sentinel workspace. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually. Both out-of-the-box and workspace-deployed parsers are functionally equivalent, but have slightly different naming conventions, allowing both parser sets to coexist in the same Microsoft Sentinel workspace.
Each method has advantages over the other:
| Compare | Built-in | Workspace-deployed |
|---|---|---|
| Advantages | Exist in every Microsoft Sentinel instance. Usable with other built-in content. |
New parsers are often delivered first as workspace-deployed parsers. |
| Disadvantages | Cannot be directly modified by users. Fewer parsers available. |
Not used by built-in content. |
| When to use | Use in most cases that you need ASIM parsers. | Use when deploying new parsers, or for parsers not yet available out-of-the-box. |
It is recommended to use built-in parsers for schemas for which built-in parsers are available.
Parser hierarchy and naming
ASIM includes two levels of parsers: unifying parser and source-specific parsers. The user usually uses the unifying parser for the relevant schema, ensuring all data relevant to the schema is queried. The unifying parser in turn calls source-specific parsers to perform the actual parsing and normalization, which is specific for each source.
The unifying parser name is _Im_<schema> for built-in parsers and im<schema> for workspace deployed parsers, where <schema> stands for the specific schema it serves. Source-specific parsers can also be used independently. Use _Im_<schema>_<source> for built-in parsers and vim<schema><source> for workspace deployed parsers. For example, in an Infoblox-specific workbook, use the _Im_Dns_InfobloxNIOS source-specific parser. You can find a list of source-specific parsers in the ASIM parsers list.
Tip
A corresponding set of parsers that use _ASim_<schema> and ASim<Schema> are also available. Theses parsers do not support filtering parameters and are provided to help mitigate the Time picker set to a custom range issue. Use those parsers only interactively in the logs screen, but not elsewhere, for example in analytic rules or workbooks. This parsers may not be removed when the issue is resolves.
Tip
The built-in parser hierarchy adds a layer to support customization. For more information, see Managing ASIM parsers.
Next steps
Learn more about ASIM parsers:
For more about ASIM, in general, see: