Where AI for Security Teams Pays Off: SIEM Query Generation

You describe the behaviour you want to detect - for example, 'show me all failed logins from a single source IP that exceed five attempts in ten minutes' - and the AI maps that intent to the query language your SIEM uses (SPL for Splunk, KQL for Microsoft Sentinel, Lucene for Elastic, and so on). It fills in the correct field names, time-window functions, and aggregation syntax. The result is a draft query, not a finished one. You still need to confirm the field names match your data schema, set realistic thresholds for your environment, and test against a small time window before widening the search.

Current large-language models handle SPL (Splunk), KQL (Microsoft Sentinel and Defender), Lucene / EQL (Elastic SIEM), Sigma (vendor-neutral rule format), and basic SQL for data-lake log stores. They are weakest on niche or proprietary query dialects with limited training data. Always state the target language explicitly in your prompt and verify the output compiles without errors before running it in production.

Yes. Threat hunting queries tend to be exploratory - they look for patterns rather than definitive thresholds. You can ask AI to generate a baseline query, then iterate: 'now filter out known service accounts', 'add a time-of-day filter for outside business hours', 'group by user and sort by event count descending'. This conversational refinement is where AI saves the most time, cutting what used to be a back-and-forth with documentation into a fast drafting loop.

Treat every AI-generated query as an unreviewed draft. The safe sequence is: (1) generate the query with a clear plain-English prompt; (2) read the output and check field names against your log schema; (3) run it against a short time window or a test index first; (4) review the results for obvious false positives; (5) tune thresholds and exclusions before saving as a detection rule. Never pipe AI output directly into an automated response action without this review step.

It does not know your environment unless you tell it. The most effective approach is to paste a sample log line or a snippet of your schema into the prompt. The AI then maps the query to your actual field names rather than generic defaults. Some teams maintain a short 'field map' snippet they paste into every AI query session - for example, mapping generic terms like 'source IP' to the actual field name in their log schema. This two-minute setup step prevents the most common source of broken queries.

AI drafts the query syntax. The analyst owns the detection logic. That means the human decides what threshold makes sense given the environment's normal noise level, whether a detected pattern is genuinely suspicious or a known benign process, and what action to take on a match. AI has no visibility into your organisation's risk appetite, its known-good service accounts, or its incident response playbooks. The human brings that context - AI just removes the friction of writing correct syntax.

A good prompt includes four things: the target query language, the data source or log type, the behaviour or pattern to detect, and any known exclusions. For example: 'Write a Splunk SPL query against Windows Security event logs. Detect accounts with more than three failed logon events (EventCode 4625) within five minutes, grouped by account name and source IP. Exclude service accounts ending in -svc.' That level of specificity produces a query that needs minor tuning, not a complete rewrite.

This is one of the most reliable use cases. Sigma is a vendor-neutral detection rule format. Paste a Sigma rule into an AI prompt and ask it to convert to SPL or KQL - the output is usually accurate because the mapping is structured and well-documented in training data. Still validate: Sigma-to-KQL converters sometimes miss platform-specific nuances like case sensitivity or time-range syntax. Run the converted query against a test window and compare results to the original rule's intent.