---
name: asp-siem-zh
description: '用于在 ASP SIEM 中进行日志调查、事件检索、字段探索和结构化分析，适合从模糊线索到精确验证的调查任务。'
argument-hint: 'explore schema [index] | search <keyword> from <UTC start> to <UTC end> | adaptive query <index_name> <time range> [filters] [aggregations]'
compatibility: connect to asp mcp server
metadata:
  author: Funnywolf
  version: 0.3.0
  mcp-server: asp
  category: cyber security
  tags: [ SIEM, search, SOC, hunting, investigation ]
  documentation: https://asp.viperrtp.com/
---

# ASP SIEM

当用户要在 ASP 中进行 SIEM 调查时，使用这个 skill。重点是帮助用户根据调查目标选择合适的查询方式，并输出对分析有价值的证据。

## 适用场景

- 用户要在 ASP SIEM 中查找、确认或补充安全事件证据。
- 用户想先了解有哪些索引、字段或可用数据源。
- 用户想根据 IOC、告警上下文或关键词搜索相关日志。
- 用户想在已知范围内做进一步过滤、统计或结构化分析。
- 用户想从 alert、artifact 或 case 继续向 SIEM 侧取证。

## 运行规则

- 如果用户请求已经隐含 SIEM 搜索，不要反问用户要选哪种操作。
- 只收集所选路径缺失的必要输入。
- 当用户不知道正确索引或字段时，使用 `siem_explore_schema`。
- `siem_keyword_search` 适合关键词驱动的搜索，既可用于广范围探索，也可用于已知 index 下的快速检索。
- `siem_adaptive_query` 适合精确字段过滤、受控聚合和稳定复现，能力上更接近一个结构化 SIEM API。
- 如果用户给出相对时间窗口，先调用 `get_current_time`，从返回的本地时间加时区推导出可用的 UTC 范围。
- 优化目标是有用证据，而不是最大原始输出。


## 函数说明

### `siem_keyword_search`

适用场景：

- 用户手里有 IP、域名、用户名、主机名、hash、进程名、邮件地址、报错文本或其他关键词，想直接查有没有相关日志。
- 用户还不确定日志在哪个 index，想先在较大范围或全局范围搜索。
- 用户想像 SIEM 检索界面那样多次调整关键词和时间范围，逐步观察结果分布。
- 用户已经知道 index，但当前只需要基于关键词快速找事件，不需要精确字段过滤。

使用方法：

- 必填参数是 `keyword`、`time_range_start`、`time_range_end`。
- `keyword` 可以是单个字符串，也可以是字符串列表；传列表时表示 AND 匹配。
- `index_name` 可选；不传表示全局搜索，传入时表示只在指定源或 index 中搜索。
- `time_field` 默认使用 `@timestamp`，只有在已知数据源使用其他时间字段时才改。

适合输出和解读：

- 返回的是搜索命中的事件集合，适合观察是否命中、命中分布在哪些 backend 或 index、事件时间是否集中、是否出现新的可疑关键词或字段。
- 它既可以作为调查起点，也可以作为调查中的快速二次搜索工具。
- 它不要求调用前就知道精确字段名，因此更适合模糊搜索和探索。

### `siem_adaptive_query`

适用场景：

- 用户已经知道或基本确认日志所在的 `index_name`。
- 用户已经有较明确的过滤条件，例如某个字段必须等于某值，或某几个字段要做精确匹配。
- 用户想做 top-N、分组统计、字段聚合、受控范围查询。
- 用户需要一个更稳定、可复现、结构化的查询，而不是继续做自由关键词搜索。

使用方法：

- 必填参数是 `index_name`、`time_range_start`、`time_range_end`。
- `filters` 是精确字段过滤条件，键是字段名，值可以是单个字符串或字符串列表。
- `aggregation_fields` 是可选的聚合字段列表；只有用户明确需要统计或分组时才添加。
- `time_field` 默认使用 `@timestamp`，只有在目标数据源不是这个字段时才修改。

适合输出和解读：

- 返回的是结构化查询结果，更适合做稳定验证、字段统计和结论支撑。
- 它更像提供给模型使用的一个 SIEM API，不要求一定来自 `siem_keyword_search` 的下一步，但通常需要更清晰的上下文。
- 当用户已经给出 index、时间范围和大致条件时，可以直接使用，不必强行先走关键词搜索。

### 两者如何选择

- 如果线索主要是“关键词”，优先用 `siem_keyword_search`。
- 如果线索主要是“已知 index + 已知字段条件”，优先用 `siem_adaptive_query`。
- 如果用户目标是找事件、看分布、补线索，优先用 `siem_keyword_search`。
- 如果用户目标是精确过滤、聚合统计、稳定复现，优先用 `siem_adaptive_query`。
- 如果用户没有说明字段名且 index 也不确定，不要强推 `siem_adaptive_query`。
- 如果用户已经说明明确的 index 和 filters，也不要机械地先跑 `siem_keyword_search`。

## 决策流程

1. 如果用户问该用哪个索引、有哪些字段，或 SIEM 源如何组织，使用 `siem_explore_schema`。
2. 如果用户给出相对时间窗口，调用 `get_current_time`，从返回的本地时间加时区推导出可用 UTC 范围，再继续。

## SOP

### 探索 Schema

1. 如果用户不知道目标源，先调用 `siem_explore_schema()`。
2. 如果用户已经知道索引且想要字段结构，调用 `siem_explore_schema(target_index=<index>)`。
3. 解析返回的 JSON。
4. 总结与调查目标最相关的索引、时间字段候选和高信号字段。
5. 推荐下一步查询路径：先全局关键词搜索，或在已明确位置时直接做自适应查询。

### 使用 `siem_keyword_search`

1. 先提取已知最强关键词。
2. 只有当用户真正要求所有条件都匹配时，才把多个关键词规范化为 AND 集合。
3. 要求 UTC 时间戳以 `Z` 结尾。
4. 如果用户未指定 `index_name`，可先全局搜索；如果用户已明确数据源，也可以直接限定到该 index。
5. 调用 `siem_keyword_search`。
6. 解析每条返回的 JSON 字符串，并按用户目标决定输出重点：
   - 如果用户在找事件，优先展示代表性命中。
   - 如果用户在判断日志落点，优先展示 backend、index 分布和时间分布。
   - 如果用户在继续收敛，优先总结下一轮应补充或移除哪些关键词。
7. 根据结果进行下一轮判断：
  - 命中太多时，先收窄时间范围，再补充一到两个高信号关键词。
  - 命中太少或为空时，先移除一个限制性关键词，或适度扩展时间范围。
  - 命中集中在少数 index 时，下一轮优先指定 `index_name`。
  - 当结果已经足够说明日志位置和关键字段时，切换到 `siem_adaptive_query`。

### 使用 `siem_adaptive_query`

1. 要求 `index_name`、UTC 时间范围，以及至少一个精确过滤条件或明确聚合目标。
2. 把过滤条件规范化为精确字段/值对。
3. 只有当用户想要流行度、top-N 统计或分组范围时，才添加 `aggregation_fields`。
4. 调用 `siem_adaptive_query`。
5. 用分析师语言总结过滤范围、命中情况和任何聚合输出。
6. 如果结果不理想，优先判断是 `filters` 太严、字段名不对、时间范围不对，还是其实应回到 `siem_keyword_search` 补充上下文。

### 优化搜索

首选优化动作：

1. 先用 `siem_keyword_search` 在全局或较大范围内建立感觉，不要过早假设 index。
2. 在添加很多新关键词前，先收窄时间范围。
3. 添加一两个高信号关键词，而不是很多弱关键词。
4. 如果查询为空，移除一个限制性关键词，或适度扩大时间窗口。
5. 当广泛搜索返回太多无关数据时，优先指定 `index_name` 或补充更强信号。
6. 当结果已经显示日志主要集中在某类 index 时，下一轮搜索就应该收敛到这些 index。
7. 当用户已经学到足够字段结构和日志落点时，可切换到 `siem_adaptive_query`；但如果用户仍只是想继续搜事件，也可以继续用 `siem_keyword_search`。
8. 持续迭代直到结果质量匹配用户目标。



## 回复策略

始终解释搜索的含义，而不只是它返回了什么。

首选回复结构：

### 搜索概览

- 搜索模式：schema 探索、关键词搜索或自适应查询
- 关键词集或精确过滤条件
- 时间范围
- 搜索的索引或 `all`
- 如果使用了聚合字段
- 用一两句话给出整体解释，说明当前搜索是在探索、收敛还是验证


### 证据要点

- 对调查重要的关键字段统计。
- 只有在增加价值时才给出代表性记录。
- 对于 schema 探索，只强调对 hunt 重要的索引和字段。
- 对于关键词搜索，说明这是关键词匹配结果，适合继续搜索、看分布、找线索或定位日志来源。
- 对于自适应查询，说明这是结构化过滤或聚合结果，适合做验证、统计和稳定复现。

### 下一步最佳动作

- 收窄时间范围
- 添加一个更强关键词
- 移除一个限制性关键词
- 根据分布切换到特定 index
- 搜索特定索引
- 用精确过滤切换到自适应查询
- 把有用 SIEM 结果保存为相关 case、alert 或 artifact 上的 enrichment
- 停止，因为证据已经足够

## 澄清规则

- 如果缺少时间范围，询问时间范围。
- 只有当用户没有提供 UTC 且意图时区不清楚时，才询问时区。
- 除非已经明显收敛，否则不要一开始就强制用户提供 `index_name`。
- 只有当广泛搜索可能浪费、用户已经暗示已知源，或自适应查询是正确工具时，才询问 `index_name`。
- 只有当用户想要自适应查询且 schema 仍不清楚时，才询问精确字段名。
- 如果用户说"看看这个事件周围"，从可用 IOC 和时间框架推导出合理的首次搜索，而不是让他们设计查询。

## 输出规则

- 保持简洁。
- 默认不要倾倒每条返回记录。
- 优先展示最相关的记录和统计。
- 当返回多个组时，按 backend 和 index 分组结果。
- 对于 schema 探索，呈现候选列表而不是原始字段清单。
- 对于关键词搜索，优先输出能指导下一轮搜索的分布和线索，而不是机械罗列日志。
- 对于自适应查询，优先输出能支撑结论的过滤命中和聚合结果。
- 如果没有找到数据，直接说明并建议最可能有用的调整。

## 失败处理

- 无效时间格式：要求 UTC ISO8601 带尾部 `Z`。
- 空结果：先扩展时间范围或移除一个关键词；如果过早指定了 index，也考虑回到全局关键词搜索。
- 太多命中：先收窄时间范围，再添加信号，必要时切到更可能的 index。
- 未知索引或字段选择：在猜测前使用 `siem_explore_schema`。
- Backend 或源问题：如果结果指示了，说明哪个 backend 或索引失败。
