Build Sentinel scheduled analytics rules with KQL queries, entity mappings, incident grouping, and MITRE ATT&CK tactics.
Build Sentinel scheduled analytics rules with KQL queries, entity mappings, incident grouping, and MITRE ATT&CK tactics.
Required Fields
displayNameseveritykindqueryqueryFrequencyqueryPeriodtriggerOperatortriggerThresholdtacticsOutput will appear here...Build a Microsoft Sentinel scheduled analytics rule combining a KQL detection query, queryFrequency/queryPeriod scheduling, incidentConfiguration grouping settings, and entityMappings that bind query output columns to Sentinel entity types (Account, IP) for investigation graph enrichment. queryPeriod must be greater than or equal to queryFrequency, querying a lookback window shorter than how often the rule runs creates gaps where events landing between the query's lookback boundary and the next run are never evaluated by any single execution, a subtle detection gap that doesn't show up as an error, just as silently missed alerts.
Always give queryPeriod real overlap beyond just matching queryFrequency exactly, a period exactly equal to frequency still risks gaps from execution timing jitter, build in a comfortable margin (period noticeably longer than frequency) as the example's 1 hour vs 5 minutes does.
Test entity mappings against real query output before relying on the investigation graph during an actual incident, a subtle column name mismatch in fieldMappings produces incidents with an incomplete or wrong entity graph that's only discovered when someone's actually trying to investigate.
MITRE ATT&CK tactic/technique tagging is only as useful as its accuracy, tagging a rule with a technique it doesn't actually detect (or omitting one it does) undermines any coverage-gap analysis built on top of these tags later.
The builder validates that displayName, severity, kind, query, queryFrequency, queryPeriod, triggerOperator, triggerThreshold, and tactics all resolve before accepting the JSON as a valid scheduled analytics rule definition, the fields Sentinel needs to know what to detect, how often, and how to classify it; it can't validate the KQL query's syntax or that it actually references real table/column names in your Log Analytics workspace, that's only confirmed when the rule actually executes.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.