ASIM Browser Unleashed: Master Microsoft Sentinel’s 2,100+ Normalization Fields for Uncanny Threat Detection + Video

By /

Listen to this Post

Featured Image

Introduction:

Security Information and Event Management (SIEM) systems are the central nervous system of any Security Operations Center (SOC). However, their effectiveness is often crippled by the “signal-to-noise” ratio caused by disparate data formats. Microsoft Sentinel’s Advanced Security Information Model (ASIM) solves this by acting as a universal translator, turning raw logs from thousands of sources into a unified schema. A new community-driven tool, the ASIM Browser, has emerged to demystify this complex normalization layer, exposing over 2,100 fields and 165 parsers to help analysts hunt threats faster and build source-agnostic detections.

Learning Objectives:

  • Understand the architecture of Microsoft Sentinel’s ASIM and how it standardizes security data across diverse sources.
  • Learn to navigate the ASIM Browser to trace parser lineage and identify available entity extension fields.
  • Apply hands-on techniques for validating normalized data and writing source-agnostic KQL queries.

You Should Know:

  1. Deconstructing the ASIM Browser: Your Interactive Schema Map
    The ASIM Browser is not just a documentation aggregator; it is an interactive debugging and planning tool for security engineers. Ofer Shezaf’s tool consolidates fragmented Microsoft documentation into a single, searchable interface. It reveals the relationships between 12 core schemas (like NetworkSession, ProcessEvent, Authentication) and the specific log sources that feed them.

Step‑by‑step guide: First Contact with the Browser

  1. Navigate to the tool: `https://lnkd.in/ge6DCBca`
    2. You will be greeted by a table view. At the top, you’ll see tabs for different ASIM schemas (e.g., `ASIM Audit Event,ASIM Authentication`).
  2. Click on the “ASIM Audit Event” tab. The table populates with fields such as EventProduct, EventOriginalType, and ActorUsername.
  3. Use the global search bar (top right) to type “IpAddr”. The browser instantly filters to show every field across schemas containing that string, such as `DstIpAddr` and SrcIpAddr.
  4. Click on any cell value, for example, a specific `EventProduct` like “Windows”. The table will filter to show only the fields relevant to that product’s implementation.

  5. Unlocking the Power of Entity Extensions (The 600+ Field Explosion)
    ASIM defines base entities like “User” or “Device.” These entities are then prefixed by roles such as Actor, Dst, Src, or `Target` to create highly specific fields. Official documentation often lists the base entity but not the hundreds of permutations. The ASIM Browser dynamically generates these, giving you a complete inventory of every possible field you can query.

Step‑by‑step guide: Hunting with Entity Extensions

  1. In the ASIM Browser, ensure you are on a main schema tab, such as “ASIM Network Session” .
  2. Look for fields that start with a role prefix. Notice `DvcHostname` (Device hostname) and DvcIpAddr.
  3. Now, observe the `Actor` fields: ActorUsername, ActorSessionId. Notice how they differ from `TargetUsername` or DstUsername.

  4. To use this in a real Sentinel hunt, you would open the Log Analytics workspace and run a KQL query that leverages this normalization:

    // Source-agnostic query for failed logins using ASIM
_Im_Authentication(starttime=ago(1d), endtime=now())
| where LogonResult == "Failed"
| where TargetUsername contains "admin"
| project TimeGenerated, TargetUsername, SrcIpAddr, EventProduct
| summarize FailedAttempts=count() by TargetUsername, SrcIpAddr, EventProduct

    Note: `_Im_Authentication` is the ASIM parser function that unions all normalized authentication data.

  5. Parser Traceability: Mapping Log Sources to Detection Logic
    One of the browser’s most powerful features is parser traceability. It maps 165 ASIM parsers back to their original Microsoft Sentinel solutions, data connectors, and target Log Analytics tables. This is crucial for troubleshooting why a detection isn’t firing—perhaps the expected log source isn’t being parsed correctly.

Step‑by‑step guide: Validating Your Data Pipeline

  1. In the ASIM Browser, look for the column or filter related to “Parsers” or “Products” . Select a product, such as “Cisco ASA”.
  2. The view will update to show you exactly which ASIM parsers are responsible for ingesting and normalizing Cisco ASA logs (likely the `vNetworkSession` parsers).
  3. It will also show you the target tables. You might see that the raw data lands in `CommonSecurityLog` before being parsed.
  4. To validate this in your own environment, use a Linux or Windows command to generate a test log event on a Cisco ASA (if available) or simply check the table in Sentinel: 
    // Check raw data in the native table
CommonSecurityLog
| where DeviceProduct == "ASA"
| where TimeGenerated > ago(15m)
| take 10

Then, check the normalized view:

_Im_NetworkSession(starttime=ago(15m))
| where DvcAction == "Allow" // Filter using normalized field
| where DeviceProduct == "ASA"
| project TimeGenerated, SrcIpAddr, DstIpAddr, DvcAction, EventOriginalType

4. Exploiting “Allowed Values” for Precision Detection

Free-text fields are the enemy of accurate detection. ASIM defines specific enumerated values for critical fields (e.g., `EventType` can be “Logon”, “ElevatePrivilege”). The ASIM Browser provides interactive dropdowns of these allowed values, ensuring your detections use the correct syntax.

Step‑by‑step guide: Building Precise Analytics Rules

1. Navigate to the “ASIM Process Event” tab.

  1. Locate the `EventType` field. In the browser, you should see an interactive element (or note) indicating allowed values such as ProcessCreated, ProcessTerminated, ProcessAccessedFile.
  2. When building a detection rule in Microsoft Sentinel for suspicious process creation, you can now confidently use these exact values: 
    _Im_ProcessCreate(starttime=ago(1h))
| where EventType == "ProcessCreated"
| where Process has_any ("powershell.exe", "cmd.exe", "wscript.exe")
| where ParentProcess contains "winword.exe" // Office spawning shell
| project TimeGenerated, DvcHostname, ActorUsername, Process, ParentProcess

5. Cross-Source Validation: Debugging ASIM Inconsistencies

The ASIM Browser exposes inconsistencies by comparing fields against three sources: official documentation, the ASIM Tester tool, and physical Log Analytics tables. This “source of truth” comparison helps analysts understand why a field might be present in a parser but missing from their actual data.

Step‑by‑step guide: Troubleshooting Missing Fields

  1. In the browser, select a field, for example, DvcOs. The display will show flags indicating its status.
  2. If the field is “In Docs” but “Not in Physical Tables,” your connector may not be populating it.
  3. To investigate, you must look at the specific parser logic using KQL: 
    // View the code of a specific ASIM parser
let parser_name = "vimProcessCreateMicrosoft365Defender";
// This command shows the underlying union/filter logic
union isfuzzy=true
(table('DeviceProcessEvents') | where ...),
(table('IdentityLogonEvents') | where ...)

    This command helps you see exactly which source table column maps to `DvcOs` and if the logic is correct.

What Undercode Say:

  • The “Source-Agnostic” Advantage: The ASIM Browser solidifies the shift from signature-based detection (Cisco 5510 logs) to behavior-based detection (Network connection allowed to unknown IP). By unifying the language of your logs, it future-proofs your detections against changes in your underlying infrastructure.
  • Documentation as Code: The tool highlights that security engineering is moving towards treating documentation as an interactive, queryable asset. Manually tracking 2,100+ fields is impossible; tools like this are now mandatory for efficient SOC engineering, turning a theoretical normalization model into a practical, daily driver for threat hunters.

Prediction:

As SIEMs become increasingly data-lake centric, normalization layers like ASIM will become the standard, not the exception. The ASIM Browser points to a future where security tools are shipped with “schema explorers” by default. We will likely see the rise of automated “schema linters” in CI/CD pipelines for detection-as-code, which will use these interactive definitions to validate that a new detection rule uses legitimate, normalized fields before it is deployed to production. This will drastically reduce rule failures and false positives caused by simple syntax errors.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Oshezaf Microsoftsentinel – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: