Azure Activity, Threat Indicators and Custom Tables

What it is

Beyond servers and appliances, a SOC also needs Azure control plane logs, threat intelligence about known bad indicators, and data from its own applications. This page covers three ways to bring those in: Azure activity logs through diagnostic settings and Azure Policy, threat indicators from threat intelligence feeds, and custom log tables filled through the Logs Ingestion API.

How it works

Azure activity logs

The Azure Activity log records control plane operations in a subscription, such as who created or deleted a resource, so it is key for detecting suspicious changes. The log lands in the AzureActivity table.

The current way to collect it is with diagnostic settings pointed at the Log Analytics workspace. Because a large organisation has many subscriptions, you use Azure Policy to assign the diagnostic setting at the management group or subscription level, so that every existing and new subscription sends its logs automatically. The same approach works for the resource logs of individual services, such as a storage account or a Key Vault, which are collected through each resource's diagnostic settings.

Azure Activity logs are one of the data sources that is free to ingest into Sentinel, along with Office 365 audit logs.

Threat indicators

Threat indicators, also called indicators of compromise, describe things known to be malicious, such as IP addresses, domains, URLs and file hashes. Sentinel can ingest them from several sources:

• Microsoft Defender Threat Intelligence, which provides indicators from Microsoft.
• TAXII servers, using the TAXII data connector, which pull indicators from feeds in the STIX format.
• Threat intelligence platforms and other products, through the upload indicators API.
• Manual entry, where an analyst adds an indicator in the Threat intelligence page.

Indicators are stored in the threat intelligence tables of the workspace. Once there, they are used in three ways: analytics rules match indicators against your events to raise alerts, hunting queries and workbooks use them for context, and analysts see them on the Threat intelligence page, where they can search, tag and manage them. Every indicator has a valid until date and a confidence, so old indicators expire.

Threat intelligence also reaches Defender XDR, so detections can use it across products.

Custom log tables

When no connector exists for a source, you create a custom table and send data to it. Custom tables have names that end with _CL. There are two common ways to get data in.

1. Logs Ingestion API. Your application, or a script, posts JSON to an endpoint.
2. Custom logs from files through the agent and a DCR, for text files on servers.

For the Logs Ingestion API, three things must exist before the first call works.

A workspace key is not used, and an agent is not needed for this API. The identity is usually a Microsoft Entra application or a managed identity.

A transformation in the DCR, written in KQL, lets you filter rows, drop columns or add computed columns before the data is stored, which cuts cost and cleans the data.

Table plans

Each table has a plan that decides cost and capability.

In Sentinel, tables can also be placed in the data lake tier. Choose the plan to match how often you query the data and whether detections use it.

Choosing the approach

A worked scenario

A company wants every Azure subscription to send its activity logs to Sentinel, now and in the future. A security engineer assigns an Azure Policy at the management group that deploys a diagnostic setting to the workspace, and the AzureActivity table fills automatically. The team enables the Defender Threat Intelligence connector and a TAXII feed from an industry sharing group, and turns on the threat intelligence analytics rule that matches indicators against events. An in house application creates JSON audit events, so a developer creates a custom table, a DCR with a stream declaration and a transformation that drops debug fields, and gives the application's identity the Monitoring Metrics Publisher role on the DCR.