Agentic SOC Platform

简体中文

English

简体中文

English

如何构建一个高效、可靠的 SIEM Agent ​

引言 ​

在当今的安全运营中心（SOC），分析师们面临着前所未有的海量日志数据。SIEM（安全信息和事件管理）系统是应对这一挑战的核心工具。近年来，大型语言模型（LLM）的崛起为自动化安全分析带来了新的曙光。 理论上，LLM 可以理解自然语言指令，并将其转化为复杂的 SIEM 查询，从而极大地提升分析效率。

然而，理想很丰满，现实很骨感。直接将 LLM 应用于生产环境的 SIEM 系统，我们会发现一系列棘手的问题。这篇文章将探讨这些挑战，并提出一套我们已经实践并证明有效的解决方案，旨在构建一个真正高效、可靠的 SIEM Agent。

核心挑战：LLM 在 SIEM 场景下的”水土不服” ​

当我们将 LLM 直接对接 SIEM 系统时，通常会遇到以下三大核心问题：

  1. LLM 无法稳定编写精确的查询语句： 无论是 Splunk 的 SPL 还是 Azure Sentinel 的 KQL，这些查询语言都拥有严谨的语法和复杂的函数。LLM 在生成这些查询时，即使有上下文学习能力， 也常常会因为对特定数据模式（Schema）的理解不充分而产生语法错误或逻辑缺陷的语句，导致查询失败。
  2. 海量数据导致定位困难： 生产环境的 SIEM 系统中存储着数以亿计的日志条目。当分析师给出一个较为宽泛的指令，如”查找过去 24 小时内用户'admin'的可疑行为”，LLM 很难在没有精确指导的情况下， 准确地从海量数据中定位到真正有价值的几条日志。这就像是让一个不熟悉图书馆的管理员去找一本没有索引号的书。
  3. 查询结果”污染”LLM 上下文： 这是一个更致命的问题。即使 LLM 侥幸生成了正确的查询，查询结果也往往是成千上万条原始日志。将这些未经处理的日志直接塞入 LLM 的上下文窗口，不仅会迅速耗尽宝贵的 Token 资源，更重要的是，大量的无关信息会”污染”上下文，干扰 LLM 的后续分析和推理能力，使其无法抓住重点。

解决方案：像专家一样思考和工作 ​

我们的核心思路是：不要强迫 LLM 成为一个数据查询专家，而是为它构建一套模仿人类安全分析专家工作流程的智能工具链。 人类专家在调查时，并不会一开始就试图编写完美的查询， 而是采用一种渐进式的、由粗到细的方法。我们的 SIEM Agent 正是围绕这一理念构建的。

策略一：模式定义（Schema Definition）——让数据变得透明 ​

我们首先解决 LLM 对数据模式不了解的问题。我们为 SIEM 中的每一个索引（index）都创建一个对应的 YAML 配置文件。这个文件就是该索引的”说明书”。

yaml
name: siem-network-traffic
backend: ELK
description: 包含了所有网络流量日志，可用于分析网络连接、协议分布和数据传输情况。

fields:
  - name: "@timestamp"
    type: date
    description: 事件发生的精确时间
    is_key_field: false

  - name: event.category
    type: keyword
    description: 事件分类，如 network_traffic（网络流量）
    is_key_field: true

  - name: event.action
    type: keyword
    description: 网络连接的动作，如 allow（允许）或 deny（拒绝）
    is_key_field: true

  - name: source.ip
    type: ip
    description: 源IP地址
    is_key_field: true

  - name: destination.ip
    type: ip
    description: 目的IP地址
    is_key_field: true

  - name: network.protocol
    type: keyword
    description: 网络协议，如 tcp、udp、icmp
    is_key_field: true

通过这个简单的 YAML 文件，我们为 LLM 提供了关于数据的一切：

  • description： 索引的用途是什么。
  • fields： 索引里有哪些字段，每个字段的类型和描述是什么。
  • is_key_field： 标记出哪些是核心调查字段。这至关重要，LLM 会优先关注这些字段。

这让原本对于 LLM 来说是”黑盒”的数据，变得清晰、透明。

策略二：渐进式信息披露（Progressive Disclosure）——按需提供信息 ​

我们借鉴了 Claude Skill 的设计哲学，即”渐进式披露”。Agent 在启动时，只会加载所有索引的 name 和 description 等高级信息。它知道有哪些数据源以及它们的大致用途，但不会被所有字段的细节所淹没。

只有当 LLM 在调查过程中决定要深入某个具体的索引（例如 siem-network-traffic）时，Agent 的内置工具（Tool）才会去加载并解析对应的 siem-network-traffic.yml 文件，并将详细的字段信息提供给 LLM。

这种机制确保了 LLM 的上下文始终保持简洁和聚焦，每次只获取当前任务所需的最少必要信息。

策略三：智能数据摘要（Intelligent Summarization）——从噪音中提取信号 ​

为了解决查询结果污染上下文的问题，我们的查询工具（Tool）引入了一个关键的智能摘要功能。当执行一个查询后，工具并不会立即返回原始日志。

  1. 强制时间范围： 所有查询都必须包含明确的开始时间和结束时间，避免无边界的查询。
  2. 多字段并行过滤： 支持同时对多个字段进行过滤，快速缩小范围。
  3. 智能摘要： 如果查询匹配的日志数量超过一个预设的阈值（例如 100 条），工具不会返回日志本身，而是返回一个统计摘要，内容包括：
    • 匹配日志的总数。
    • 每个关键字段（key_field）中，不同值的分布数量。

例如： 对于查询”过去 1 小时内所有被拒绝的网络连接”，工具可能返回：

json
{
  "total_hits": 5281,
  "is_aggregated": true,
  "summary": {
    "source.ip": {
      "10.1.1.5": 2500,
      "10.1.1.8": 1800,
      "... (3 more)": 981
    },
    "destination.port": {
      "22": 5200,
      "3389": 81
    },
    "network.protocol": {
      "tcp": 5281
    }
  }
}

这份摘要告诉 LLM："有 5281 次拒绝事件，主要来自几个特定 IP，并且绝大多数都指向了 22 端口（SSH）"。这份信息比 5281 条原始日志有价值得多，LLM 可以立即抓住重点，形成下一步的调查假设。

策略四：模拟分析师工作流（Simulating Analyst Workflow）——提供”初步分诊”工具 ​

人类专家在拿到一个可疑指标（如 IP 或域名）后，第一步通常是在所有可能的日志源中进行一个快速的、全局的搜索。我们将这个过程也封装成了一个工具。

”全局关键字搜索”工具：

  • 输入： 关键字（IP、用户名、域名等）和时间范围。
  • 过程： 工具并不会去查询原始数据，而是去搜索我们为每个索引定义的 YAML 文件（元数据）。它会检查关键字是否与索引的描述，或关键字段的描述相匹配。
  • 输出： 一个”可能相关的索引列表”。

例如： 输入关键字 185.193.124.210，工具可能会返回： ["siem-network-traffic", "siem-firewall-logs", "siem-proxy-logs"]

这个工具极大地降低了 LLM 的决策难度。它不再需要问”我应该查哪里”，而是可以从一个高度相关的建议列表中进行选择，或者将这个列表返回给用户进行决策。

实战演练：一次完整的调查 ​

让我们看看这个 Agent 如何调查一个真实的告警："在过去 24 小时内，调查与可疑 IP 185.193.124.210 相关的所有活动。"

  1. 启动（Step 1：Initial Triage）

    • LLM 调用**”全局关键字搜索”工具**，输入 185.193.124.210。
    • 工具返回：[“siem-network-traffic”, “siem-firewall-logs”]。

  2. 聚焦与摘要（Step 2：Focus & Summarize）

    • LLM 选择从 siem-network-traffic 开始调查。它请求工具查询该索引中包含 185.193.124.210 的日志。
    • 工具发现匹配的日志有数千条，于是触发智能摘要功能，返回：
      json
      {
  "total_hits": 8740,
  "is_aggregated": true,
  "summary": {
    "event.action": { "deny": 8740 },
    "destination.port": { "22": 8000, "3389": 740 },
    "source.ip": { "185.193.124.210": 8740 }
  }
}

  3. 深入挖掘（Step 3：Drill Down）

    • LLM 分析摘要后发现，所有活动都是被拒绝的连接，并且主要针对 SSH（22）和 RDP（3389）端口。这强烈暗示着一次扫描或暴力破解尝试。
    • LLM 现在可以发起一个更精细的查询：”请获取 siem-network-traffic 索引中，event.action 为 deny 且 destination.port 为 22 的 5 条样本日志。”
    • 这次，查询结果数量远小于阈值，工具会返回 5 条完整的原始日志。

  4. 结论（Step 4：Conclusion）

    • LLM 分析这几条样本日志，可以确认这是一次来自 185.193.124.210 的、针对不同服务器 SSH 端口的扫描攻击。
    • 最终，Agent 给出一份清晰、准确的报告："在过去 24 小时内，IP 185.193.124.210 对内网服务器发起了 8740 次连接尝试，均为拒绝。主要攻击目标是 SSH（8000 次）和 RDP（740 次）服务， 行为模式确认为扫描攻击。建议在防火墙上永久封禁此 IP。"

结论 ​

通过上述设计，我们构建的 SIEM Agent 成功地克服了 LLM 在安全分析领域的”水土不服”。关键的转变在于，我们不再将 LLM 视为一个全知全能但难以控制的”黑盒”，而是将其定位为一个聪明的”大脑”， 并为它配备了一双”眼睛”（模式定义）、一个高效的”记忆体”（渐进式披露），以及一双能干的”手”（智能摘要与分诊工具）。

这套以”模拟专家工作流”为核心的方案，使得 Agent 的每一步操作都变得更加精确、可控和高效，最终能够作为一个可靠的助手，真正赋能安全分析师，让他们从繁杂的低级查询和数据筛选中解放出来， 专注于更高层次的威胁狩猎和安全决策。

有关 SIEM Agent 的实现代码，请参考 GitHub 仓库。 更多对于 SIEM 插件的介绍，请访问 SIEM 插件文档。 同时，您也可以查阅 SIEM Agent 文档 了解更多信息。

最后更新于:

版权所有 © 2024-2026 Funnywolf