Log baseline v0.5.1
GitHub
HomeMethodology

How the baseline is built

Every table gets two separate recommendations. The classification records its security value and follows guidance from the Australian Cyber Security Centre (ACSC) and the US Cybersecurity and Infrastructure Security Agency (CISA). The storage tier is set separately from volume and how detections use the data, which means volume never changes the classification.

Process

How it was built

The dataset is AI-assisted and human-reviewed, with the outlined steps done by a person, and every change reaches the repository through a pull request with public evidence.

  1. 1Collect tables

    Microsoft Sentinel connector and table references, the Azure Monitor table feature matrix, and the public Azure-Sentinel repository. 773 tables today.

  2. 2Hand-classify a seed

    The maintainer classified around 50 connectors by hand and wrote down why.

  3. 3Write the rules

    Value rules C1-C9 from the guidance below. Tier rules T1-T5 from volume and documented data lake behavior.

  4. 4Classify with AI assistance

    An agent with Microsoft Learn, Defender, and web search checked the seed against the sources, then applied the rules to the remaining tables.

  5. 5Human review

    One table at a time: accept, edit, reject, defer, or challenge. Parts of the baseline were checked against live tenants.

  6. 6Validate

    Test-Baseline.ps1 rejects rule pairs outside their matrix cell and Data lake recommendations for tables without lake support.

  7. 7Release

    A versioned, checksum-pinned data release used by this site and Log Horizon. This site shows 0.5.1.

AI output, public documentation, upstream detection content, and tenant observations can all be incomplete or outdated. The data accuracy notes list what can go wrong.

Guidance

Guidance behind the value rules

The value rules are built mainly on two documents, and each rule maps to the sections and event types they list.

ACSCPriority logs for SIEM ingestion: Practitioner guidance 14 data source categories in rough priority order, from EDR logs to macOS endpoint logs.CISAGuidance for implementing M-21-31 8 event types in priority order for collection and storage, starting with identity and credential events.

Other sources

These also informed the classification. The sources page lists the full reference library.

Where the tier comes from

The guidance covers what to collect and in which order. The storage tier comes from the tier rules below. They build on a point ACSC makes about volume and on documented Microsoft Sentinel data lake behavior.

"The volume of firewall or Domain Name System (DNS) logs may overshadow the importance of the information received."

"The authoring agencies strongly discourage using a SIEM as the central repository for all logs."

ACSC, risk and architectural considerations
Step 1

Value rules

Each table gets exactly one value rule, where C1-C8 make it primary and C9 makes it secondary.

  1. C1primary139 tables

    Detections and findings

    Detections, alerts, incidents, security findings (vulnerability and posture findings), and detection pipeline health

    ACSC
    • 1Endpoint detection and response (EDR) logsEDR detections
    • 2Network device logsIDS/IPS alerts
    • -Risk considerationsCheck the health of priority sources
    CISA

    No event type

  2. C2primary37 tables

    Authentication and credential use

    Authentication and credential use, including non-interactive, service principal, managed identity, federated, VPN, NAC, and password vault access

    ACSC
    • 2Network device logsVPN and NAC
    • 3Microsoft Domain Controller
    • 4Active Directory (AD) and Domain Service security logs
    • 8Cloud platform loggingEntra sign-in logs
    CISA
    • 1Identity, credential, and access management (ICAM)1b Track usage of credentials
  3. C3primary70 tables

    Identity, privilege, and configuration changes

    Identity, privilege, and configuration changes: directory audit, cloud control plane, RBAC, Kubernetes API, security tool administration, virtualisation and MDM management

    ACSC
    • 2Network device logsConfiguration changes
    • 6Virtualisation system logs
    • 8Cloud platform logging
    • 9Container logs
    • 11Mobile device management
    CISA
    • 1Identity, credential, and access management (ICAM)1a Manage and track changes in attributes and credentials
    • 4Cloud environments (general logging)4a Any activity on breakglass accounts
    • 5Amazon Web Services (AWS)5a AWS CloudTrail
    • 6Cloud Azure6a-6b Azure Active Directory logs and Azure Activity
    • 8Google Cloud Platform (GCP)8a Admin audit
  4. C4primary34 tables

    Endpoint and operating system activity

    Endpoint and operating system activity: process, script, logon, service, scheduled task, registry, file

    ACSC
    • 1Endpoint detection and response (EDR) logs
    • 5Microsoft Windows endpoints logs
    • 6Virtualisation system logs
    • 13Linux endpoint auditing logs
    • 14Apple MacOS endpoint logs
    CISA
    • 2Operating systems2a-2j All listed operating system event types
  5. C5primary241 tables

    Network activity

    Network activity: firewall, DNS, DHCP, web proxy, flow, load balancer, mail gateway and message flow, web access to internet-facing services

    ACSC
    • 2Network device logs
    • 8Cloud platform logging
    • 12Windows DNS server analytic event logs
    CISA
    • 3Network device infrastructure3a-3c DNS query and response, DHCP lease information, and firewall logs
  6. C6primary29 tables

    Collaboration, SaaS, and business application activity

    Collaboration, SaaS, and business application activity

    ACSC
    • 8Cloud platform loggingOffice 365 and Google Workspace
    CISA
    • 7Microsoft 3657a Unified audit log
  7. C7primary28 tables

    Data access

    Data access: storage, database audit and queries, API data access, directory queries, and audit log access

    ACSC
    • 6Virtualisation system logsAudit log access
    • 8Cloud platform loggingStorage and cloud API logs
    • 9Container logsAudit log access
    • 10Database logsDatabases and audit log access
    • 14Apple MacOS endpoint logsAudit log access
    CISA

    No event type

  8. C8primary11 tables

    Behavior analytics, threat intelligence, and identity inventory

    Behavior analytics, threat intelligence, and identity inventory used by detections

    ACSC

    No section

    CISA
    • 1Identity, credential, and access management (ICAM)1a Identity attributes
  9. C9secondary184 tables

    Health, inventory, and reference context

    Secondary: health, performance, metrics, diagnostics, inventory, posture snapshots, reference data, and aggregates derived from another collected table

    ACSC

    No section

    CISA

    No event type

Step 2

Tier rules

T1 to T4 run in order and the first match wins, then T5 checks whether the table can live in the data lake at all.

  1. T1
    Near-real-time detection

    Generic detections need near-real-time matching on single events.

    Analytics319 tables
  2. T2
    Enrichment or join target

    Low-volume enrichment or join target for analytics-tier detections or Sentinel features.

    Analytics44 tables
  3. T3
    High-volume aggregation

    Primary, high or very-high volume, and the generic detection use is aggregation, threat-intelligence matching, baselining, or investigation.

    Data lake197 tables
  4. T4
    Investigation context

    Low-touch context queried during investigations rather than for alerting.

    Data lake170 tables

Then the plan support check

  1. T5
    No lake support

    The table would otherwise get T3 or T4, but it has no Auxiliary/Lake support. The table stays in Analytics. See plan support.

    Analytics43 tables

Data lake limits behind T3

T3 relies on KQL jobs and summary rules.

  • Data lake ingestion latency is up to 15 minutes.
  • A scheduled KQL job starts at least 30 minutes after it is created.
  • A tenant can run 5 jobs concurrently with 100 enabled.

Split candidates

When some rows need T1 and the rest fit T3, a split transformation keeps the matching rows in Analytics, mirrored to the lake, and sends the rest to a separate _SPLT table in the lake.

Shared tables carry one split rule for every source in them. The CommonSecurityLog and Syslog pages build it from the sources you collect.

Platform fact

Not every table can move to the data lake

T3 and T4 apply only when the Azure Monitor table feature matrix lists Auxiliary/Lake support for the table, or when it is a custom table based on a data collection rule (DCR). Every other table that would land in the lake gets Analytics with rule T5. Long-term retention for those tables uses the mirrored lake copy.

Built-in tables with lake support
479
Baseline tables placed by T5
43
Analytics tables with no lake option
89

Microsoft documents that DCR-based custom tables support all plans. Classic custom tables created by the HTTP Data Collector API are not DCR-based, so migrate them before planning a move to the lake. Support for the HTTP Data Collector API ended on September 14, 2026.

Result

Classification and tier matrix

The two steps place every table in one of four cells, and validation rejects any rule pair outside its cell, so secondary tables never use T1 or T3.

Tables by classification and recommended tier, with the rule pairs that place them
AnalyticsT1, T2, T5Near-real-time detection, join targets, or no lake support.Data lakeT3, T4High-volume aggregation or investigation context.
PrimaryC1-C8Security events and the context detections depend on.Primary + Analytics350tables classified primary with the Analytics tier

C1-C8 with T1, T2, T5

High-value events that need near-real-time detection, low-volume join targets, or high-value tables the lake cannot hold.

14 more rule pairs

ExamplesPathlock_TDnR_CLSecurityEventEmailEvents

Primary + Data lake239tables classified primary with the Data lake tier

C1-C8 with T3, T4

High-value events at high volume detected through aggregation or jobs, or high-value context used mainly in investigations.

6 more rule pairs

ExamplesTailscale_Network_CLDeviceImageLoadEventsAzureNetworkAnalytics_CL

SecondaryC9Health, inventory, and reference data.Secondary + Analytics56tables classified secondary with the Analytics tier

C9 with T2, T5

Context that analytics-tier detections or Sentinel features join against, or context tables the lake cannot hold.

ExamplesTailscale_Devices_CLDeviceInfoWhisperThreatIntel_CL

Secondary + Data lake128tables classified secondary with the Data lake tier

C9 with T4

Operational and reference context.

ExamplesDeviceFileCertificateInfoUnifi_SiteManager_Devices_CLUnifi_SiteManager_Sites_CL

Value is decided first with one value rule per table, and volume plays no part in it. The tier is decided second, where T1 to T4 run in order and the first match wins, and T5 keeps a table in Analytics when T3 or T4 matches but the lake cannot hold it.

Input to step 2

Volume model

volumeDriver records what one row represents. volumeClass is the expected volume relative to other tables where the source is deployed. Both are judgment and experience, not measured tenant volume. Log Horizon measures actual ingestion from the Usage table.

low

  • alert129
  • snapshot97
  • admin-action54

medium

  • activity46
  • sign-in25
  • message15
  • indicator7

high

  • metric57
  • application-trace32
  • endpoint-event29
  • data-access24
  • api-request13
  • os-event8
  • token-sign-in6

very-high

  • connection184
  • web-request34
  • dns-query13

Counts are tables per driver. A per-table override can set a different class than the driver's default, for example very-high for non-interactive sign-ins.

Context takes precedence

A table marked secondary can still be essential because of deployed detections, regulatory requirements, incident history, or business processes. Treat these recommendations as review inputs, not as a one-size-fits-all security standard.