Log Analytics Query
Runs and ingests custom queries from Azure Log Analytics to collect operational or identity-related logs
Sync Type: Incremental
Requirements
Before setting up the Microsoft Log Analytics Query you need to:
- Have a Microsoft Account with an active Azure Subscription
- Create a Application with API Data.Read access to the Log Analytics API
- Reader permissions granted to the application from the Logs Analytics Workspace
Note: On the first sync, the start time is determined in order: Backfill Start Time if set, otherwise now - Ingestion Delay if configured, otherwise starts from current time (while accounting for the ingestion delay in azure). Subsequent syncs are incremental from the last successful sync time.
Query behavior: Monad automatically appends | extend IngestionTime = ingestion_time() and filters/sorts by IngestionTime rather than TimeGenerated. Do not include IngestionTime filters, sorting, or limits in your query.
Configuration
Settings
| Setting | Type | Required | Description |
|---|---|---|---|
| Tenant ID | string | true | The tenant ID of the Azure AD application |
| Workspace ID | string | true | The workspace ID of the Log Analytics workspace |
| Query | string | true | The KQL query to run against the Log Analytics workspace. Do not include IngestionTime filters, sorting, or limits — these are managed automatically. |
| Ingestion Delay | duration (seconds) | false | Approximate delay between event occurrence and Azure ingestion for your workspace and table. Used to avoid missing late-arriving data. Run `{table_name} | summarize percentile(ingestion_time() - TimeGenerated, 99)` in Log Analytics to measure. Defaults to 0. |
| Backfill Start Time | string | false | ISO 8601 timestamp to start fetching data from on the first sync. Cannot be more recent than now - Ingestion Delay. |
| API Rate Limit | object | No | Optional limit on the connector's outbound request rate to the source API. Leave blank to use the connector's default behavior. See API Rate Limiting for the field format, limits, and how to choose a value. |
Secrets
| Setting | Type | Required | Description |
|---|---|---|---|
| Client ID | string | true | The client ID of the Azure AD application |
| Client Secret | string | true | The client secret of the Azure AD application |
Setting up API Access
- Registering a new application
- Open the App Registration page in the Azure portal.
- Select New Registration
- Add a name to the new registration
- Click Register
- Save the applications
Application (client) IDandDirectory (tenant) ID - Select Certificates and Secrets
- Click link next to Client credentials
- In "Client secrets" click "New client secret"
- Add a name and expiration to the new secret
- Save the client secret value
- Give application access to Log Analytics API
- Click "API Permissions" on left sidebar
- Click "Add Permission"
- Click "Logs Analytics API"
- Select "Delegated permissions"
- Select "Data.Read"
- Grant access to your Log Analytics Workspace
- Navigate to the Log Analytics Workspace
- Select the workspace
- Click "Access control (IAM)" on the left menu
- Select "Add Role Assignment" from the "+ Add" menu
- Select the
Readerrole and click Next - Click "Select members"
- Search for the new application name and click Select
- Click "Review + assign"
- Confirm by clicking "Review + assign"
Custom Schema Handling
If the source data doesn't align with any of the OpenSecurityControlFramework (OSCF) schemas, you can create a custom transformation using our JQ transform pipeline. For example:
Code
For more information on JQ and how to write your own JQ transformations see the JQ docs here.
If you believe this data source should be included in the standard OSCF schema set, please reach out to our team at support@monad.com. We're always looking to expand our coverage of security control frameworks based on community needs.
Related Articles
Sample Record
Code