> ## Content Index
> Fetch the complete content index at: https://marshsecurity.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# Sentinel Skills Saturday  - Edition 1.
- URL: https://marshsecurity.org/sentinel-skills-saturday-edition-one/
- Published: 2025-10-18T12:30:34.000Z
- Updated: 2026-05-24T17:07:46.000Z
- Author: Philip Marsh
- Tags: Sentinel, Microsoft Security

### 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.