log-horizon

Microsoft Sentinel SIEM Log Source Analyzer

I've had to answer "what are we actually getting out of these logs?" or "what is the recommended logs for Microsoft Sentinel" more times than I can count. The answer always depend on so many things, but we can be generic. So I built this thingy right here.

Log Horizon connects to your Microsoft Sentinel workspace (and optionally Defender XDR), goes through every log table you're ingesting, and tells you whether you're getting security value from it or just burning money. It classifies tables, scores them against your detection rules, and gives you concrete recommendations with savings estimates.

Important: This is a generic approach. If you know a log source is important to your environment, that context always takes precedence over what this tool tells you. The classifications are a starting point, not gospel.

Want to read more? I have some posts about Log Horizon on my blog:

1. Tool Release: Log Horizon
2. Update: Log Horizon v0.5.0
3. Building a practical log baseline and how Log Horizon helps you do that
4. How to use Log Horizon

Features

Disclaimer

[!CAUTION] Disclaimer

This tool is developed and maintained with the help of AI. Please exercise caution when using this solution and always understand what are you running before you run it in production. The developer assumes no liability for any vulnerabilities or issues.

By downloading, installing, or using this tool, you acknowledge that you have read, understood, and agree to these terms.

Prerequisites

If you're not already logged into Azure, the module will fire up Connect-AzAccount for you. If you are, it'll just carry on.

Getting started

Pretty straight forward:

# Grab the dependencies
Install-Module -Name Az.Accounts, Az.Resources -Scope CurrentUser
Install-Module -Name PwshSpectreConsole -Scope CurrentUser

# Clone and import
git clone https://github.com/lnfernux/log-horizon
Import-Module ./log-horizon/LogHorizon.psd1

Usage

The basics

Start by connecting to Azure and making sure you select the right account and subscription:

Connect-AzAccount

Then we can invoke the tool:

Invoke-LogHorizon -SubscriptionId '00000000-0000-0000-0000-000000000000' -ResourceGroup 'rg-sentinel' -WorkspaceName 'my-sentinel-ws'

Output should look something like this:

Also has a menu to dig deeper into other outputs:

Keyword gaps + Defender XDR

Want to know if you're missing tables related to specific vendors? Throw in some keywords. Add -IncludeDefenderXDR if you want the XDR analysis too.

Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -Keywords 'CrowdStrike','AWS','Okta' -IncludeDefenderXDR

Detection Analyzer

Enable rule quality/noise analysis based on incidents and automation rules:

Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -IncludeDetectionAnalyzer -DetectionLookbackDays 90

Export a report

# JSON
Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -Output json -OutputPath ./report.json

# Markdown
Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -Output markdown -OutputPath ./report.md

# Static HTML (self-contained, no JS, works offline)
Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -Output html -OutputPath ./report.html

# Auto-generate timestamped filename by pointing at a directory
Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -Output html -OutputPath ./reports/

Manage table retention and type

You can now update table retention and table type directly from the interactive TUI:

• Open Invoke-LogHorizon normally, then choose Manage table retention and type from the main menu for bulk retention or type updates.
• Open Log Tuning / Transforms > Evaluate specific table and choose Manage retention/type for this table for a single-table change.

For scripting or automation, use the dedicated public command:

# Preview a single-table change
Set-LogHorizonTableRetention -SubscriptionId '...' -ResourceGroupName 'rg' -WorkspaceName 'ws' `
  -TableName 'SigninLogs' -TotalRetentionInDays 365 -WhatIf

# Switch tables to Basic and set total retention
Set-LogHorizonTableRetention -SubscriptionId '...' -ResourceGroupName 'rg' -WorkspaceName 'ws' `
  -TableName 'AzureDiagnostics','VMConnection' -TargetPlan Basic -TotalRetentionInDays 730

# Use -1 for inherit/default semantics
# RetentionInDays = inherit workspace default
# TotalRetentionInDays = remove long-term retention
Set-LogHorizonTableRetention -SubscriptionId '...' -ResourceGroupName 'rg' -WorkspaceName 'ws' `
  -TableName 'SigninLogs' -RetentionInDays -1 -TotalRetentionInDays -1

Non-interactive / CI mode

Skip the interactive TUI and export straight to a file — useful for pipelines or scheduled runs:

Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -NonInteractive -Output json -OutputPath ./reports/

If you omit -Output, the analysis object is returned to the pipeline so you can pipe it into your own logic.

Split KQL Suggestions

The interactive TUI includes a Split KQL Suggestions menu that generates portal-ready split KQL for tables that are good candidates for splitting. It shows per-table KQL you can paste straight into the Sentinel split rule editor, with source attribution (knowledge base, rule analysis, or combined).

Custom pricing

Default price is 5.59 $/GB (West Europe Simplified PAYG). If your commitment tier is different:

Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' -PricePerGB 4.61

All parameters

Under the hood

So there's four phases.

1. Data collection

The module connects to Azure and pulls data from the Log Analytics and Security Insights APIs:

2. Classification

Every table gets classified through two passes:

First, a direct lookup against the 345-entry knowledge base in Data/log-classifications.json. Each entry carries the connector name, primary/secondary classification, security category, MITRE data source mappings, and a recommended pricing tier.

If there's no match, heuristic rules kick in:

• Name contains security patterns like Alert, Incident, Threat, Signin, Audit, Risk -> primary
• Name looks like infra telemetry: Flow, Metric, Diagnostic, Perf, Heartbeat -> secondary
• Has active analytics rules pointing at it -> primary
• High volume (>10 GB/mo) with nothing detecting on it -> secondary
• None of the above -> unknown

3. Cost-value scoring

Each table gets scored on a few dimensions:

• Cost tier: Free / Low (<1 GB) / Medium (1-10 GB) / High (10-50 GB) / Very High (>50 GB)
• Detection tier: None / Low (1-2 rules) / Medium (3-9 rules) / High (10+ rules)
• Assessment: High Value / Good Value / Missing Coverage / Review Needed / Data Lake Candidate / Free Tier
• Coverage %: Percentage of tables with at least one analytics rule or hunting query referencing them, calculated as tablesWithRules / totalTables * 100. Per-table coverage sums analytics rules + hunting queries found by parsing KQL for table names.

Then the module generates recommendations:

4. Detection Analyzer (noisiness scoring)

When you pass -IncludeDetectionAnalyzer, the module fetches recent incidents and automation rules, then scores every enabled analytics rule for potential noisiness.

Per-rule metrics (computed from incident data):

Noisiness score formula:

Each metric is converted to a percentile rank across all rules that have at least one incident. The composite score is a weighted blend:

Score = (Volume_percentile × 0.35) + (AutoClose_percentile × 0.40) + (FalsePositive_percentile × 0.25)

• Volume percentile (35%) — how many incidents a rule generates relative to other rules.
• AutoClose percentile (40%) — how often incidents are auto-closed by automation rules (highest weight because automated closure is the strongest signal of low-value alerts).
• FalsePositive percentile (25%) — how often analysts classify the outcome as false positive.

Score thresholds:

Rules with a score ≥ 70 and at least 5 incidents are automatically surfaced as High-priority recommendations in the Recommendations view.

5. Interactive dashboard

• Dashboard: overview stats, top 10 costliest tables, coverage bar, retention compliance summary, correlation exclusion callout
• Recommendations: prioritised actions with estimated monthly savings — expandable to show the full list when there are more than 10
• Detection Assessment: per-table rule and hunting query coverage breakdown, correlation-excluded rule listing
• SOC Optimisation: Microsoft's own improvement suggestions
• Retention Assessment: tables below recommended minimums with current vs recommended retention, plan type, and shortfall
• Transforms: DCR transform inventory with transform type classification
• Split KQL Suggestions: per-table split KQL ready to paste into the portal, with source attribution (knowledge base, rule analysis, or combined)
• All Tables: the full list with classification, cost, rules, retention (colour-coded), and assessment
• XDR Analysis: Defender XDR integration (when you used -IncludeDefenderXDR)
• Detection Analyzer: percentile-based noisy rule ranking with closure quality indicators (when you used -IncludeDetectionAnalyzer)
• Export: dump the report to JSON or Markdown right from the menu

The classification database

Sitting at Data/log-classifications.json. 345 entries, 190 connectors, 21 categories.

What's in each entry

Primary vs secondary security data

Primary (211 entries): the tables you're actually building detections on. Sign-in logs, security alerts, threat intel, audit trails, vulnerability findings, firewall hits, EDR telemetry.

Secondary (133 entries): supporting stuff. Perf metrics, infrastructure diagnostics, network flow volumes, inventory snapshots, config baselines, health checks.

Categories at a glance

Custom classifications

You can provide your own classification file to add entries for tables not in the built-in database, or override existing entries when the defaults don't match your environment. Custom entries take precedence over built-in ones when the same tableName appears in both.

Invoke-LogHorizon -SubscriptionId '...' -ResourceGroup 'rg' -WorkspaceName 'ws' `
    -CustomClassificationPath './my-classifications.json'

The custom file uses the same schema as Data/log-classifications.json — an array of objects:

[
  {
    "tableName": "MyCustomApp_CL",
    "connector": "Custom Logs (DCR)",
    "classification": "primary",
    "category": "Application Logs",
    "description": "Security-relevant audit events from an internal application",
    "keywords": ["custom", "internal", "audit"],
    "mitreSources": [],
    "recommendedTier": "analytics",
    "isFree": false
  },
  {
    "tableName": "AzureMetrics",
    "connector": "Azure Monitor",
    "classification": "primary",
    "category": "Infrastructure Diag",
    "description": "Override: promoted to primary because we detect on Azure resource metrics in this environment",
    "keywords": ["metrics", "azure", "infrastructure", "monitoring"],
    "mitreSources": [],
    "recommendedTier": "analytics",
    "isFree": false
  }
]

See Data/custom-classifications-example.json for a ready-to-use template.

How the classifications were built

The primary/secondary grading was done partially by the author and then by feeding Microsoft's data connector and table definitions into AI with a human grading baseline, using Microsoft best practices and industry standards as the classification criteria.If something looks off for your environment, trust your own context over the tool - AI can make mistakes, and context is king.

The classification criteria were drawn from the following sources:

ACSC (Australian Signals Directorate, Australian Cyber Security Centre)

• ACSC: Best practices for event logging and threat detection (Aug 2024)
• ACSC: Priority logs for SIEM ingestion - Practitioner guidance (May 2025)

CISA (Cybersecurity and Infrastructure Security Agency)

• CISA: Guidance for Implementing M-21-31: Improving the Federal Government's Investigative and Remediation Capabilities
• CISA: Microsoft Expanded Cloud Logs Implementation Playbook (2025)

Microsoft

• Microsoft Sentinel data connectors reference
• Microsoft Sentinel tables & connectors reference
• Azure-Sentinel GitHub repo (community analytics rules, connector definitions, solution templates)
• Microsoft Sentinel billing
• Microsoft Sentinel data tier management

MITRE

• MITRE ATT&CK Data Sources

NIST (National Institute of Standards and Technology)

• NIST SP 800-92: Guide to Computer Security Log Management

NSA (National Security Agency)

• NSA Cyber Event Forwarding Guidance

NCSC-UK (National Cyber Security Centre - United Kingdom)

• NCSC-UK's "What exactly should we be logging?"

Google Cloud

• Google Cloud Audit Logs overview
• Google Cloud Audit Logs best practices

Other sources were also used, along with the authors "expertise" if you can categorize it as such.

Project layout

LogHorizon.psd1              Module manifest (v0.6.2)
LogHorizon.psm1              Module loader
Public/
  Invoke-LogHorizon.ps1      Entry point, the main orchestrator
Private/
  Connect-Sentinel.ps1       Azure auth + workspace resolution
  Get-TableUsage.ps1         KQL query for ingestion volumes
  Get-AnalyticsRules.ps1     Analytics rules + table/field extraction + correlation tags
  Get-HuntingQueries.ps1     Hunting queries + table extraction
  Get-DataConnectors.ps1     Data connector inventory
  Get-DataTransforms.ps1     DCR transform discovery, split KQL generation
  Get-DefenderXDR.ps1        Defender XDR analysis (optional)
  Get-Incidents.ps1          Incident fetch + SentinelHealth auto-close attribution
  Get-AutomationRules.ps1    Automation rule inventory + close-logic attribution
  Get-SocOptimization.ps1    SOC improvement recommendations
  Get-TableRetention.ps1     Per-table retention, archive, and plan type
  Invoke-AzRestWithRetry.ps1 REST retry wrapper with exponential backoff for 429/5xx
  Invoke-Classification.ps1  Static DB + heuristic classification + _SPLT_CL detection
  Invoke-Analysis.ps1        Cost-value matrix + recommendations + split suggestions
  Write-Report.ps1           Spectre.Console TUI rendering
  Export-Report.ps1          JSON / Markdown / static HTML export with shared section renderer
Data/
  log-classifications.json              345-entry classification knowledge base
  high-value-fields.json                15-table split KQL knowledge base with curated fields and split hints
  field-frequency-stats.json            Community field frequency stats (generated by Build-FieldKnowledgeBase.ps1)
  custom-classifications-example.json   Example custom classification override file
  ReportTemplate.html                   Static HTML report template (pure-CSS tabs, zero JS)
Tests/
  LogHorizon.Tests.ps1       Pester v5 unit tests

Knowledge base generation

The split KQL knowledge bases -- high-value-fields.json and field-frequency-stats.json -- are generated offline by Build-FieldKnowledgeBase.ps1. The script:

1. Shallow-clones the Azure/Azure-Sentinel GitHub repo (sparse checkout of Solutions/, Detections/, Hunting Queries/)
2. Parses ~3,800 YAML rule files and extracts KQL queries via regex
3. Runs Get-TablesFromKql and Get-FieldsFromKql on each query to build per-table field frequency counts
4. Computes three tiers of fallback fields:
   • Universal fields -- fields appearing in >50% of all tables (e.g. TimeGenerated)
   • Category defaults -- fields appearing in >40% of tables within a classification category
   • Per-table stats -- raw field frequency counts for tables with >= 3 referencing rules
5. Merges mined fields into the existing curated high-value-fields.json (carries forward curated entries, adds newly-discovered tables with >= 3 rules and >= 3 meaningful fields)
6. Outputs both files to Data/

At runtime, Get-SplitKql uses a fallback hierarchy: curated KB entry -> live rule/hunting field analysis -> community per-table stats -> category defaults -> universal fields. Frequency of fields is not a perfect method, but it's useful to know.

Tests

Invoke-Pester ./Tests/LogHorizon.Tests.ps1 -Output Detailed

License

MIT

Version history

Known issues

PwshSpectreConsole UTF-8 encoding warning

To enable UTF-8 output in your terminal, add the following line at the top of your PowerShell $PROFILE file and restart the terminal:

$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

The module sets this automatically on import, but depending on your session the warning may still appear. It's cosmetic and doesn't affect functionality.

Contributing

If you have issues or want to contribute, create a PR.

Like the tool?