Sentinel Skills Saturday - Edition 1.

What the heck is Sentinel Skills Saturday?!

I have an idea to showcase features within Sentinel and assist with sharing skills every Saturday. These posts will be shorter length, and will be aimed at all levels of knowledge to assist users with upskilling or knowledge gaps.

Introduction

KQL is at the heart of every effective Sentinel deployment, but poorly written queries waste time and compute; leading to delayed investigations and higher costs. This post will show you how to write faster, leaner, and more effective KQL queries to supercharge your threat hunting.

Start with the smallest table possible

Instead of starting with large tables such as SecurityEvent or SigninLogs and filtering later, start with the exact subset you need.

This approach avoids scanning unnecessary columns and tables, which add compute time and cost.

Example:

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine contains "encodedcommand"

Limit Columns Early

Each additional column costs compute. Use project early in your query, rather than later.

| project Timestamp, DeviceName, FileName, ProcessCommandLine

Use Summarise Sparingly

summarize is powerful but expensive. Only aggregate once per pipeline, ideally after filtering. Note that if you summarize before filtering, you're wasting compute time unnecessarily.

Filter in the Right Order

Always filter on high-selectivity columns first (e.g., DeviceName, AccountName) before broader time or text matches.

Use in and has_any for Lists

Instead of chaining multiple OR queries which can take longer to look up and compute.

Example:

| where FileName in ("powershell.exe", "cmd.exe", "wmic.exe")

Benchmark Query Performance

Use the execution_time() function in the query performance panel to identify bottlenecks.

Cache Expensive Joins

If you frequently join with static reference data, use a Watchlist instead, it’s faster and more manageable.

Create Reusable Functions for Common Patterns

Move recurring query logic into a function library to keep your detection rules consistent and maintainable.

Test Queries with Sample Data

When building detections, use the Sentinel demo data set or your own lab to validate query accuracy and performance, rather than querying against a larger subset of data.

Add Context for Analysts

Include fields that provide context (AccountName, DeviceName, IPAddress) for downstream investigation efficiency. These should (where possible) also be mapped in the entity mapping to make investigations and contextual analysis easier for your analysts.

Closing Thought

Efficient KQL is both an art and a discipline. The better your queries, the more responsive your SOC becomes and the cheaper your Sentinel operations are.