secops-triage: Google 把 SOC 一线分析师塞进了一个 Skill

SOC（安全运营中心）的一线分析师每天都在做同一件事：

• 看告警
• 判真假
• 决定要不要升级

听起来简单，但实际跑起来，这句轻描淡写的话背后是大量重复劳动：

• 同一个 IP 查十遍
• 同一个告警类型翻来覆去写同样的结论
• 在三个系统之间切来切去地找上下文

这就是 Google 的 secops-triage Skill 想解决的问题。它不搞花里胡哨的 AI 自动狩猎，也不承诺”一键搞定所有安全事件”。它做的事情非常聚焦：把 Tier 1 分析师在告警分类这件事上的标准操作流程，内化成一套可执行的协议。

说真的，这种”把一个具体岗位的标准流程写进 Skill”的思路，比那些号称全能的安全 AI Agent 靠谱得多。因为它不替代人，而是把人工分析中最机械、最重复的部分抽出来，让人把精力放在真正需要判断力的地方。

环境准备

secops-triage 运行在 Smithery 平台上，通过 Google SecOps 的 MCP 工具链来执行实际操作。你得先有一个 Google SecOps 环境，并且通过 Smithery 安装这个 Skill。

安装方式很直接，在 Smithery 页面点击安装就行。但真正开始用之前，有一个关键选择需要你先想清楚：你用哪种工具模式。

Skill 的 SKILL.md 里第一段就在讲这件事。它支持两套工具体系：Remote 模式走 Google SecOps 的远程 API（list_cases, udm_search 这类原生接口），Local 模式用本地安全事件搜索工具（search_security_events 这类）。两套工具的命名相似但参数和调用方式不一样，Skill 内部通过 TOOL_MAPPING.md 做了映射。如果你环境里 Remote 工具不可用，Skill 会自动退回到 Local 模式，不需要手动切换。

这个双模式设计解决了一个实际问题：不是所有 SOC 都用了 Google SecOps 全栈。有些团队只用了 Chronicle SIEM 但没有接入 SecOps API，Local 模式就是给他们准备的。Google 在设计这个 Skill 时显然考虑到了部署环境的多样性，没有假设用户一定是”全套 Google 安全产品”的理想配置。

操作流程

secops-triage 的核心是一套七步告警分类协议，从文档标题就看得出它的野心。“Alert Triage Protocol”，不是”建议”也不是”最佳实践”，是 Protocol。这意味着它希望你严格按步骤走，每步都有明确的输入输出和决策分支。

从 SKILL.md 的完整协议来看，整个流程的设计思路非常清晰：

Alert Triage Protocol
├── Step 1: Gather Context（收集上下文）
├── Step 2: Check Duplicates（查重）
├── Step 3: Find Related Cases（找关联告警）
├── Step 4: SIEM Search（告警相关搜索）
├── Step 5: Enrichment（IOC 富化）
├── Step 6: Assessment（四分类判定）
└── Step 7: Final Action（关 Case 或升级）

第一步是收集上下文。通过 get_case 或 get_case_full_details 拉取告警的完整信息：

• 告警类型
• 严重级别
• 关键实体（IP、用户、域名、文件哈希）
• 触发事件

这一步决定了后续所有步骤的数据基础。如果你在这一步拿到的信息不完整，后面每一步的判断都会偏。

第二步是查重。用 list_cases 按关键实体搜索历史告警。如果发现已有同类告警且已被确认为重复，Skill 会直接走”记录原因然后关闭”的快速通道。这个设计很实战。SOC 里大量告警其实是同一事件的重复触发，手工查重是分析师最烦的事情之一。

第三步到第五步是深度分析阶段，也是这个 Skill 最体现专业度的地方。

第三步找关联告警，搜索涉及相同实体的开放中的 Case。第四步做告警相关的 SIEM 搜索，而且不同类型的告警有不同的搜索重点。可疑登录类告警会查登录成功/失败记录，恶意软件类会查进程执行和文件修改，网络类会查流量和 DNS 记录。这个分类搜索策略比通用的”搜一下这个 IP”精准得多。

第五步是 IOC 富化，对每个关键实体执行 SIEM 概要查询和 IOC 匹配。第六步基于前面五步收集的所有信息做最终分类，把告警归入四类中的一类：

• 误报（False Positive）
• 良性真阳性（Benign True Positive）
• 真阳性（True Positive）
• 可疑（Suspicious）

这四分类体系比传统的”是或否”二分法实用得多。很多告警确实检测到了真实行为，但那个行为是管理员在合法操作，不是攻击。传统的二分法要么把它当攻击升级（浪费二线时间），要么当误报关掉（漏掉信息）。”良性真阳性”这个分类就是专门处理这种情况。

第七步是收尾动作。误报和良性真阳性走”记录原因 + 关 Case”流程，真阳性和可疑走”记录发现 + 升级”流程。Remote 模式下关 Case 用 execute_bulk_close_case，可以直接指定关闭原因（如 NOT_MALICIOUS）和根因分类（如 Legit action/Normal behavior）。Local 模式下关 Case 不支持自动操作，Skill 会提示用户手动处理。

关键设计

这个 Skill 有几个设计决策值得细看。

第一个是把工具适配放在协议的第一优先级。很多 Workflow Skill 的做法是先写流程，再假设用户环境里有对应的工具。secops-triage 反过来了：开头第一段就在讲”确认你能用哪些工具”，然后让 SKILL.md 里的每一步都带上 Remote 和 Local 两套指令。这意味着同一个协议可以跑在两种完全不同的工具链上，不需要用户自己去改流程。

第二个是分类体系的粒度控制。它没有用传统的”是攻击/不是攻击”二分法，而是拆成了四个等级：

• FP：没有恶意指标，已知良性活动
• BTP：检测到了真实行为，但是授权或预期的操作
• TP：已确认的恶意指标或可疑行为
• Suspicious：结果不确定但值得进一步调查

有意思的是 BTP 和 Suspicious 这两个”中间态”分类的存在，一类是”真但不是威胁”，一类是”不确定但值得查”。这两个分类说明设计者对 SOC 实际工作流程非常熟悉。一线分析师的日常不是在”是攻击”和”不是攻击”之间选，而是在这四个状态之间来回判断。

第三个是工作流里的”早停”策略。第二步如果发现重复告警，直接走关闭流程然后 STOP，不再执行后续的富化和深度分析。这个设计节省的不是几秒钟，是每个重复告警上浪费的完整分析周期。从文档来看，Skill 对于”什么时候可以不查”有明确的边界定义，这比”建议你查一下”的模糊指导要实用很多。

不过有一个潜在风险需要注意：这个 Skill 的分类逻辑依赖 SIEM 搜索的覆盖度和质量。如果 SIEM 里的日志不全，或者 IOC 库的时效性不够，第 4-5 步的分析结果可能会偏。换句话说，Skill 本身是一流的，但它跑出来的结论取决于你喂给它的数据质量。这不是 Skill 的问题，但它决定了你能在多大程度上信任它的自动分类结果。

使用场景

SOC 里最常见的三类告警，这个 Skill 都有针对性的处理策略。

可疑登录告警是最频繁的一类。一个用户在凌晨三点从陌生的地理位置登录，触发了异常登录告警。传统做法是分析师先看登录记录，再查这个 IP 的威胁情报，然后翻历史告警确认这个用户之前有没有类似行为，最后决定是不是要升级。secops-triage 把这个过程压缩成了四步：拉 Case 详情（拿到用户、源 IP、时间），SIEM 搜索这个时间段内的登录事件（成功和失败都查），对源 IP 做 IOC 富化，然后基于这些信息分类。如果发现这是用户出差在外地登录，标记为 BTP 关闭；如果发现源 IP 关联已知攻击活动，升级。

恶意软件告警是另一类高频场景。端点检测到可疑进程或文件哈希，需要判断是真恶意还是误报。Skill 的第四步对此做了专门优化：搜索进程执行事件、文件修改记录和网络连接，构建一个围绕该端点的行为画像。然后第五步对文件哈希做 IOC 匹配，查威胁情报库。两个维度的信息合在一起，判断的准确度比单独看哈希高很多。

网络异常告警，比如 C2 通信或数据外传的检测，Skill 会查网络流量日志和 DNS 查询记录。这类告警的一个特点是容易产生大量关联，一个被控主机可能跟几十个恶意域名通信过。Skill 的第三步”找关联告警”在这里特别有用，因为它能帮你发现同一个主机或同一个 IP 段上还有没有其他待处理的告警，避免漏掉横向移动的迹象。

这三类场景覆盖了 SOC 一线 80% 以上的日常工作，而且每类都有专门的搜索策略。从文档的细节程度来看，Google 应该是拿自己内部 SOC 的实战经验来写的这套协议，而不是从教科书上摘抄的理论流程。

洞察与反思

看完整套 SKILL.md 之后，我最深的感受不是这个 Skill 功能多强，而是它定义了一种新的 Skill 设计范式：不追求功能广度，而是把单一角色的一次完整操作流程做精。

大多数安全类 Skill 和 Agent 都在做同一件事，把所有能想到的安全检查堆在一起，号称”一站式安全运营”。但实际用起来你会发现，这些大而全的工具反而更难用，因为每个检查的深度都不够，你得手动补大量上下文。secops-triage 反其道而行之：它只做告警分类这一件事，但每一步都深到可以直接替代人工操作。

另一个观察是这个 Skill 的协议化程度。传统的 Skill 大多是”提供一些工具，让 AI 看着办”，secops-triage 是”给你一套标准流程，你必须按这个走”。这种协议化的 Skill 有一个天然优势：输出的一致性很高。同一个告警类型，不同时间、不同 Case 跑出来的分析路径是一样的，这对 SOC 的审计和复盘非常重要。

不过这个 Skill 也有明显的边界。它只做 Tier 1 分类，不涉及实际的响应动作，比如隔离主机、阻断 IP、触发 SOAR 剧本。从设计上看这是一个正确的边界划定。Tier 1 的职责就是分类和升级，动手操作是 Tier 2/3 的事。但对于一些规模较小的 SOC，一线和二线可能是同一个人，这时候就会觉得”你帮我判完了还得我自己去操作”，流程上有点断。

从 Smithery 的数据来看，433 个安装量在安全类 Skill 里算中等偏上。考虑到 Google SecOps 本身的用户基数不算特别大，这个数据反映的是目标用户群内部的渗透率相当不错。真正在用 Google SecOps 的团队，安装这个 Skill 的意愿很强。

资源地址

总结

secops-triage 不是那种让你”哇”一声的工具。它有三件事明确不做：

• 不炫技
• 不做自动狩猎
• 不画漂亮的安全态势图

但它做的事情是 SOC 运营中最基础、最容易被忽视的一环：

把告警分类这件事
做标准
做快
做一致

如果你团队里的一线分析师每天有三分之一的时间花在”这个告警别人是不是已经处理过了”和”这个 IP 上次是什么结论来着”上，那这个 Skill 能省掉的远不止时间，还有因为重复决策疲劳导致的漏判。

话说回来，它也不是开箱即用到能自动跑的程度。你得先有一套可用的 SIEM 日志和 IOC 情报库，Skill 的分析质量直接取决于这两个数据源的完整度。如果你的环境还在”告警来了手动翻日志”的阶段，装这个 Skill 之前先补数据基础。