Detection Rules Migration: SPL to KQL¶

Status: Authored 2026-04-30 Audience: Detection Engineers, SOC Analysts, Security Engineers Purpose: Comprehensive guide for migrating Splunk detection rules (correlation searches, alerts, scheduled searches) to Microsoft Sentinel analytics rules

1. Overview¶

Detection rule migration is the most labor-intensive and risk-sensitive part of a Splunk-to-Sentinel migration. Your detection library represents years of security engineering investment -- false positive tuning, environment-specific logic, compliance-mandated rules, and institutional knowledge.

Microsoft provides two paths for detection rule migration:

1. SIEM Migration Experience -- automated, Copilot-powered SPL-to-KQL translation in the Defender portal (see Tutorial: SIEM Migration Experience)
2. Manual conversion -- hand-translate SPL to KQL using the patterns in this guide

Most organizations will use a combination: the SIEM Migration Experience for bulk conversion, then manual refinement for complex or critical rules.

2. SPL to KQL command mapping¶

Core search commands¶

Stats functions mapping¶

Eval functions mapping¶

3. Complex pattern translations¶

Pattern: eventstats (adding aggregations without reducing rows)¶

SPL:

index=main sourcetype=auth action=failure
| stats count by src_ip
| eventstats avg(count) as avg_failures
| where count > avg_failures * 3

KQL:

let avg_threshold =
    SigninLogs
    | where ResultType != 0
    | summarize failures = count() by IPAddress
    | summarize avg_failures = avg(failures);
SigninLogs
| where ResultType != 0
| summarize failures = count() by IPAddress
| where failures > toscalar(avg_threshold) * 3

Pattern: transaction (grouping events into sessions)¶

SPL:

index=proxy sourcetype=web_proxy
| transaction session_id maxspan=30m maxpause=5m
| eval duration=tostring(duration, "duration")
| where eventcount > 50

KQL:

WebProxy
| summarize
    EventCount = count(),
    StartTime = min(TimeGenerated),
    EndTime = max(TimeGenerated),
    URLs = make_list(Url),
    BytesTotal = sum(BytesSent)
    by SessionId, bin(TimeGenerated, 30m)
| extend Duration = EndTime - StartTime
| where EventCount > 50

Pattern: tstats (accelerated data model search)¶

SPL:

| tstats summariesonly=true count from datamodel=Authentication
  where Authentication.action=failure
  by Authentication.src, Authentication.user, _time span=1h

KQL:

SigninLogs
| where ResultType != 0
| summarize count() by IPAddress, UserPrincipalName, bin(TimeGenerated, 1h)

Splunk data models map to specific Sentinel/Log Analytics tables. The Authentication data model maps to SigninLogs (Entra ID) or SecurityEvent (Windows) depending on the source.

Pattern: macro expansion¶

SPL:

`notable_event_filter`
| search severity=critical
| `get_asset_info(src)`

KQL:

// Macros become KQL functions defined in Log Analytics
// Create function: notable_event_filter
let notable_event_filter = SecurityAlert
    | where AlertSeverity == "High";
// Create function: get_asset_info that enriches with watchlist
let enriched = notable_event_filter
    | join kind=leftouter (
        _GetWatchlist('AssetInventory')
    ) on $left.CompromisedEntity == $right.Hostname;
enriched

Pattern: subsearch / append¶

SPL:

index=firewall action=blocked
| stats count by src_ip
| where count > 100
| fields src_ip
| join src_ip [search index=auth action=success | stats count by src_ip]

KQL:

let blocked_ips =
    CommonSecurityLog
    | where DeviceAction == "Deny"
    | summarize BlockCount = count() by SourceIP
    | where BlockCount > 100
    | project SourceIP;
SigninLogs
| where ResultType == 0
| where IPAddress in (blocked_ips)
| summarize SuccessCount = count() by IPAddress

Pattern: rex (field extraction with regex)¶

SPL:

index=web sourcetype=access_combined
| rex field=_raw "(?<method>\w+)\s+(?<url>\S+)\s+HTTP/(?<http_version>\S+)"
| rex field=url "^/(?<app>\w+)/"

KQL:

W3CIISLog
| extend method = extract("(\\w+)\\s+\\S+\\s+HTTP", 1, csMethod)
| extend app = extract("^/(\\w+)/", 1, csUriStem)
// Or use parse for structured extraction:
| parse RawData with method " " url " HTTP/" http_version

4. Sentinel analytics rule types¶

Scheduled rules¶

The primary rule type for migrated Splunk correlation searches:

// Example: Brute force detection (migrated from Splunk ES)
// Original SPL: index=auth action=failure | stats count by src_ip, user
//               | where count > 20 | `notable_event`
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize
    FailureCount = count(),
    DistinctUsers = dcount(UserPrincipalName),
    Users = make_set(UserPrincipalName, 10)
    by IPAddress
| where FailureCount > 20
| extend AccountCustomEntity = tostring(Users[0])
| extend IPCustomEntity = IPAddress

Rule configuration:

Near-real-time (NRT) rules¶

For Splunk real-time searches that require sub-minute detection:

// NRT rule: Critical asset logon from unusual location
// Runs every 1 minute with minimal latency
SigninLogs
| where UserPrincipalName in (_GetWatchlist('CriticalAccounts') | project UPN)
| where Location !in (_GetWatchlist('ApprovedLocations') | project Location)
| where ResultType == 0

When to use NRT vs scheduled:

Fusion rules (ML-powered)¶

Sentinel Fusion rules use ML to correlate low-fidelity alerts into high-confidence incidents. These have no direct Splunk equivalent and represent net-new detection capability:

• Multi-stage attack detection
• Anomalous sign-in + data exfiltration correlation
• Ransomware campaign detection

5. Entity mapping¶

Splunk ES notables use asset and identity correlation. Sentinel uses entity mapping to link alerts to entities for investigation:

Entity mapping in analytics rule:¶

// In the analytics rule query, project entity fields:
| extend
    AccountCustomEntity = UserPrincipalName,
    IPCustomEntity = IPAddress,
    HostCustomEntity = Computer

6. SIEM Migration Experience workflow¶

The SIEM Migration Experience in the Defender portal automates bulk detection rule conversion:

flowchart TD
    A[Export Splunk detection rules] --> B[Upload to SIEM Migration tool]
    B --> C[Copilot translates SPL to KQL]
    C --> D{Translation status}
    D -->|Fully translated| E[Review KQL side-by-side]
    D -->|Partially translated| F[Manual completion required]
    D -->|Not translated| G[Manual rewrite needed]
    E --> H[Accept / Modify / Reject]
    F --> H
    G --> I[Manual KQL authoring]
    I --> H
    H --> J[Deploy analytics rules to Sentinel]
    J --> K[Configure entity mapping]
    K --> L[Enable and monitor]

Translation success rates (typical):

Recommendation: Export all rules to the SIEM Migration Experience first. It will handle the bulk of simple-to-moderate rules, leaving your detection engineering team to focus on the complex rules that require manual attention.

See Tutorial: SIEM Migration Experience for the step-by-step walkthrough.

7. Detection coverage validation¶

MITRE ATT&CK coverage comparison¶

Before and after migration, map your detection rules to MITRE ATT&CK techniques:

// Query to assess MITRE ATT&CK coverage in Sentinel
SecurityAlert
| extend Tactics = parse_json(ExtendedProperties).Tactics
| mv-expand Tactics
| summarize
    RuleCount = dcount(AlertName),
    Rules = make_set(AlertName)
    by tostring(Tactics)
| sort by RuleCount desc

Coverage gap analysis¶

8. Post-migration tuning¶

False positive reduction¶

Migrated rules often generate more false positives initially because KQL may match differently than SPL on the same data:

// Tuning example: exclude known service accounts from brute force detection
SigninLogs
| where ResultType != 0
| where UserPrincipalName !in (_GetWatchlist('ServiceAccounts') | project UPN)
| where IPAddress !in (_GetWatchlist('TrustedIPs') | project IP)
| summarize FailureCount = count() by IPAddress, UserPrincipalName
| where FailureCount > 20

Performance optimization¶

Summary¶

Detection rule migration from Splunk to Sentinel follows a structured approach:

1. Export all Splunk correlation searches, scheduled searches, and alerts
2. Upload to the SIEM Migration Experience for automated Copilot-powered translation
3. Review each translated rule -- accept, modify, or flag for manual rewrite
4. Manually convert complex rules using the SPL-to-KQL patterns in this guide
5. Configure entity mapping, MITRE ATT&CK tagging, and alert grouping
6. Validate MITRE ATT&CK coverage parity with pre-migration baseline
7. Tune false positives and optimize query performance
8. Monitor during parallel-run period before full cutover

Next steps:

• Tutorial: SIEM Migration Experience -- use the automated tool
• Tutorial: SPL to KQL -- 20+ hands-on conversion examples
• SOAR Migration -- migrate playbooks and automation

Maintainers: csa-inabox core team Last updated: 2026-04-30