Native ASIM Ingestion for Microsoft Sentinel, Now in Bindplane
Bindplane's Sentinel destination now supports ASIM mode to send raw security logs straight into Microsoft Sentinel's native ASIM tables, with no custom tables to predefine and no schema to design first.

If you're sending security data to Microsoft Sentinel, you now have a faster path. A new ASIM mode lands your logs directly in Sentinel's native ASIM tables: no custom tables to predefine, no schema to design before data flows.
We added ASIM mode to the Microsoft Sentinel destination, backed by a new ASIM standardization processor that converts raw logs to ASIM in the pipeline and routes each record to the table it belongs in. Here's how it works, and why we built it this way.
The Old Way Meant More Setup Than Searching
Sending data to Sentinel has meant the Azure Log Analytics Ingestion API, a custom Data Collection Rule, and tables you defined before any data could flow.
That works, and we still support it. But it pushes schema decisions onto every team upstream of Sentinel, and it often lands data outside the structures Sentinel is built to query. You spend setup time that should have gone to detection. More plumbing, less querying.
ASIM Is the Schema Sentinel Wants
Sentinel is built around ASIM, Microsoft's schema model for security data. If you've standardized on OCSF in other stacks, ASIM is the Sentinel-native equivalent.
The point isn't compatibility, it's standardization. Before, raw logs landed in a custom table you defined, outside the structures Sentinel's analytics rules, workbooks, and hunting queries expect. ASIM mode standardizes them on the way in:
One step added in the pipeline. Native tables, no schema work, on the other side.
One Processor, Routing Per Record
The ASIM standardization processor takes raw security logs (Windows Security events, Linux syslog, CEF) and converts them to ASIM in the pipeline. Presets cover the common sources, and you can define custom event mappings for the rest.
We made routing per-record on purpose. You don't assign a source to a table and hope every event fits. The processor reads each log, picks the matching table from Sentinel's ten native ASIM tables, and validates the record against that table's column contract before it ships. If a record doesn't satisfy the contract, it fails in the pipeline instead of landing malformed in Sentinel. We'd rather catch bad data early than debug it inside a detection rule later.
Once data lands, querying, alerting, and investigation work against native structures from the first event.
Setup Stays in Your Control
You configure sources in Bindplane, choose Microsoft Sentinel as the destination, and add the ASIM processor to the pipeline.
On the Azure side, you deploy a single consolidated DCR from an ARM template the wizard generates. It provisions one Data Collection Rule across all ten ASIM tables, plus the role assignment the service principal needs. Deploy it, upload the deployment output back into Bindplane, and we auto-fill the endpoint, rule ID, and tenant ID. You add your client ID and secret, and that's the loop.
We split it this way deliberately. Bindplane handles standardization. You keep control of Azure resources and permissions, and we never ask for broader access than the job needs.
Two Modes for Two Maturity Levels
The Microsoft Sentinel destination now ships with two modes:
- Basic mode: send data to a custom table you provision. Same flexibility as before.
- ASIM mode: send standardized data to Sentinel's ten native ASIM tables.
Not every team is ready to commit to ASIM, and we didn't want to force it. Both paths are first-class.
Same Philosophy, More Destinations
This is the same approach we took with Google SecOps: shape data for the destination instead of treating every backend as a generic sink.
If you run across multiple security ecosystems, destination-aware processing is the difference between pipelines you maintain and pipelines that just work.
From Raw Logs to Detection-Ready Data
If you're building on Microsoft Sentinel, this is the shortest path from raw logs to data your security team can use on day one.
To set it up, see the Microsoft Sentinel ASIM destination docs. If you want help getting started, reach out in the Community Slack.

