Dictionary

A table whose value rule is one of C1 to C8: detections and findings, authentication, identity and configuration changes, endpoint and operating system activity, network activity, collaboration and SaaS activity, data access, or behavior analytics and threat intelligence. The rules map to the ACSC priority logs for SIEM ingestion and CISA's M-21-31 guidance. Primary does not decide the tier. A primary table can recommend Analytics or Data lake.

• Methodology: Value rules
• Building a practical log baseline

A table whose value rule is C9: health, performance, metrics, diagnostics, inventory, posture snapshots, reference data, and aggregates derived from another collected table. Volume never makes a table secondary. A secondary table recommends Analytics when detections or Sentinel features join against it or when the data lake cannot hold it, and Data lake otherwise.

• Methodology: Value rules
• Building a practical log baseline

The baseline grouping a table belongs to, such as Identity & Access, Security Alerts, Network Flow, or Infrastructure Diagnostics. Categories map each table into a domain and a log type in the explorer.

The Sentinel tier the baseline suggests for a table, set by its tier rule independently of its classification. analytics (T1, T2, T5) keeps the table queryable for near-real-time detections and joins. datalake (T3, T4) stores it for aggregation through KQL jobs and summary rules, and for investigations. Data lake is only recommended for tables with Auxiliary/Lake support or custom tables based on a data collection rule (DCR).

• Methodology: Tier rules

The four combinations of classification and recommended tier: primary with Analytics, primary with Data lake, secondary with Analytics, and secondary with Data lake. Each value rule and tier rule pair belongs to one cell. Validation rejects a pair outside its cell, and secondary tables never use T1 or T3.

• Methodology: Matrix

The rule, C1 to C9, that set a table's classification. Stored as valueRule. Each rule maps to sections of the Australian Cyber Security Centre (ACSC) priority logs for SIEM ingestion and event types in CISA's M-21-31 guidance.

• Methodology: Value rules

The rule, T1 to T5, that set a table's recommended tier. Stored as tierRule. T1 to T4 run in order and the first match wins. T5 applies when T3 or T4 matches but the table has no Auxiliary/Lake support, so it stays in Analytics.

• Methodology: Tier rules

Expected volume relative to other tables where the source is deployed: low, medium, high, or very-high. Stored as volumeClass. It is judgment, not measured volume, and it feeds the tier rules only. Log Horizon measures actual ingestion.

• Methodology: Volume model

What one row of the table represents, for example sign-in, connection, or dns-query. Stored as volumeDriver. Each driver has a default volume class that a table can override.

• Methodology: Volume model

A table where some rows need near-real-time detection (T1) and the rest fit high-volume aggregation (T3). A split transformation keeps the matching rows in Analytics, mirrored to the data lake, and sends the rest to a separate _SPLT table in the data lake.

• Methodology: Split candidates

Minimum recommended total retention for a table in days. The baseline uses 90, 180, or 365, drawn from public guidance such as CISA M-21-31, NIST SP 800-92, NCSC-UK, ACSC, and NSA. Your regulatory and contractual obligations override these values.

• NIST SP 800-92
• CISA: Guidance for Implementing M-21-31

Whether Microsoft ingests the table into Sentinel at no charge. Free tables still count toward retention beyond the included period and can still be worth reviewing for detection coverage.

• Microsoft: Free data sources

Search terms attached to a table so the explorer finds it by product, vendor, or activity name rather than only by table name.

MITRE ATT&CK data sources and components the table can populate, for example Logon Session or Cloud Service: Cloud Service Modification. Used to reason about which techniques a table can help detect.

• MITRE ATT&CK data sources

Top-level security area such as Identity, Endpoint, Network, Cloud, or Security Operations. Each domain groups the log types and tables that describe activity in that area.

The kind of record a table holds inside a domain, such as Audit, Activity, Alert, Sign-in, or Diagnostics. Filtering a domain by log type narrows the table list to one record shape.

The product, service, or connector that produces the table, such as Microsoft Entra ID, Windows Security Events via AMA, or Microsoft Defender for Identity. Shown as the connector column in the explorer.

The Log Analytics table the data lands in, for example SigninLogs or SecurityAlert. Baseline recommendations, tier, retention, and free-ingestion flags are all attached at the table level.

A product that writes into a table many products share, such as PAN-OS in CommonSecurityLog or OpenVPN in Syslog. Each source has a KQL row filter, an optional parser, and its own classification, tier, and retention. The shared table's own record covers only the remainder, the rows that match no source.

• CommonSecurityLog sources
• Syslog sources

A table kept in the dataset so existing deployments can be identified, but left out of the active baseline, its counts, and the pre-made layers. The table page names the replacement. Legacy means a newer table or connector replaces it. Deprecated means the table or its connector is retired or scheduled for retirement.

• Legacy and deprecated tables

A table that can be queried in Defender advanced hunting without ingestion into a Log Analytics workspace. Some of these tables also stream to Sentinel through the Microsoft Defender XDR connector. A few have no Log Analytics table at all. In ISOC, Defender data has 90 days of included retention, and the tier recommendation covers retention beyond that.

• Microsoft: Advanced hunting schema
• Microsoft: Defender XDR connector

Full KQL, near real-time availability, and unlimited queries at no per-query charge. Interactive retention is 90 days by default and can be extended to two years. Intended for primary security data.

• Microsoft: Analytics tier

Low-cost, long-term storage in the Microsoft Sentinel data lake. Data is queried on demand, searched at scale, or summarized into the analytics tier with KQL jobs. Intended for secondary security data and for retention beyond the analytics tier period.

• Microsoft: Data lake tier
• Microsoft: Sentinel data lake overview

A Log Analytics table plan with a reduced flat ingestion rate, limited KQL, and interactive queries billed per GB scanned. Only tables on Microsoft's supported list can use it. The baseline ships that list so tools can check eligibility.

• Microsoft: Select a table plan in Azure Monitor Logs

The Log Analytics table plan for high-volume, verbose data at the lowest ingestion rate, with queries billed per GB scanned. Microsoft also calls it lake-only ingestion into the Sentinel data lake. The baseline ships the supported table list so tools can check eligibility.

• Microsoft: Select a table plan in Azure Monitor Logs
• Microsoft: Azure Monitor Logs table feature support

How long data remains accessible across tiers. Data past the analytics tier interactive retention stays available in the data lake tier until total retention ends.

An ingestion-time rule with a KQL condition that discards matching records before they are stored. Typical use is dropping routine allow events from firewall logs while keeping deny, block, and high-severity outcomes in the analytics tier. Filtered data is gone, not tiered.

• Microsoft: Filter transformations

An ingestion-time rule with a KQL expression that decides which records go to the analytics tier. Matching data lands in analytics and is mirrored to the data lake. Non-matching data goes to the data lake only, into a separate table with a _SPLT suffix so retention can be set per tier. A table has one split rule, so on a shared table the condition combines every source you collect. The table pages for CommonSecurityLog and Syslog build that condition.

• Microsoft: Split transformations
• Building a practical log baseline

A KQL transformation inside an Azure Monitor data collection rule that filters, reshapes, or routes records before they reach a Log Analytics table. Sentinel filter and split rules generate these for you. Rules created directly in Azure Monitor can conflict with rules created in Sentinel on the same table.

• Microsoft: Data collection transformations

Data ingested into the analytics tier is also written to the data lake tier as a single copy. The lake therefore always holds the full dataset, and the analytics tier holds the subset selected for detections.

Moving data or aggregates from the data lake tier into the analytics tier so detections, correlation, and full-speed queries can use it. KQL jobs, summary rules, and search jobs are the mechanisms. Promoted data is billed at analytics tier rates, so project only the columns and rows needed.

A one-time or scheduled asynchronous KQL query over data lake tables and federated tables. Results are written to a table in the analytics tier or the data lake tier. Used to promote historical data for an investigation, run retrospective threat intelligence matching, or build recurring baselines from low-fidelity logs. Requires data lake onboarding.

• Microsoft: Create KQL jobs
• Microsoft: Compare KQL jobs, summary rules, and search jobs

A scheduled aggregation that runs frequently over high-volume data and stores the result in a custom table in the analytics tier. Works over analytics and data lake tables. Lets a secondary table like NetFlow or firewall allow traffic still feed detections through counts, distinct values, or first-seen summaries rather than raw rows.

• Microsoft: Summary rules

A one-time, long-running asynchronous query over a single table across large time ranges. Results are hydrated into a new custom table in the analytics tier for forensic analysis. Fits pulling one table's history back for an incident rather than recurring aggregation.

• Microsoft: Search jobs

A written view of which assets matter, who is likely to attack them, and how. It is an input to detection engineering, not a Sentinel feature. Detections get built for the techniques in the threat model, and the tables those detections need become primary. The same table can be primary in one organization and secondary in another for this reason.

• Building a practical log baseline

A public catalog of adversary tactics and techniques. Sentinel analytics rules, hunting queries, and Defender custom detections can be tagged with techniques, and Sentinel renders the result as a coverage matrix. The baseline maps tables to ATT&CK data sources so gaps in the matrix can be traced back to missing logs.

• MITRE ATT&CK
• Microsoft: View MITRE ATT&CK coverage

The set of enabled analytics rules, custom detections, and hunting queries that reference a table. Log Horizon counts these per table. A primary table with no coverage is data paid for but not used for detection. A secondary table with heavy coverage is a candidate for reclassification.

A Sentinel rule that queries collected data on a schedule and raises alerts when it matches. Scheduled query rules, near real-time rules, Fusion, Microsoft security incident creation, threat intelligence matching, and anomaly rules are all analytics rule kinds. Rules run against the analytics tier only.

• Microsoft: Threat detection in Microsoft Sentinel

The most common analytics rule kind. A KQL query runs at a fixed interval over a lookback window and raises an alert per result or per group. Frequency, lookback, thresholds, entity mapping, and MITRE technique tags are set on the rule.

• Microsoft: Create scheduled analytics rules

A near real-time analytics rule that runs once a minute over the previous minute of data. Same wizard as scheduled rules with a limited feature set. Suited to detections where minutes of delay matter.

• Microsoft: Near real-time rules

A Defender XDR detection built from an advanced hunting query. It can query Defender tables and Sentinel tables in a workspace connected to the Defender portal, run continuously or on a schedule, and trigger response actions on matched entities. Microsoft now positions custom detections as the primary way to author new rules across Sentinel and Defender XDR.

• Microsoft: Create custom detection rules
• Microsoft: Compare analytics rules and custom detections

A saved KQL query run on demand rather than on a schedule. Used to look for activity no rule covers yet. A hunting query that keeps finding something becomes an analytics rule or custom detection. Log Horizon counts hunting queries toward a table's coverage.

• Microsoft: Threat hunting in Microsoft Sentinel

The output of a rule match. An alert carries the matched events, mapped entities such as users, hosts, and IP addresses, severity, and MITRE tags. Alerts from Defender products land in the SecurityAlert table, which is free to ingest.

A case that groups related alerts for triage and investigation. Sentinel and Defender XDR correlate alerts into incidents by shared entities and time. Incidents are stored in the SecurityIncident table, which is free to ingest.

A JSON file Log Horizon loads on top of its generic classification database. A layer lists tables with their connector, classification, category, tier, retention, and free-ingestion settings. Pre-made layers and custom baselines both use this format.

The smallest pre-made Microsoft layer. Sign-in, audit, identity risk, security alert and incident, Azure Activity, and Office activity tables.

Minimum plus Azure control-plane and workload logs such as Graph activity, Key Vault audit, firewall threat intel, WAF, storage blob, SQL audit, and behavior analytics.

Recommended plus the extended Entra ID sign-in and risk tables, provisioning, ADFS, Graph and notification activity, custom security attribute audit, and Sentinel behavior tables.

A layer you build in the explorer by selecting tables and overriding settings such as connector, classification, tier, or retention. Downloaded as JSON that validates against the same schema as the pre-made layers.

A per-table change in a custom baseline that replaces the generic value. Overrides are how tenant context gets recorded on top of the public baseline.

The data version of the log-baseline release the site was built from. Shown in the header and embedded in downloaded layers so feedback and tooling can reference the same snapshot.

The PowerShell module that consumes baseline layers, compares them with a live Sentinel workspace, and scores each table against ingestion cost and detection coverage.

• Log Horizon repository