Searching, Filtering, and Query Languages

Why SIEM Queries Matter

A SIEM platform collects logs from dozens or hundreds of sources—firewalls, endpoints, servers, cloud services—and stores them in a central index. Raw volume alone makes manual review impossible. A well-written query lets you cut through millions of events in seconds and surface exactly the activity you need to investigate. Weak or imprecise queries produce either too much noise (everything matches) or too little signal (nothing matches). Learning to write targeted queries is a core analyst skill and is tested on both CompTIA Security+ and CySA+.

Query Language Basics

Most enterprise SIEMs use a proprietary search language. Splunk uses Search Processing Language (SPL); Microsoft Sentinel uses Kusto Query Language (KQL); Elastic Stack uses Lucene syntax with optional EQL or KQL extensions. The concepts below apply broadly across platforms, though exact syntax differs. Always consult your platform's reference card during practice.

Keyword Search

The simplest query is a plain keyword. The engine searches every field in every indexed event for that string.

```

failed login

```

This returns any event containing both words. Keyword searches are useful for quick triage but produce false positives because the words may appear in unrelated fields.

Field Filter

When you know which field holds the value you care about, narrow your search to that field. This dramatically reduces noise.

SPL example: `source_ip="192.168.1.105"`

KQL example: `source_ip == "192.168.1.105"`

Field names are defined by the SIEM's data model or by the source log format. Common fields include `src_ip`, `dest_ip`, `user`, `action`, `event_id`, and `severity`.

Time-Range Filter

Logs grow continuously. Scoping your query to a time window keeps results relevant and reduces processing load. Most platforms let you set the time range in the UI picker, but you can also express it in the query itself.

SPL example: `earliest=-24h latest=now`

KQL example: `TimeGenerated > ago(24h)`

Always anchor queries to the time window relevant to the incident. Leaving the range open on a large index wastes resources and slows results.

Stats and Count by Field

Aggregation commands summarize events rather than listing them individually. The most common pattern is counting events grouped by a field value—for example, counting failed logins per user.

SPL: `stats count by user`

KQL: `summarize count() by user`

This produces a table showing each unique user and how many matching events exist for that user. Sorting descending (`sort -count` in SPL, `sort by count_ desc` in KQL) puts the highest-volume entries first.

Top N Values

A shortcut command returns the most frequent values of a field without writing a full stats-and-sort chain.

SPL: `top 10 src_ip`

This shows the ten source IPs that appear most often in the result set, with count and percentage columns automatically included. Use `top N` during initial triage to identify outliers or heavy hitters quickly.

Building Compound Queries

Real investigative queries chain multiple clauses together. A typical pattern in SPL uses the pipe character `|` to pass results from one command to the next:

```

index=main action="failure" earliest=-24h

| stats count by src_ip

| sort -count

| head 5

```

This query: (1) filters to failure events in the last 24 hours, (2) counts events per source IP, (3) sorts highest first, (4) returns the top five. Read a piped query left-to-right; each pipe narrows or transforms the previous result set.

In KQL, the same logic uses the `|` pipe and different command names:

```

SecurityEvent

| where Activity == "failure" and TimeGenerated > ago(24h)

| summarize count() by IpAddress

| sort by count_ desc

| take 5

```

Common Query Errors

Most broken queries fall into a small set of patterns:

• Misspelled field name – the field exists in the data model under a slightly different name; check the reference card.
• Missing or mismatched quotes – string values containing spaces must be quoted; forgetting the closing quote breaks the entire query.
• Wrong comparison operator – SPL uses `=` for equality inside a search; KQL uses `==`. Mixing them causes parse errors.
• Incorrect time syntax – `earliest=-24hours` will not parse in SPL; the correct unit is `h`, not `hours`.
• Pipe order mistake – placing a `where` filter after a `stats` command filters aggregated results, not raw events; the order matters.
• Case sensitivity – field names are often case-sensitive. `SRC_IP` and `src_ip` may be treated differently depending on platform configuration.

Responsible Use and Lab Safety

SIEM platforms have access to sensitive organizational data. In a production environment, analysts must operate under a defined authorization scope and handle query results as confidential. In this lab, you are working with a pre-loaded sample dataset (such as BOTS v3); do not attempt to connect your instance to live external systems or import data from outside the lab environment without instructor approval. Log off your instance when you finish. Do not share credentials for the lab platform with classmates; each student uses their own account so that query logs remain individually traceable for assessment.