Imported from lmkjhqwer123/multi-agent-cyber-soc-soar (PLUGINS/ClaudeCode/skills/asp-siem-en/SKILL.md). Install upstream with npx skills add lmkjhqwer123/multi-agent-cyber-soc-soar --skill asp-siem-en. Copyright stays with the author.

ASP SIEM

Use this skill when the user needs SIEM investigation on ASP. The focus is on choosing the right query path and returning evidence that is useful for analysis.

When to Use

• The user wants to confirm which indices, fields, or data sources are available.
• The user wants to search for related logs using IOC, alert context, or keywords.
• The user wants to do further filtering, statistics, or structured analysis within a known scope.
• The user wants to pivot into SIEM evidence from an alert, artifact, or case.

Operating Rules

• If the request already implies SIEM search, do not ask which operation to choose.
• Collect only the minimum missing inputs for the selected path.
• When the user does not know the correct index or field, use siem_explore_schema.
• siem_keyword_search is suitable for keyword-driven search, both broad exploration and fast lookup within a known index.
• siem_adaptive_query is suitable for exact field filtering, controlled aggregation, and stable reproduction. It is closer to a structured SIEM API.
• If the user gives a relative time window, call get_current_time first and derive a usable UTC range from the returned local time with timezone.
• Optimize for useful evidence, not for maximum raw output.

Function Notes

siem_keyword_search

Use when:

• The user has an IP, domain, username, hostname, hash, process name, email address, error text, or other keywords and wants to check for related logs.
• The user is not sure which index the logs live in and wants to start with a broader or global search.
• The user wants to iterate like a SIEM search interface, adjusting keywords and time range to observe result distribution.
• The user already knows the index but only needs a fast keyword search rather than exact field filtering.

How to use it:

• Required parameters are keyword, time_range_start, and time_range_end.
• keyword can be a string or a list of strings; when a list is used, it means AND matching.
• index_name is optional. If omitted, search globally. If provided, search only within that source or index.
• time_field defaults to @timestamp. Change it only when the source is known to use another time field.

What it is good for:

• It returns the event set that matches the search, which is useful for checking whether something hit, where it hit, whether the time distribution is concentrated, and whether new suspicious keywords or fields appear.
• It can be the starting point of an investigation or a fast secondary search during an investigation.
• It does not require the exact field names up front, so it is better for fuzzy search and exploration.

siem_adaptive_query

Use when:

• The user already knows or has mostly confirmed the target index_name.
• The user already has clear filters, such as exact field matches or a few precise conditions.
• The user wants top-N output, group statistics, field aggregation, or controlled scope queries.
• The user needs a stable, reproducible, structured query instead of more free-form keyword search.

How to use it:

• Required parameters are index_name, time_range_start, and time_range_end.
• filters are exact field filters; keys are field names and values can be a single string or a list of strings.
• aggregation_fields is optional. Add it only when the user explicitly wants statistics or grouping.
• time_field defaults to @timestamp. Change it only when the target source uses another field.

What it is good for:

• It returns structured query results and is better for stable verification, field statistics, and evidence that supports a conclusion.
• It is more like a SIEM API for the model. It does not have to come from siem_keyword_search, but it usually needs clearer context.
• When the user has already given the index, time range, and general conditions, use it directly rather than forcing keyword search first.

How To Choose

• If the clue is mainly a keyword, prefer siem_keyword_search.
• If the clue is mainly a known index plus known field conditions, prefer siem_adaptive_query.
• If the goal is to find events, see the distribution, and gather clues, prefer siem_keyword_search.
• If the goal is exact filtering, aggregation, or stable reproduction, prefer siem_adaptive_query.
• If the user does not name fields and the index is unclear, do not force siem_adaptive_query.
• If the user already gives a clear index and filters, do not mechanically start with siem_keyword_search.

Decision Flow

1. If the user asks which index to use, which fields exist, or how the SIEM source is organized, use siem_explore_schema.
2. If the user gives a relative time window, call get_current_time, derive a usable UTC range from the returned local time with timezone, and continue.

SOP

Explore Schema

1. If the user does not know the target source, call siem_explore_schema() first.
2. If the user already knows the index and wants field structure, call siem_explore_schema(target_index=<index>).
3. Parse the returned JSON.
4. Summarize the indices, time field candidates, and high-signal fields most relevant to the investigation goal.
5. Recommend the next query path: keyword search or adaptive query.

Use siem_keyword_search

1. Start with the strongest known keyword.
2. Normalize multiple keywords into an AND set only when the user truly means all conditions must match.
3. Require UTC timestamps ending in Z.
4. If the user did not specify index_name, you may start globally; if the user has a known source, you can restrict to that index.
5. Call siem_keyword_search.
6. Parse each returned JSON string, and choose output emphasis based on the user's goal:
   • If the user is looking for events, show representative hits first.
   • If the user is checking where the logs landed, focus on backend, index distribution, and time distribution.
   • If the user is narrowing further, summarize which keywords should be added or removed next.
7. Decide the next round based on the results:
   • If there are too many hits, narrow the time range first, then add one or two high-signal keywords.
   • If there are too few hits or none, remove one restrictive keyword or expand the time range moderately.
   • If hits are concentrated in a few indices, specify index_name next time.
   • When the results already explain the log location and key fields, switch to siem_adaptive_query.

Use siem_adaptive_query

1. Require index_name, a UTC time range, and at least one exact filter or a clear aggregation goal.
2. Normalize filters into exact field/value pairs.
3. Add aggregation_fields only when the user wants prevalence, top-N statistics, or grouped scoping.
4. Call siem_adaptive_query.
5. Summarize the filtered scope, hit count, and any aggregation output in analyst language.
6. If the result is not useful, first decide whether the filters are too strict, the field name is wrong, the time range is wrong, or the user should return to siem_keyword_search for more context.

Refine Search

Preferred refinement actions:

1. Narrow the time range before adding many new keywords.
2. Add one or two high-signal keywords instead of many weak ones.
3. Remove one restrictive keyword if the query returns no results.
4. Add index_name when broad search returns too much irrelevant data.
5. Switch to siem_adaptive_query when the user has learned enough field structure to stop using keyword search.
6. Keep iterating until the result quality matches the user's goal.

Response Strategy

Always explain what the search means, not just what it returned.

Preferred response structure:

Search Overview

• Search mode: schema exploration, keyword search, or adaptive query
• Keyword set or exact filters
• Time range
• Searched index or all
• Aggregation fields if used
• Overall explanation in one or two lines describing whether this is exploration, narrowing, or validation

Evidence Highlights

• Key field statistics that matter to the investigation.
• Representative records only when they add value.
• For schema exploration, only highlight the indices and fields that matter to the hunt.
• For keyword search, explain that the result is a keyword match set that can be used for follow-up search, distribution review, clue gathering, or source location.
• For adaptive query, explain that the result is a structured filter or aggregation result that supports validation, statistics, and stable reproduction.

Next Best Step

• Narrow the time range
• Add one stronger keyword
• Remove one restrictive keyword
• Search a specific index
• Switch to adaptive query with exact filters
• Save the useful SIEM result as enrichment on the relevant case, alert, or artifact
• Stop because the evidence is already sufficient

Clarification Rules

• Ask for the time range if it is missing.
• Ask for timezone only if the user did not provide UTC and the intended timezone is unclear.
• Ask for index_name only when broad search is likely wasteful, the user already hints at a known source, or adaptive query is the right tool.
• Ask for exact field names only when the user wants adaptive query and the schema is still unclear.
• If the user says "look around this event", derive a reasonable first search from the available IOC and time window instead of asking them to design the query.

Output Rules

• Be concise.
• Do not dump every returned record by default.
• Prefer the most relevant records and statistics.
• Group results by backend and index when multiple groups are returned.
• For schema exploration, present a shortlist rather than a raw field inventory.
• For keyword search, prefer output that helps guide the next search step instead of mechanically listing logs.
• For adaptive query, prefer output that supports the conclusion through filters and aggregation results.
• If no data is found, say that directly and suggest the most useful adjustment.

Failure Handling

• Invalid time format: ask for UTC ISO8601 with trailing Z.
• Empty results: widen the time range or remove one keyword.
• Too many hits: narrow the time range first, then add signal.
• Unknown index or field choice: use siem_explore_schema before guessing.
• Backend or source issue: state which backend or index failed if the result indicates it.