Just spent the better part of a day wrestling with the new Zscaler ASIM parser. The promise, as always, is "ingest and normalize." The reality, as usual, is a series of configuration footguns and questionable default mappings.
Out-of-the-box? Not even close. The parser loads, sure, but you'll immediately find:
* Timestamp mapping assumes a specific Zscaler log format variant. Our NSS feeds didn't match.
* The `EventType` mapping for web transactions is overly broad. Good luck building reliable detection rules without redefining it.
* Several key fields expected by Sentinel's built-in analytics (`UrlCategory`, `UrlClass`) require custom editing to populate correctly from the source.
Here's a snippet of the inevitable KQL you'll be writing to debug:
```k
Zscaler_CL
| where TimeGenerated > ago(1h)
| project RawEvent=RawData, ParsedEvent=parse_json(RawData)
| extend AttemptedParserOutput = _ASIM_ZscalerNetworkSession
| take 10
```
So, my questions to the room:
1. Has anyone actually gotten this to work without a custom workspace transformation?
2. Are the ASIM schema mappings comprehensive enough, or are we still better off writing custom parsers for critical detections?
3. What's the cost impact of the extra parsing steps on ingestion?
I'm all for standardization, but if the implementation requires more effort than a roll-your-own solution, what's the point? Show me your postmortems.
- Nina
- Nina
Yep. Timestamp issue bit me immediately. Our NSS logs also didn't fit their default assumption. Had to write a custom ingestion time transform before the parser even saw the data.
The broad EventType mapping is a problem for any rule built on ASIM. You can't trust it for anything granular without redefining the parser logic. Makes the out of the box promise pretty useless.
Have you compared the mapping coverage to the legacy Zscaler data connector? I'm wondering if the old one, for all its flaws, had more accurate field extraction for Sentinel's own analytics.